Не удается вызвать файлы плагинов WordPress из-под wp-content

У меня есть клиент, у которого много клиентов блога. Каждый из этих блогов WordPress вызывает плагин, который предоставляет ссылку на продукт. Состав этой ссылки выглядит следующим образом:

{веб-сайт}/wp-content/plugins/prodx/product?id=432320

Это отлично работает на всех блогах, кроме двух. На этих двух, когда вы пытаетесь позвонить по URL-адресу, вы получаете 404.

Итак, я отключил все плагины, кроме prodx, и вернул тему по умолчанию (Kubrick), думая, что, возможно, это делает перехват плагина с API add_action(), например, перехват URL-адресов и их перенаправление. Однако это не помогло.

Итак, я обновил WordPress до последней версии. Опять не исправили.

Итак, я проверил разрешения, сравнив с блогом, который работал нормально. Опять не исправили.

Поэтому я заменил .htaccess на один из работающего блога. Опять не исправили.

Поэтому я заменил все файлы, используя некоторые из рабочего блога, который был идентичен этому, а затем восстановил файл wp-config.php обратно, чтобы он общался с нужной базой данных блога. Опять не исправили.

Я снова тщательно проверил разрешения, сравнив их с отлично работающим блогом. Опять не исправили.

Итак, я создал test.php, который выглядит так:

<?php

print_r($_GET);
echo "hello world";

Затем я скопировал его в другую папку плагинов и использовал свой браузер, чтобы добраться до него — снова 404. Поэтому я скопировал его в корень wp-content/plugins и попытался вызвать его там — снова 404. Итак, я скопировал его в wp-content -- снова 404. Наконец, я скопировал его в корень веб-сайта блога WordPress, и на этот раз это сработало!

Не имеет смысла.

Я начал думать, что, возможно, что-то происходит с /etc/httpd/conf/httpd.conf для этого клиента, но единственное, что я увидел в них для этого клиента, это то, что IP-адрес отличался от работающего блога клиента. Каждый клиент получает свой собственный IP в этой среде, созданной моим клиентом.

Мой клиентский сисоп тоже сбит с толку.

Что по-твоему происходит? Что-то не так в базе данных WP для этого клиента? Что-то не так в httpd.conf?


wordpress http-status-code-404 apache2 httpd.conf
person Volomike    schedule 30.04.2010    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Вы можете проверить неверные URL-адреса в параметрах плагинов в таблице параметров WP с помощью phpmyadmin (и сравнить другие аспекты параметров каждого блога), которые могут быть уже доступны на вашем хосте, или в виде плагина: WordPress › Portable phpMyAdmin « Плагины для WordPress. Или удалите параметры плагинов с помощью параметров очистки, чтобы полностью «сбросить» плагин (если плагин использует параметры): Очистить параметры « Плагины WordPress

person markratledge    schedule 30.04.2010
comment
Спасибо, я попробую и дам вам знать. Я думаю, что кто-то добавил фильтр или действие в правила перезаписи (что возможно в WordPress), и вот что делает это со мной. - person Volomike; 01.05.2010

arrow_upward
1
arrow_downward

Вы должны заглянуть в журнал ошибок вашего сервера, там должно быть объяснение. Если нет, включите уровни отладки и т. д. Тем не менее, плагин действительно не должен ссылаться на файл в каталоге плагинов, он должен использовать класс перезаписи wordpress http://codex.wordpress.org/Function_Reference/WP_Rewrite

person nkuttler    schedule 04.05.2010
comment
Я обнаружил, что API wp_rewrite на самом деле довольно сложный. И они рекомендуют вам запускать его во время активации и деактивации, но, к сожалению, я не мог сделать это с блогами, которые уже были запущены. Итак, я использовал описанную ниже технику hijack_URL(), которая была еще проще в использовании. - person Volomike; 06.05.2010

arrow_upward
0
arrow_downward

Я думаю, проблема была в том, что URL был слишком длинным. Вот отличная информация об этом:

http://www.boutell.com/newfaq/misc/urllength.html

И по какой-то причине блог получил 404 вместо 413.

Исправление заключалось в том, что я использовал gzcompress, чтобы сократить свой длинный идентификатор продукта (который был скрытым URL-адресом), а затем bin2hex. Поэтому я сделал URL-адрес следующим образом:

http://myblog.com/item/789ccb282929b0d2d72f2f2fd7cb4ac92fcc4faed44bcecfd54fcec94cced63536373334b730d7353430333334b530b60f0df2b1cd00ea503576543572032290befcb2d4a2e292fce46c904e90b0b15b1a50854b9aaa915980a3bb2b901910e4ef12ea1c0214f00f0ef60e058a181a199b5b18999b0100194725b4

Оттуда мой плагин добавил обработчик инициализации для захвата URL-адреса, его проверки и перенаправления. Эта функция выглядит так:

add_action('init','hijackURL');

function hijack_URL() {
  $sURL = $_SERVER['REDIRECT_URL'];
  if (empty($sURL)) {
    $sURL = $_SERVER['REQUEST_URI'];
  }
  if (strpos(' ' . $sURL, '/item/')>0) {
    $sID = str_replace('/item/','',$sURL);
    $sID = trim($sID);
    if (empty($sID)) {
      require('../../../wp-blog-header.php');
      $sBlogURL = get_bloginfo('wpurl');
      header('HTTP/1.1 302 Moved Temporarily');
      header("Location: $sBlogURL");    
      exit(0);
    }
    $sID = pack('H*', $sID);
    $sURL = gzuncompress($sID);
    header('HTTP/1.1 302 Moved Temporarily');
    header("Location: $sURL");  
    exit(0);
  }
}
person Volomike    schedule 02.05.2010