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

<p>у меня есть клиент, который настоятельно предпочитает отключать файлы .htaccess, потому что им нравится устанавливать конфигурации apache самостоятельно. тем не менее, они все еще хотят seo-дружественные url.</p><p>есть ли способ иметь пользовательские постоянные ссылки без файла .htaccess? мои исследования до сих пор, кажется, показывают, что это невозможно, но, возможно, один из блестящих разработчиков знает, как казалось бы невозможное возможно. заранее спасибо!</p>

<p>привет<strong> @mike lee </strong>:</p><p>чтобы ответить на ваш вопрос, полезно понять, как все работает.</p><h3>apache обслуживает url-адреса, которые соответствуют файлам и каталогам</h3><p>apache предназначен для обслуживания файлов, явно совпадающих с url, или для обслуживания <code>index.php</code>, найденного в каталоге, когда каталог явно совпадает.</p><h3>но apache может обслуживать url-адреса, соответствующие regex с <code>mod\_rewrite</code></h3><p>если вы хотите, чтобы apache соответствовал url-адресам, для которых нет реальных каталогов (в случае с wordpress и довольно постоянными ссылками), то у вас должен быть какой-то способ рассказать apache, как обрабатывать url-адреса по-разному. и это именно то, что <code>mod\_rewrite</code> был разработан, чтобы позволить; это дает администраторам серверов возможность устанавливать правила для сопоставления url-адресов с помощью регулярных выражений. эти правила направляют результат на другие url-адреса, часто включая фактически файлы <code>.php</code>, а иногда и передаваемые параметры url-адреса. в конечном итоге правила определяют, что загружаются реальные файлы.</p><h3>и <code>mod\_rewrite</code> конфигурируется с <code>.htaccess</code> или <code>httpd.conf</code></h3><p>для настройки <code>mod\_rewrite</code> вы можете сделать это только внутри <code>.htaccess</code> или внутри файла <code>httpd.conf</code> или одного из включаемых в него файлов, например, потенциально <code>httpd-vhosts.conf</code>. на самом деле, я удивлен, если у вашего клиента есть навыки для управления apache, что они этого еще не знают.</p><h3>wordpress всегда использует один и тот же простой файл <code>.htaccess</code></h3><p>переходя к тому, что делает wordpress, когда вы устанавливаете постоянные ссылки, wordpress записывает следующее в файл <code>.htaccess</code>, предполагая, что он доступен для записи (<em>и в этом первом примере, если ваш сайт обслуживается из корня</em>):</p><pre><code># 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> </code></pre><h3>wordpress перенаправляет все url-адреса, не соответствующие файлам и каталогам, в <code>index.php</code></h3><p>итак, как вы можете видеть, единственное, что wordpress использует для <code>.htaccess</code>, - это сопоставление<strong> <em>любого</em> </strong>url-адреса домена к <code>/index.php</code> (или <code>/blog/index.php</code> во втором примере)<strong> <em>кроме</em> </strong>когда url соответствует фактическому файлу (например, <code>.jpg</code>/<code>.gif</code>/<code>.png</code> image, таблице стилей <code>.css</code>, сценарию <code>.js</code> и т. д.) или когда он соответствует фактическому каталогу (который, насколько я знаю, не относится к стандартной установке wordpress.)</p><h3>в <code>php</code> разборы wordpress <code>$_server['request_uri'] чтобы решить, что загрузитьвнутри своего php кода wordpress получает значение $\_server['request\_uri']</code>, которое содержит полный url-запрос <em>sans</em> домен и схему (т. е. схема <code>http</code> или <code>https</code>), и затем анализирует значение, чтобы определить, какой url был запрошен и, следовательно, что страницы это должно загрузить.</p><h3>в обход <code>.htaccess</code>? получить apache для загрузки виртуальных url-адресов (но удачи с этим!)</h3><p>поэтому, если вы хотите каким-то образом обойти <code>.htaccess</code>, ваша задача - заставить apache отвечать на произвольный url, затем загрузить wordpress и установить <code>$_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> </code></pre><h3>бонус! с блокировкой приходит производительность</h3><p>этот последний вариант должен устранить любой <code>.htaccess</code> и вернуть контроль в свои руки. более того, он немного более производительный, поскольку <code>httpd.conf</code> загружается только один раз при запуске apache, но<strong> <em><code>.htaccess</code> файлы загружаются и анализируются при каждом запросе url!</em> </strong></p><p>постскриптум еще одна вещь, которую следует учитывать, - это<strong> внешний apache с кэширующим сервером, например <a href="http://nginx.org/">nginx</a> </strong>, который, я считаю, становится <a href="http://technosailor.aaronbrazell.com/2010/07/29/back-in-startup-mode-announcing-wp-engine/">лучшей практикой для сайтов wordpress с большим трафиком</a> которые действительно должны быть исполнительным. это может потребовать настройки зеленого поля, потому что я не думаю, что большинство людей использовали nginx для переписывания url-адресов для apache, но если вас интересует это направление, вот несколько ссылок:</p><ul> <li> <a href="http://wordpress.org/extend/plugins/nginx-proxy-cache-integrator/">интегратор кеша wordpress nginx</a> </li> <li> <a href="http://www.saltycrane.com/blog/2009/11/using-nginx-caching-proxy-wordpressapache/">использование nginx в качестве кеширующего прокси с wordpress + apache</a> </li> <li> <a href="http://blogs.law.harvard.edu/djcp/2010/01/nginx-as-a-front-end-proxy-cache-for-wordpress/">nginx как внешний прокси-кеш для wordpress</a> </li> <li> <a href="http://ocaoimh.ie/wordpress-nginx-wp-super-cache/">wordpress, nginx и wp super cache</a> </li> <li> <a href="http://blog.hybridindie.com/2010/02/16/nginx-wordpress-mu-w-wp-super-cache/">nginx и wordpress mu с wp-супер-кэшем</a> </li> <li> <a href="http://tech.nocr.at/tech/how-to-speed-up-wordpress-with-nginx-and-wp-super-cache/">как ускорить wordpress с помощью nginx и wp super cache</a> </li> <li> <a href="http://wpveda.com/nginx-rewrite-rules-for-w3-total-cache-plugin/">правила перезаписи nginx для плагина w3 total cache</a> </li> <li> <a href="http://vpsbible.com/content-management/configure-nginx-wordpress/">настройка nginx для wordpress - красивые url & wp super cache</a> </li> </ul>

<p><strong> постоянные ссылки без mod\_rewrite </strong></p><p>без файла .htaccess и без изменения файла httpd.conf лучшее, что вы можете сделать - это постоянные ссылки pathinfo. постоянные ссылки pathinfo такие же, как симпатичные постоянные ссылки, за исключением того, что они начинаются с index.php.</p><p>чтобы использовать постоянные ссылки pathinfo, поместите index.php/в начало вашей пользовательской структуры постоянных ссылок:</p><pre><code>/index.php/%postname%/ </code></pre><p>смотрите <a href="http://codex.wordpress.org/using\_permalinks#permalinks\_without\_mod\_rewrite">статью кодекса</a> для получения дополнительной информации.</p>

<p>в старые добрые времена wordpress нужно было писать новый файл конфигурации каждый раз, когда вы меняли структуру постоянных ссылок. в современных установках rewriterules неизменны:</p><pre><code># begin wordpress <ifmodule mod\_rewrite.c> rewriteengine on rewritebase / rewritecond %{request\_filename} !-f rewritecond %{request\_filename} !-d rewriterule . /index.php [l] </ifmodule> # end wordpress </code></pre><p>все запросы на несуществующие файлы (т. е. пользовательский постоянный путь, который не соответствует файлу в файловой системе) передаются через index.php, и <code>$\_server['request\_uri']</code> сообщает php, что фактически было запрошено. ваш клиент может установить правила перезаписи в httpd.conf или .htaccess, и вам не нужно будет изменять его при настройке структуры постоянной ссылки.</p><p>некоторые плагины пытаются сами изменить .htaccess или просят вас изменить файл. это решение может быть не для всех, но стоит задуматься.</p>