Периодические ошибки 404 и 500 с перенаправлением перманента на сайт Wordpress - PullRequest
Новая
       27

Периодические ошибки 404 и 500 с перенаправлением перманента на сайт Wordpress

1 голос
/ 04 марта 2012

Я завещал сайт Wordpress, который был создан в подкаталоге нашего текущего основного веб-сайта (стандартный HTML).Итак, у меня есть:

http://www.company.com/ в качестве основного сайта

и

http://www.company.com/newsite/ в качестве сайта WordPress.

следующие структуры каталогов:

/ company-com /

и

/ company-com / newsite /

Это (само собой разумеется) нескольконеудобно.Однако по разным причинам было бы сложно изменить эту структуру, поэтому я хотел бы придерживаться ее, если это вообще возможно.

Я создал файл .htaccess в каталоге / company-com / с помощью (например,)

перенаправление перманент /aboutus.htm http://www.company.com/newsite/aboutus/

Пока у меня есть около 20 перенаправлений для различных страниц.

Это работало нормально, пока я не заметил случайночто мы получили 500 ошибок.Это оказалось прерывистым.Позвонив нашему хостинг-провайдеру 1and1, служба поддержки сказала, что это потому, что у нас заканчиваются вычислительные мощности и нам нужно обновить наш пакет (!).Ранее я поднял онлайн-билет и сыт по горло ожиданием ответа.На этот тикет ответили, что проблема в файле .htaccess.

Вопрос:

Какой из них правильный?Из того, что я прочитал, файл .htaccess вызовет постоянные проблемы, а не прерывистые, поэтому я бы пошел с недостатком вычислительной мощности.

С уважением, Стив Бут

Ответы [ 2 ]

0 голосов
/ 24 октября 2014

Я неоднократно был свидетелем случайных ошибок 404 и 500, связанных с перенаправлениями через .htaccess RewriteRules. Подавляющее большинство можно было бы вылечить, добавив директиву RewriteBase, соответствующую базовой папке ваших перезаписей, например ::10000 

RewriteBase /

или 

RewriteBase /newsite

Фактически, многие системы CMS уже имеют такую ​​директиву RewriteBase в своих предварительно записанных файлах .htacces, которая закомментирована и требует активации (например, Drupal, Joomla, TYPO3).

Хотя это решило проблему для меня во многих случаях, тем не менее, я все еще не могу понять, почему такие прерывистые ошибки перенаправления вообще случаются. В конце концов, они должны или произойти, или не произойти, но не приходят и не уходят случайным образом.

0 голосов
/ 04 марта 2012

У вас есть две отдельные проблемы здесь. Первое - это ограничения хостинг-пакета 1and1. Я предполагаю, что вы используете их пакет общего хостинга. Это будет процессор, который использует любой отдельный скрипт. У моего хоста есть «RLimitCPU 15», что означает, что ни один скрипт не может занять больше 15 секунд процессора Возможно, ваши приложения «сталкиваются» с этим пределом и истекают. Я использую стандартный цикл синхронизации вокруг всех моих сценариев, где я добавляю это в начало своих сценариев: 

define( 'START_TIME', microtime() );

и это до конца каждого скрипта 

pageTimer( "Page $pageName completed" );

где pageTimer (): 

/**
  * Simple debug transaction timer
  * @param $eventName Timer event being displayed 
  */
function pageTimer( $eventName ) {
    static $u0, $s0;

    if( is_null( $s0 ) ) {
        list( $u0, $s0 ) = explode( " ", START_TIME );
        debugMsg( date( 'Y-m-d H:i:s', $s0 ) .  " - Transaction timer set at 0 mSec" );
    }

    list( $u1, $s1 ) = explode( " ", microtime() );
    $elapsed = ( ( (float)$s1 - (float)$s0 ) + ( (float)$u1 - (float)$u0 ) ) * 1000;
    debugMsg( sprintf( "\t%s at %u mSec", $eventName, (int) $elapsed ) );
}

, где debugMsg() просто выполняет error_log( $msg . "\n", 3, $debugFile );, и я регулярно проверяю время выполнения скрипта на странице. Делая это, вы знаете, если что-то занимает слишком много времени Второе, что вы должны сделать, это установить в журнале ошибок личный файл в вашем каталоге и собрать все ошибки, а затем регулярно проверять это.

Второй вопрос - ваши перенаправления. Это должно не вызывать эту неустойчивую проблему.

...