it-swarm.xyz

Настройка WordPress с пользовательскими постоянными ссылками и без файла .htaccess?

У меня есть клиент, который настоятельно предпочитает отключать файлы .htaccess, потому что им нравится устанавливать конфигурации Apache самостоятельно. Тем не менее, они все еще хотят SEO-дружественные URL.

Есть ли способ иметь пользовательские постоянные ссылки без файла .htaccess? Мои исследования до сих пор, кажется, показывают, что это невозможно, но, возможно, один из блестящих разработчиков знает, как казалось бы невозможное возможно. Заранее спасибо!

7
Mike Lee

Привет @Mike Lee :

Чтобы ответить на ваш вопрос, полезно понять, как все работает.

Apache обслуживает URL-адреса, которые соответствуют файлам и каталогам

Apache предназначен для обслуживания файлов, явно совпадающих с URL, или для обслуживания index.php, найденного в каталоге, когда каталог явно совпадает.

Но Apache может обслуживать URL-адреса, соответствующие Regex с mod_rewrite

Если вы хотите, чтобы Apache соответствовал URL-адресам, для которых нет реальных каталогов (в случае с WordPress и довольно постоянными ссылками), то у вас должен быть какой-то способ рассказать Apache, как обрабатывать URL-адреса по-разному. И это именно то, что mod_rewrite был разработан, чтобы позволить; это дает администраторам серверов возможность устанавливать правила для сопоставления URL-адресов с помощью регулярных выражений. Эти правила направляют результат на другие URL-адреса, часто включая фактически файлы .PHP, а иногда и передаваемые параметры URL-адреса. В конечном итоге правила определяют, что загружаются реальные файлы.

И mod_rewrite конфигурируется с .htaccess или httpd.conf

Для настройки mod_rewrite вы можете сделать это только внутри .htaccess или внутри файла httpd.conf или одного из включаемых в него файлов, например, потенциально httpd-vhosts.conf. На самом деле, я удивлен, если у вашего клиента есть навыки для управления Apache, что они этого еще не знают.

WordPress всегда использует один и тот же простой файл .htaccess

Переходя к тому, что делает WordPress, когда вы устанавливаете постоянные ссылки, WordPress записывает следующее в файл .htaccess, предполагая, что он доступен для записи (и в этом первом примере, если ваш сайт обслуживается из корня):

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Предостережение: когда каталог на главной странице WordPress не является корневым

Если вместо этого ваш сайт обслуживается из /blog, тогда записанный файл .htaccess будет выглядеть следующим образом:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>

WordPress перенаправляет все URL-адреса, не соответствующие файлам и каталогам, в index.php

Итак, как вы можете видеть, единственное, что WordPress использует для .htaccess, - это сопоставлениелюбогоURL-адреса домена к /index.php (или /blog/index.php во втором примере)кромекогда URL соответствует фактическому файлу (например, .jpg/.gif/.png image, таблице стилей .css, сценарию .js и т. д.) или когда он соответствует фактическому каталогу (который, насколько я знаю, не относится к стандартной установке WordPress.)

В PHP Разборы WordPress $_SERVER['REQUEST_URI'] Чтобы решить, что загрузить

Внутри своего PHP кода WordPress получает значение $_SERVER['REQUEST_URI'], которое содержит полный URL-запрос sans домен и схему (т. Е. Схема http или https), и затем анализирует значение, чтобы определить, какой URL был запрошен и, следовательно, что страницы это должно загрузить.

В обход .htaccess? Получить Apache для загрузки виртуальных URL-адресов (но удачи с этим!)

Поэтому, если вы хотите каким-то образом обойти .htaccess, ваша задача - заставить Apache отвечать на произвольный URL, затем загрузить WordPress и установить $_SERVER['REQUEST_URI'] в качестве пути URL плюс параметры; IOW подделка, но в хорошем смысле. Тем не менее, я знаю, если не знаю никаких способов, которые не слишком сложны для этого.

Встраивание /index.php/ (возможно?!?)

Несмотря на то, что * Chris_O * правильно добавил /index.php/ к вашим URL, я сжимаю всякий раз, когда вижу это. Он добавляет 10 символов к каждому URL, делая их длиннее и менее значимыми для поисковых систем, но, что еще хуже, делает их менее доступными и выглядит загадочно для пользователей. Извините, Крис, я знаю, что вы имели в виду хорошо, но тьфу!

Создавайте реальные каталоги для каждого URL (может быть?)

Один из способов получить милые постоянные ссылки без прикосновения к Apache - написать скрипт, который будет генерировать фактический каталог для каждого URL, который вы хотите, а затем сохранить там index.php, который загрузит WordPress. Конечно, это было бы огромным усилием для крошечной выгоды, и это потребовало бы, чтобы у сервера был доступ на запись, который должен быть хуже, чем использование файла .htaccess.

Ненавижу признавать, но это то, что я делал примерно в 1998 году с веб-сайтом на основе .ASP, когда IIS не поддерживал перезапись URL (и даже сегодня это все еще настоящая PITA!) ненавидел это, но URL-адреса были хороши как для пользователей, так и для SEO!

Лучшее решение? Добавить правила перезаписи в httpd.conf

Вернемся к тому, что, вероятно, является вашим лучшим решением, и @Simon Brown фактически рекомендовало его; Добавьте свои правила перезаписи в httpd.conf или в один из включаемых файлов, таких как httpd-vhosts.conf (именно так Apache настроен на localhost на моем Mac.) Добавьте следующую директиву, убедившись, что вы изменили каталог в соответствии с каталогом вашего сайта:

<Directory "/home/example_user/public_html/">
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</Directory>

Бонус! С блокировкой приходит производительность

Этот последний вариант должен устранить любой .htaccess и вернуть контроль в свои руки. Более того, он немного более производительный, поскольку httpd.conf загружается только один раз при запуске Apache, но.htaccess файлы загружаются и анализируются при каждом запросе URL!

Постскриптум Еще одна вещь, которую следует учитывать, - это внешний Apache с кэширующим сервером, например Nginx, который, я считаю, становится лучшей практикой для сайтов WordPress с большим трафиком которые действительно должны быть исполнительным. Это может потребовать настройки зеленого поля, потому что я не думаю, что большинство людей использовали Nginx для переписывания URL-адресов для Apache, но если вас интересует это направление, вот несколько ссылок:

15
MikeSchinkel

Постоянные ссылки без mod_rewrite

Без файла .htaccess и без изменения файла httpd.conf лучшее, что вы можете сделать - это постоянные ссылки pathinfo. Постоянные ссылки Pathinfo такие же, как симпатичные постоянные ссылки, за исключением того, что они начинаются с index.php.

Чтобы использовать постоянные ссылки pathinfo, поместите index.php/в начало вашей пользовательской структуры постоянных ссылок:

/index.php/%postname%/

Смотрите статью Кодекса для получения дополнительной информации.

2
Chris_O

В старые добрые времена WordPress нужно было писать новый файл конфигурации каждый раз, когда вы меняли структуру постоянных ссылок. В современных установках RewriteRules неизменны:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Все запросы на несуществующие файлы (т. Е. Пользовательский постоянный путь, который не соответствует файлу в файловой системе) передаются через index.php, и $_SERVER['REQUEST_URI'] сообщает PHP, что фактически было запрошено. Ваш клиент может установить правила перезаписи в httpd.conf или .htaccess, и вам не нужно будет изменять его при настройке структуры постоянной ссылки.

Некоторые плагины пытаются сами изменить .htaccess или просят вас изменить файл. Это решение может быть не для всех, но стоит задуматься.

0
Annika Backstrom