Использование постоянных ссылок «WordPress Codex

1. Постоянная ссылка Типы
2. По умолчанию: «Гадкий»
3. mod_rewrite: "Красивые постоянные ссылки"
4. ПАТИНФО: «Почти красиво»
5. Выбор вашей структуры постоянных ссылок
6. Использование «милых» постоянных ссылок
7. Где мой файл .htaccess?
8. Создание и редактирование (.htaccess)
9. Автоматическое обновление .htaccess
10. Постоянные ссылки без mod_rewrite
11. Исправление проблем с постоянными ссылками
12. Постоянные ссылки, .htaccess и MS Frontpage
13. Быстрые исправления, главная страница или постоянные ссылки
14. Использование FrontPage и постоянные ссылки вместе
15. Длинные постоянные ссылки
16. Исправление других проблем
17. Дополнительная справка
18. Секреты и уловки
19. Проверьте структуру постоянных ссылок

Языки : Английский • Français • 日本語 한국어 • ລາວ • Мьянма • Nederlands • Português do Brasil • ไทย • 中文 (简体) • 中文 (繁體) • ( Добавьте свой язык )

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

Постоянная ссылка Типы

Существует три основных типа постоянных ссылок WordPress:

По умолчанию: «Гадкий»

По умолчанию выглядит

http://example.com/?p=N

где N - номер почтового идентификатора. Он работает во всех серверных средах, но выглядит не так хорошо, как некоторые другие опции.

mod_rewrite: "Красивые постоянные ссылки"

Используя mod_rewrite или lighttpd, вы можете создавать намного более приятные постоянные ссылки (см. Довольно постоянные ссылки ). Существует много разных форматов, но самый распространенный и универсальный выглядит

http://example.com/2012/post-name/

или же

http://example.com/2012/12/30/post-name

Довольно постоянные ссылки доступны в:

• Веб-сервер Apache с модулем mod_rewrite
• Веб-сервер Hiawatha с поддержкой UrlToolkit.
• Веб-сервер Microsoft IIS 7+ с модулем URL Rewrite 1.1+ и PHP 5, работающим как FastCGI
• Microsoft IIS 6+ с использованием ASAPI_Rewrite (бесплатно для сервера с одним сайтом, $$ для сервера с несколькими сайтами)
• Microsoft IIS 6+ с использованием Ионный фильтр перезаписи ISAPI (IIRF) (бесплатно для одного или нескольких сайтов)
• Lighttpd используя обработчик 404
• Nginx использует try-файлы, например, согласно этому руководство
• Кэдди, используя переписать, например, в соответствии с этим руководство

ПАТИНФО: «Почти красиво»

Постоянные ссылки PATHINFO очень похожи на постоянные ссылки mod_rewrite, но с одним исключением: перед ними вставлен /index.php, например:

http://example.com/index.php/yyyy/mm/dd/post-name/

В остальном они такие же, как и у «симпатичных» постоянных ссылок mod_rewrite, и аналогично гибкие. Все, что могут сделать постоянные ссылки mod_rewrite, могут сделать постоянные ссылки PATHINFO с помощью этой части /index.php.

Выбор вашей структуры постоянных ссылок

На экране «Настройки» → «Постоянные ссылки» вы можете выбрать одну из наиболее распространенных структур постоянных ссылок или ввести свою собственную в поле «Пользовательская структура» с помощью тегов структуры .

Обратите внимание: вы не помещаете URL своего сайта в поля постоянных ссылок. Вы используете только один из тегов структуры или комбинацию тегов.

Чтобы активировать постоянные ссылки PATHINFO, начните свою структуру постоянных ссылок с index.php /.

Вы можете использовать эти теги, чтобы настроить постоянные ссылки "Pretty" или "Pretty Pretty". Несколько подсказок:

• Вы не помещаете URL своего сайта в поля постоянных ссылок. Вы используете только один из тегов структуры или комбинацию тегов.
• Обязательно добавьте в свою структуру% post_id% или% postname% (например, /% year% /% monthnum% /% day% /% postname% /), чтобы каждая постоянная ссылка указывала на отдельный пост.

% year% Год поста, четыре цифры, например, 2004% monthnum% Месяц года, например, 05% day% День месяца, например, 28% hour% Час дня, например 15% minute % Минута часа, например 43% секунда% Секунда минуты, например 33% post_id% Уникальный идентификатор # сообщения, например, 423% postname% Обеззараженная версия заголовка сообщения (поле post slug на панели редактирования сообщения / страницы). Таким образом, «Это великий пост!» Становится таким же великим постом в URI. % category% Обеззараженная версия имени категории (поле слагаемой категории на панели «Создать / Изменить категорию»). Вложенные подкатегории отображаются в виде вложенных каталогов в URI. % author% Обеззараженная версия имени автора.

База категорий и база тегов - это префиксы, используемые в URL для архивов категорий и тегов, которые выглядят следующим образом:

example.net/wp/category_base/category_name example.net/wp/tag_base/tag_name

Значениями по умолчанию для них являются категория и тег. Вы можете изменить их, но не можете полностью удалить их из URL.

Пользовательские постоянные ссылки работают на большинстве систем без каких-либо проблем, но все же есть некоторые условия, в которых возникают проблемы.

Когда вы присваиваете нескольким категориям сообщение, в постоянной ссылке может отображаться только одна категория. Категории упорядочены по алфавиту. В каждой группе подкатегорий порядок также будет в алфавитном порядке. (увидеть Управление категориями ). Пост будет по-прежнему доступен для всех категорий в обычном режиме.

Попробуйте WP Category Постоянная ссылка плагин, если вы хотите выбрать, какая категория отображается в постоянной ссылке.

Использование «милых» постоянных ссылок

Требования:

• Веб-сервер Apache с установленным модулем mod_rewrite
• В домашнем каталоге WordPress,
  • Опция FollowSymLinks включен
  • Директивы FileInfo разрешено (например, AllowOverride FileInfo или AllowOverride All)
  • Файл .htaccess (если этот файл отсутствует, WordPress попытается создать его, когда вы активируете «красивые» постоянные ссылки)
  • Если вы хотите, чтобы WordPress автоматически обновлял файл .htaccess, WordPress понадобится доступ для записи в файл.

• За Nginx веб-сервер, нацеленный на высокий уровень параллелизма, высокую производительность и низкое использование памяти, добавляет следующий блок местоположения в блоке сервера:

location / {try_files $ uri $ uri / /index.php?$args; }

• За Гайавата веб-сервер, уделяющий большое внимание безопасности, использует следующее правило UrlToolkit:

UrlToolkit {ToolkitID = wordpress RequestURI существует. Return Match. * \? (. *) Переписать /index.php?$1 Match. * Переписать /index.php}

• Пользователи Mac, использующие WordPress локально, должны отредактировать свой файл httpd.conf, отредактировав строку AllowOverride, чтобы прочитать инструкции хоста AllowOverride All в каталоге "/ Library / WebServer / Documents" . Для Mac OS X 10.5.x и выше этот файл находится в /private/etc/apache2/users/[your-username].conf, в противном случае он находится в /etc/httpd/httpd.conf.

Когда вы создаете или обновляете «симпатичную» структуру постоянных ссылок, WordPress генерирует правила перезаписи и пытается вставить их в соответствующий файл .htaccess. Если этого не произойдет, он скажет что-то вроде «Вы должны обновить ваш .htaccess сейчас и распечатать правила для вас, чтобы скопировать и вставить в файл (поместите их в конце).

В версиях WordPress 2.0+ вам, вероятно, потребуется сделать это только один раз, потому что WordPress выполняет внутреннюю переписывание. Если вы когда-нибудь переместите свой домашний каталог WordPress ( адрес сайта ), вам придется повторить этот шаг.

WordPress будет хорошо играть с существующим .htaccess и не будет удалять существующие RewriteRules или другие директивы. Если у вас есть другие правила mod_rewrite, поставьте свои перед WordPress.

Где мой файл .htaccess?

Файлы WordPress index.php и .htaccess должны находиться вместе в каталоге, указанном настройкой адреса сайта (URL) на странице общих параметров. Поскольку имя файла начинается с точки, файл может быть не виден через клиент FTP, если вы не измените настройки инструмента FTP, чтобы показать все файлы, включая скрытые файлы. Некоторые хосты (например, Godaddy) могут не отображать или не разрешать вам редактировать .htaccess, если вы устанавливаете WordPress через установку Godaddy Hosting Connection.

Создание и редактирование (.htaccess)

Если у вас еще нет файла .htaccess, создайте его. Если у вас есть доступ к серверу с помощью shell или ssh, простая команда прикосновения .htaccess создаст файл. Если вы используете FTP для передачи файлов, создайте файл на локальном компьютере, назовите его 1.htaccess, загрузите его в корневой каталог WordPress и затем переименуйте в .htaccess.

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

Следующий постоянный код перезаписи должен быть включен в ваш файл .htaccess (начиная с WordPress 3.0 ):

# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine Включено в RewriteBase / RewriteRule ^ index \ .php $ - [L] RewriteCond% {REQUEST_FILENAME}! -F RewriteCond% {REQUEST_FILENAME}! -D RewriteRule. /index.php [L] </ IfModule> # КОНЕЦ WordPress

Если ваш файл .htaccess содержит ошибки, которые приводят к остановке вашего сайта («Внутренняя ошибка сервера (500)»), вам нужно будет использовать FTP или хост панель управления удалить мошеннический файл .htaccess.

Автоматическое обновление .htaccess

Если WordPress не может автоматически обновить ваш файл .htaccess, он скажет вам что-то вроде: Если ваш файл .htaccess доступен для записи, мы можем сделать это автоматически, но это не… в нижней части экрана «Настройки» → «Постоянные ссылки».

Если вы хотите, чтобы WordPress делал это, вам нужно дать WordPress доступ для записи в файл .htaccess , Точные необходимые разрешения зависят от настроек вашего сервера. Попробуйте добавить разрешения на запись для владельца, затем группы, затем мира, тестирование после каждого изменения; После того, как WordPress успешно отредактировал файл, не добавляйте никаких дополнительных разрешений на запись.

После применения постоянных ссылок вы должны изменить разрешения на что-то более сильное, например 660 или 644, чтобы другие серверы не могли получить к нему доступ.

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

«Красивые» постоянные ссылки обычно требуют mod_rewrite и IIS (распространенный на серверах Windows) не поддерживает mod_rewrite. (Если вы используете Apache 2.0.54, в Windows может работать mod_rewrite, если он включен в apache \ conf \ httpd.conf.)

Если вы используете IIS 7 и имеете права администратора на своем сервере, вы можете использовать Microsoft Модуль перезаписи URL вместо. Хотя он не полностью совместим с mod_rewrite, он поддерживает довольно постоянные ссылки WordPress. После установки откройте файл web.config в папке WordPress и добавьте следующее правило в элемент system.webServer.

&lt;? xml version = "1.0" encoding = "UTF-8"?> <configuration> <system.webServer> <rewrite> <rules> <rule name = "Правило WordPress" stopProcessing = "true"> <match url = " . * "/> <условия> <add input =" {REQUEST_FILENAME} "matchType =" IsFile "negate =" true "/> <add input =" {REQUEST_FILENAME} "matchType =" IsDirectory "negate =" true "/> </ condition> <action type = "Rewrite" url = "index.php" /> </ rule> </ rules> </ rewrite> </system.webServer> </ configuration>

Есть полное руководство по установке на сайте IIS. Модуль доступен для x64 а также x86 системы.

Если это не вариант, вы можете попробовать постоянные ссылки PATHINFO; поместите index.php / в начало вашей пользовательской структуры постоянной ссылки:

/index.php/%year%/%monthnum%/%day%/%postname%/

Эта опция может не всегда работать, особенно в случаях, когда WordPress работает на IIS 6. Чтобы эта опция работала на IIS, добавьте эти две строки в файл php.ini и сохраните этот файл в своем корне:

cgi.fix_pathinfo = 1 cgi.force_redirect = 0

Другое решение существует с использованием пользовательских перенаправлений 404 IIS. Это требует, чтобы ваш веб-хост позволял вам добавить пользовательский редирект 404, но не требует установки какого-либо стороннего программного обеспечения mod_rewrite, а также не требует, чтобы ваша структура постоянных ссылок начиналась с /index.php/.

Исправление проблем с постоянными ссылками

Исправление проблем генерации .htaccess

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

1. Изменить права доступа к файлам: необходимо CHMOD файл .htaccess для 666, чтобы редактировать его с помощью WordPress редактор шаблонов , но это не рекомендуется, так как если вы это сделаете, любой пользователь вашего блога, который может редактировать шаблоны, сможет его редактировать. Вы можете изменить разрешения на 660, чтобы сделать их доступными для записи на сервере, что опять-таки будет иметь те же ограничения.
2. Блокировка сервера: Ваш хост мог заблокировать переменную SERVER_SOFTWARE, и это приведет к сбою генерации WordPress .htaccess. Если вы уверены, что на вашем сервере работает Apache, вы можете заставить WordPress полагать, что на вашем сервере работает Apache, изменив файл wp-includes / vars.php. Выполните следующие шаги для реализации этих изменений.
   • Откройте файл wp-includes / vars.php, используя встроенный редактор файлов в панели администратора WordPress. Чтобы перейти на эту панель, войдите в WordPress, нажмите «Управление», затем «Файлы», прокрутите до конца и введите wp-includes / vars.php в текстовое поле под заголовком «Другие файлы». Ищите $ is_apache = strstr ($ _ SERVER ['SERVER_SOFTWARE'], 'Apache')? 1: 0; и заменить его на // $ is_apache = strstr ($ _ SERVER ['SERVER_SOFTWARE'], 'Apache')? 1: 0;
   • Добавить новую строку в раздел // $ is_apache = strstr ($ _ SERVER ['SERVER_SOFTWARE'], 'Apache')? 1: 0; и введите $ is_apache = 1;
3. Пользователи XAMPP (Windows): некоторые версии XAMPP не включайте mod_rewrite по умолчанию (хотя он скомпилирован в Apache). Чтобы включить его - и, таким образом, включить WordPress для записи файла .htaccess, необходимого для создания красивых постоянных ссылок, - вы должны открыть apache / conf / httpd.conf и раскомментировать строку LoadModule rewrite_module modules / mod_rewrite.so (т. Е. Удалить знак хеш / фунт) в передней части линии).
4. Пользователи WAMP (Windows): Некоторые версии WAMP (все версии?) Не включают mod_rewrite или не разрешают использовать SymLinks по умолчанию. Чтобы включить необходимые функции, перейдите к файлу apache / conf / httpd.conf, откройте его с помощью текстового редактора и раскомментируйте строку LoadModule rewrite_module modules / mod_rewrite.so (т. Е. Удалите знак хеш / фунт в начале строки). Далее далее в том же файле есть раздел, который начинается со строки «Опции FollowSymlinks». Измените вторую строку в этом разделе с «AllowOverride none» на AllowOverride all. Сохраните отредактированный httpd.conf и перезапустите все модули WAMP. Ваши постоянные ссылки теперь должны работать.

Постоянные ссылки, .htaccess и MS Frontpage

Примечание о Microsoft Frontpage: многие серверы (общие и выделенные), поддерживаемые и созданные различными хостинговыми компаниями, поставляются с mod_frontpage, скомпилированным со сборкой apache, а во многих случаях с установленными серверными расширениями Frontpage, на каждом виртуальном сервере. Это более распространено, чем нет, многие / большинство бинарных дистрибутивов, используемых в процессе сборки серверов в большинстве хостинговых компаний в наши дни, включают как mod_fronpage, так и расширения сервера. Даже если вы не используете Frontpage, из-за того, как расширения взаимодействуют с apache (и файлом httpd.conf), вы, скорее всего, получите что-то вроде ошибки 500 или пустую белую страницу при попытке просмотреть вашу установку WP (хотя панель администратора может работать правильно) просто потому, что на вашем сервере существуют расширения / mod_frontpage.

WordPress будет работать правильно с установленными расширениями Frontpage, однако постоянные ссылки не будут работать вообще, и ЛЮБОЕ изменение раздела постоянных ссылок из интерфейса администратора WordPress приведет к повреждению серверных расширений Frontpage из-за добавления правил mod_rewrite в файл .htaccess. , Однако сейчас есть исправление для этой ситуации.

Быстрые исправления, главная страница или постоянные ссылки

Исправление расширений Frontpage: Если вам не нужны постоянные ссылки и вы просто хотите, чтобы расширения сервера MS Frontpage снова работали, просто отредактируйте ваш файл .htaccess и удалите раздел WordPress с правилами перезаписи.

Использование постоянных ссылок: если вам не важна Frontpage (но в вашей хостинговой компании установлены расширения)

Вам нужно будет удалить (или сделать так, чтобы ваша хостинговая компания) серверные расширения MS Frontpage или просто отредактировать файл .htaccess, чтобы удалить все линии Frontpage, оставив только код WordPress mod_rewrite.

Использование FrontPage и постоянные ссылки вместе

Наконец, решение.

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

Обычно на Unix-сервере с установленными расширениями Microsoft FrontPage Server WordPress работает очень хорошо, и вы можете редактировать и публиковать страницы (с Microsoft FrontPage ) - до - вы вносите изменения в постоянные ссылки (например, в вид, основанный на дате, который мне нравится / 2005/04 / etc). Я часто предлагаю этот тип URI людям, спрашивающим о постоянных ссылках и т. Д., Так как этот метод рекомендован w3c (см. http://www.w3.org/Provider/Style/URI ).

Теперь проблема заключается в том, что FrontPage использует файл .htaccess (к которому должны иметь доступ правила WordPress mod_rewrite) для своей конфигурации «публикации» и «веб-авторинга». Как только код WordPress mod_rewrite добавляется в файл, происходят две вещи - постоянные ссылки не работают и расширения сервера Frontpage становятся поврежденными.

Я пробовал множество способов обойти это, в том числе пытаясь использовать правила перезаписи, которые «игнорируют»% {HTTP_USERAGENT)%, используемый FrontPage, чтобы использовать второй AccessFilename .wpaccess для файла httpd.conf, и множество других вещей. и ничто не помогло одновременно использовать FrontPage, а также управление и использование постоянных ссылок в WordPress.

Решение на самом деле простое, и я понял это случайно.

Если вы используете или хотите использовать FrontPage (или если ваш хостинг-пакет предварительно настроен таким образом) вместе с WordPress, вам нужно будет выполнить следующие простые шаги на вашем сервере, или ваша хостинговая компания сделает их за вас.

Microsoft FrontPage создает следующий каталог

_vti_bin Вложенный внутри, он создает и _vti_adm и _vti_aut

В дополнение к корневой папке вашего сайта (или WordPress) во всех этих каталогах вы найдете дополнительные файлы .htaccess.

Во всех трех этих каталогах И в корневом каталоге, в верхней части ВСЕХ файлов .htaccess, вам просто нужно добавить одну строку:

Опции + FollowSymlinks

В каждом из них может быть строка, а может и нет

Варианты Нет

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

Длинные постоянные ссылки

При использовании сверхдлинных постоянных ссылок в электронной почте и публикации в комментариях и чатах некоторые длинные постоянные ссылки «обрезаются» или только первый раздел фактически распознается как ссылка, а конец воспринимается как текст. Вот пример.

Может привести к:

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

1. Убедитесь, что вы действительно используете постоянные ссылки .

2. Отредактируйте ваш файл .htaccess и добавьте следующее:

RewriteRule ^ post / ([0-9] +)? /? ([0-9] +)? /? $ /Index.php?p=$1&page=$2 [QSA]

3. Проверьте это. Найдите идентификационный номер поста и введите следующее (с вашей информацией) в браузере, и вы будете перенаправлены на ваш пост:

http://yourdomain.example.com/post/( ID #)

Стоит также отметить, что большинство почтовых программ не будут обрезать URL-адреса, которые были обозначены угловыми скобками (<и>), поэтому при вставке URL-адресов в электронные письма вы должны написать их так:

Кроме того, некоторые приличные почтовые клиенты предлагают опцию «preformat» при составлении текстовых писем. Использование опции «preformat» при вставке ссылок заставит почтовый клиент не вставлять разрывы строк внутри ссылок.

Исправление других проблем

Если ваш файл .htaccess генерируется правильно, но постоянные ссылки по-прежнему не работают, могут возникнуть следующие проблемы. Если проблемы сохраняются, оставьте запись в WordPress Форум Как раздел.

AllowOverride не включен

Ваш сервер может не иметь включенной директивы AllowOverride. Если в вашем файле Apache httpd.config для директивы AllowOverride установлено значение None, то файлы .htaccess полностью игнорируются. В этом случае сервер даже не будет пытаться прочитать файлы .htaccess в файловой системе. Когда для этой директивы установлено значение All, любая директива, имеющая контекст .htaccess, разрешена в файлах .htaccess. Пример включенной директивы AllowOverride в httpd.config: <Directory /> Параметры FollowSymLinks AllowOverride All </ Directory>

Вам также может понадобиться включить директиву AllowOverride в вашем DocumentRoot:

<Directory / var / www / html> # ... другие директивы ... AllowOverride All </ Directory> Возможно, вам также придется изменить настройки AllowOverride для сайта. Это, безусловно, имеет место при использовании Mac OS X Server, но может быть и в других системах. Обычно вы можете найти файлы конфигурации сайта в / etc / httpd / sites /. Если вы не хотите устанавливать AllowOverride для всех (как указано выше), тогда ваш список AllowOverride должен включать директиву FileInfo. Вы должны перезапустить сервер Apache, чтобы изменения в файле httpd.config вступили в силу. Для получения дополнительной информации о том, какие переопределения разрешены, читайте о Основные возможности Apache , Постраничная навигация не работает Иногда навигация по вторым (и последующим) страницам сообщений не работает должным образом. Ваша страница может генерировать ссылку на страницу с одним из этих URI: http://www.example.com/page/2/ http://www.example.name/category/categoryname/page/2/ http: / /www.example/year/month/day/page/2/ http: //www.example/year/month/page/2/ В результате нажатия одной из этих ссылок страница загружается со всем окружением (заголовок , нижний колонтитул, боковая панель), но вместо страницы сообщений появляется сообщение об ошибке: «Извините, ни один пост не соответствует этому критерию». Это происходит из-за сбоя в файле .htaccess, который генерирует WordPress. Чтобы исправить это, удалите содержимое файла .htaccess и заново создайте его.

1. В Панели управления перейдите в Управление> Файлы ( Подробнее о редактировании файлов )
2. Нажмите на ссылку на ваш файл .htaccess, чтобы отредактировать его содержимое.
3. Скопируйте содержимое файла и вставьте его в текстовый файл в текстовом редакторе. Это мера предосторожности, если в вашем файле .htaccess есть записи для перенаправлений, отказов или других данных. удобные приемы htaccess
4. Удалите все содержимое из файла .htaccess и нажмите кнопку «Обновить файл».
5. На панели управления выберите «Параметры»> «Постоянные ссылки».
6. Нажмите кнопку Обновить структуру постоянных ссылок, чтобы заново сгенерировать новые правила перезаписи для ваших постоянных ссылок.
7. Проверьте результаты, используя ранее сломанную ссылку.
8. Добавьте любые записи htaccess вручную обратно в ваш файл (поместите записи htaccess вручную до # BEGIN WordPress или после # END строк WordPress.)

Вы также можете выполнить аналогичные шаги, удалив файлы .htaccess с сервера, создав новый пустой файл .htaccess, изменив его разрешения на 666, а затем в меню «Параметры»> «Постоянные ссылки» создайте новый набор правил htaccess, нажав кнопку «Обновить структуру постоянных ссылок». , Иногда пользователи определяют одну точку (.) Как базу категорий, чтобы полностью исключить базу категорий из полученного URL. Если это так с вашей настройкой, попробуйте заменить точку реальным словом. «категория», «читать», «кошка», «полезный» - вот несколько хороших предложений. Если это все еще не работает, посмотрите на форумах поддержки WordPress, в частности, этот пост поддержки , Постоянные ссылки на страницы не работают, если вы пытались перейти на вновь созданный страница и возникнет ошибка, вам, вероятно, нужно обновить структуру постоянных ссылок , Помните, что каждый раз, когда вы добавляете новую статическую страницу в WordPress, новые правила должны быть сгенерированы и обновлены до .htaccess (WordPress 1.X) или во внутренний массив перезаписей (WordPress 2.X). Постоянные ссылки на страницы тегов Ultimate Tag Warrior не работают Если вы получаете 404 ошибки на локальных URL-адресах тегов при использовании плагина UltimateTagWarrior в WordPress 2.X, это происходит из-за того, что внутренние перезаписи, сгенерированные WordPress, являются чрезмерно жадными и вызываются до того, как правила перезаписи UTW Иметь шанс. Обычно это происходит только при использовании пользовательской структуры постоянных ссылок (например, /% postname% /). Чтобы исправить это, либо поменяйте структуру постоянных ссылок на «Дата и имя на основе» или взломать плагин UTW, чтобы поместить переписываемые UTW вверху внутреннего массива перезаписей. Постоянные ссылки работают, но страницы не возвращаются. В некоторых версиях PHP 4.4.x и 5.x есть ошибка, которая приводит к сбою mod_rewrite при использовании с некоторыми версиями Apache 2.x. Более подробная информация на http://bugs.php.net/bug.php?id=35096 а также http://bugs.php.net/bug.php?id=35059 ,

Дополнительная справка

Если эти шаги не работают, найдите вашу проблему в кодекс , Поиск проблемы или в Форум поддержки , В крайнем случае, подать отчет об ошибке ,

Секреты и уловки

Как избежать интерпретации как ссылки на архив

Обратите внимание, что даже если вы никогда не сделаете более одной публикации в день и, таким образом, захотите использовать, например,% year %% monthnum %% day%, созданные таким образом ссылки будут, тем не менее, интерпретироваться как архив всех сообщений за этот день. Нужно как минимум% year %% monthnum %% day %% hour% для таргетинга на отдельную запись.

Проверьте структуру постоянных ссылок

Способ проверить, имеет ли блог постоянную структуру:

&lt;? php if (get_option ('permalink_structure')) {echo 'постоянные ссылки включены'; }?>

Смотрите также

Похожие

Комментарии