Перенаправляет — htcaccess или cloudflare?

#wordpress

#wordpress

Вопрос:

У меня проблемы с клиентским сайтом.

Проблема в том, что, похоже, перенаправление на URL-адрес, который не существует / не имеет содержимого:

www.henparty-houses.com/liverpool

Тем не менее, если мы изменили конечный URL-адрес на другой без содержимого / не существует, мы получаем правильную загрузку страницы (т. Е. Страница не существует).

www.henparty-houses.com/leeds

===

Кажется, на URL-адресе / liverpool есть какое-то перенаправление.

Проблема заключается в том, когда создается страница, заканчивающаяся URL / liverpool — невозможно использовать этот URL, поскольку wordpress считает, что он уже используется / занят.

Возможно, я упускаю что-то очевидное или какую-то ошибку, но мне нужно как-то очистить URL-адрес / liverpool, чтобы можно было использовать контент, и убедиться, что при создании страницы с контентом с использованием / liverpool перенаправление отсутствует!

Может кто-нибудь, пожалуйста, помогите?

—- при проверке этого перенаправления, вот результат. Я проверил clourflare и не вижу никаких настроек перенаправления:

Результаты: www.henparty-houses.com/liverpool

HTTP / 1.1 301 Перемещен навсегда Дата: Пт, 25 Сен 2020 10:08:36 GMT Тип содержимого: текст / html; кодировка = iso-8859-1 Передача-Кодировка: фрагментированное соединение: keep-alive Set-Cookie: __cfduid=d440b3cca7954a48bdc3f84b50e73ea7a1601028515; истекает= Вс, 25-20 октября 10:08:35 GMT; путь =/; domain=.henparty-houses.com ; HttpOnly; SameSite=Слабое местоположение: https://www.henparty-houses.com/liverpool Cache-Control: max-age = 0 Истекает: Пт, 25 Сен 2020 10:08:36 GMT Заголовок хоста: b7440e60b07ee7b8044761568fab26e8 X-Прокси-Кэш: МИСС CF-Статус кэша: ДИНАМИЧЕСКИЙ cf-запрос-id: 05665580120000ed6fcaa52200000001 Сервер: cloudflare CF-RAY: 5d83f1e01a84ed6f-SJC

https://www.henparty-houses.com/liverpool

HTTP / 2 302 дата: Пт, 25 Сен 2020 10:08:39 GMT тип содержимого: текст / html; кодировка = UTF-8 набор файлов cookie: __cfduid=d974040f170c5090b9a4e61af9590d1b61601028518; истекает=Вс, 25-Окт-20 10:08:38 GMT; путь=/;domain=.henparty-houses.com ; HttpOnly; SameSite=Слабый x-cache-включен: True p3p: CP=»ВСЕ DSP NID CURa ADMa DEVa HISa OTPa НАШ NOR NAV DEM» x-перенаправление: расположение WordPress: https://www.henparty-houses.com контроль кэша: максимальный возраст = 0 истекает: пятница, 25 сентября 2020 г. 10:08:38 GMT заголовок хоста: b7440e60b07ee7b8044761568fab26e8 x-proxy-cache: MISS cf-cache-status: ДИНАМИЧЕСКИЙ cf-запрос-id: 05665588c800009623ca33e200000001 ожидаемый-ct: max-age= 604800, отчет-uri =»https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct » сервер: cloudflare cf-ray: 5d83f1ee09ee9623-SJC

https://www.henparty-houses.com

HTTP / 2 200 дата: Пт, 25 Сен 2020 10:08:41 GMT тип содержимого: текст / html; кодировка = UTF-8 набор файлов cookie: __cfduid=d63a3cce54fa1ecc1e3d8bbf7c7415b8d1601028519; истекает=Вс, 25-Окт-20 10:08:39 GMT; путь=/;domain=.henparty-houses.com ; HttpOnly; SameSite=Слабый x-cache-включен: True p3p: CP=»ВСЕ DSP NID CURa ADMa DEVa HISa OTPa OUR NOR NAV DEM» ссылка: ; rel=»https://api.w.org /», ; rel=»альтернативный»; тип=»приложение / json», ; rel=изменение короткой ссылки: Принять-контроль кэша кодирования: max-age = 0 истекает: Пт, 25 Сен 2020 10:08:40 GMT заголовок хоста: b7440e60b07ee7b8044761568fab26e8 x-прокси-кэш: ПРОПУСТИТЬ cf-статус кэша: ДИНАМИЧЕСКИЙ cf-запрос-id: 0566558f4e0000930a5d2f8200000001 ожидать-ct: макс-возраст = 604800, отчет-uri =»https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct » сервер: cloudflare cf-ray: 5d83f1f87ede930a-SJC

Ответ №1:

Я не думаю, что вы найдете ответ, просматривая свои .htaccess файлы. Как вы можете видеть из заголовков, перенаправление выдается самим WordPress.

 x-redirect-by: WordPress
  

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

 grep --line-number --with-filename --fixed-strings -i -R 'x-redirect-by' .
  

Результат довольно короткий:

 ./wp-includes/pluggable.php:1284:                * Filters the X-Redirect-By header.
./wp-includes/pluggable.php:1296:                       header( "X-Redirect-By: $x_redirect_by" );
  

Неудивительно, что вызывается функция, которая задает этот заголовок wp_redirect .

Короче говоря, проблема, вероятно, не в конфигурации сервера. Я думаю, что происходит то, что для одной из ваших страниц установлено liverpool значение slug .

Обычно, когда WordPress получает запрос на страницу, которая не существует (вызывая 404 ошибку), он сначала пытается перенаправить запрос на «канонический» URL (см. Этот пост). Эти канонические URL-адреса называются «слагами».

Если для одной из ваших существующих страниц установлен slug liverpool , это вызовет процесс канонизации URL. Поэтому возможно, что, возможно, эта страница имеет значение скрытая или перенаправляет пользователя вручную, потому что для этого требуется, чтобы пользователь вошел в систему, или множество других вещей. В любом случае причиной перенаправления является перенаправление вручную 302 . Лучший способ узнать, что именно происходит, — найти страницу с этим конкретным слагом.

Причина, по которой я склонен полагать, что страница существует прямо сейчас, заключается в том, что это 302 средство Found . Если страница ранее использовала liverpool фрагмент, а затем изменила его, правильным ответом было бы перенаправление 301 Moved Permanently на текущую версию страницы. Я думаю, что существует страница с slug of liverpool, которая целенаправленно перенаправляет клиента на главную страницу. Таким образом, решение, скорее всего, отслеживает эту страницу вниз.

Вы можете значительно ускорить этот процесс, обратившись к базе данных напрямую, а не через пользовательский интерфейс. wp_posts Таблица содержит большую часть содержимого страницы (более подробное объяснение см. В документации WordPress), а wp_postmeta таблица содержит метаданные post.

Я бы начал с выполнения такого запроса (я предполагаю, что вы используете MariaDB или MySQL, но Postgres или любой другой запрос будет аналогичным, если не идентичным).

 SELECT `wp_posts`.`post_name` FROM `wp_posts` WHERE `wp_posts`.`post_name` LIKE '%liverpool%';
  

Этот запрос должен приблизить вас. Если вы ничего не можете там найти, вы можете проверить wp_postmeta таблицу. В зависимости от того, насколько велика база данных сайта, на самом деле может быть проще просто переходить постранично в пользовательском интерфейсе и проверять вручную, поскольку многие записи представляют собой либо сериализованные объекты, HTML, либо просто трудно поддаются визуальному анализу.

 SELECT `wp_postmeta`.* FROM `wp_postmeta`;
  

LIKE Очевидно, что здесь можно использовать другое предложение, которое может быть полезно попробовать сначала, прежде чем запускать это. Имейте в виду, что для запуска может потребоваться некоторое время, поскольку он должен фильтровать результаты на основе сопоставления с шаблоном, поэтому может быть полезно сначала выполнить этот базовый запрос, чтобы у вас были все результаты, а затем конкретный запрос на другой консоли, чтобы вы могли попытаться просмотреть выходные данные, покавыполняется другой запрос. Я не уверен, насколько быстро ваше оборудование, но я говорю по личному опыту, лол.

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

 DESCRIBE `wp_postmeta`;
DESCRIBE `wp_posts`;
  

Вы также можете сделать SHOW TABLES , чтобы фактически увидеть все таблицы в базе данных, с которой вы работаете.

Вы также должны взглянуть на этот пост. В частности, обратите внимание, где говорится, что вы можете отключить перенаправления, добавив remove_action( 'template_redirect', 'wp_old_slug_redirect'); . Я лично не знаком с этой функциональностью, но если вы посмотрите на определение wp_redirect функции ( $WORDPRESS_INSTALL_DIR/wp-includes/pluggable.php , строка 1246), вы увидите, что функция применяет фильтры, определенные в другом месте.

Обратите внимание также, что функция специально проверяет, находится ли код состояния между 300 и 399 , что означает, что что-то меняет код состояния с 404 на 302 .

Вот определение функции для вашего удобства и назидания.

 /**
 * Redirects to another page.
 *
 * Note: wp_redirect() does not exit automatically, and should almost always be
 * followed by a call to `exit;`:
 *
 *     wp_redirect( $url );
 *     exit;
 *
 * Exiting can also be selectively manipulated by using wp_redirect() as a conditional
 * in conjunction with the {@see 'wp_redirect'} and {@see 'wp_redirect_location'} filters:
 *
 *     if ( wp_redirect( $url ) ) {
 *         exit;
 *     }
 *
 * @since 1.5.1
 * @since 5.1.0 The `$x_redirect_by` parameter was added.
 * @since 5.4.0 On invalid status codes, wp_die() is called.
 *
 * @global bool $is_IIS
 *
 * @param string $location      The path or URL to redirect to.
 * @param int    $status        Optional. HTTP response status code to use. Default '302' (Moved Temporarily).
 * @param string $x_redirect_by Optional. The application doing the redirect. Default 'WordPress'.
 * @return bool False if the redirect was cancelled, true otherwise.
 */
function wp_redirect( $location, $status = 302, $x_redirect_by = 'WordPress' ) {
    global $is_IIS;

    /**
     * Filters the redirect location.
     *
     * @since 2.1.0
     *
     * @param string $location The path or URL to redirect to.
     * @param int    $status   The HTTP response status code to use.
     */
    $location = apply_filters( 'wp_redirect', $location, $status );

    /**
     * Filters the redirect HTTP response status code to use.
     *
     * @since 2.3.0
     *
     * @param int    $status   The HTTP response status code to use.
     * @param string $location The path or URL to redirect to.
     */
    $status = apply_filters( 'wp_redirect_status', $status, $location );

    if ( ! $location ) {
        return false;
    }

    if ( $status < 300 || 399 < $status ) {
        wp_die( __( 'HTTP redirect status code must be a redirection code, 3xx.' ) );
    }

    $location = wp_sanitize_redirect( $location );

    if ( ! $is_IIS amp;amp; 'cgi-fcgi' !== PHP_SAPI ) {
        status_header( $status ); // This causes problems on IIS and some FastCGI setups.
    }

    /**
     * Filters the X-Redirect-By header.
     *
     * Allows applications to identify themselves when they're doing a redirect.
     *
     * @since 5.1.0
     *
     * @param string $x_redirect_by The application doing the redirect.
     * @param int    $status        Status code to use.
     * @param string $location      The path to redirect to.
     */
    $x_redirect_by = apply_filters( 'x_redirect_by', $x_redirect_by, $status, $location );
    if ( is_string( $x_redirect_by ) ) {
        header( "X-Redirect-By: $x_redirect_by" );
    }

    header( "Location: $location", true, $status );

    return true;
}
  

Комментарии:

1. Спасибо. С этим мне удалось решить проблему — она существовала, но не отображалась на панели администратора WordPress. Таким образом, использование базы данных для определения местоположения liverpool в базе данных в wp_posts, а затем удаление записи решило проблему. Большое спасибо за подробный ответ

2. Мое удовольствие, я рад, что это помогло