Використання Permalinks «Кодекс WordPress

1. Типи постійної посилання
2. За замовчуванням: "Ugly"
3. mod_rewrite: "Pretty Permalinks"
4. ПАТІНФО: "Майже гарна"
5. Вибір структури постійної посилання
6. Використання "Pretty" постійні посилання
7. Де мій файл .htaccess?
8. Створення та редагування (.htaccess)
9. Автоматичне оновлення .htaccess
10. Постійне посилання без mod_rewrite
11. Виправлення неполадок Постійне посилання
12. Постійне посилання, .htaccess та MS Frontpage
13. Швидкі виправлення, Frontpage або Permalinks
14. Використання FrontPage І Permalinks разом
15. Довгострокові посилання
16. Виправлення інших проблем
17. Додаткова допомога
18. Поради та підказки
19. Перевірте структуру постійної лінії

Мови : Англійська • Français • 日本語 한국어 • ລາວ • М'янма • Nederlands • Português do Brasil • ไทย • 中文 () • 中文 () • ( Додайте свою мову )

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

Типи постійної посилання

Існують три основні типи постійних WordPress:

За замовчуванням: "Ugly"

Типовим виглядає

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

де N - номер ідентифікатора повідомлення. Він працює на всіх серверних середовищах, але він не виглядає так добре, як деякі інші варіанти.

mod_rewrite: "Pretty Permalinks"

Використовуючи 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-files, наприклад, відповідно до цього підручник
• Caddy використовує перезапис, наприклад, відповідно до цього підручник

ПАТІНФО: "Майже гарна"

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

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

В іншому випадку, вони такі ж, як "досить" mod_rewrite permalinks, і аналогічно гнучкі. Все, що mod_rewrite Постійне посилання може зробити, PATHINFO Постійне посилання може зробити, за допомогою цієї / index.php частини.

Вибір структури постійної посилання

На екрані "Налаштування" → "Постійне посилання" можна вибрати одну з найбільш поширених структур постійної посилання або ввести власне в полі "Власна структура" за допомогою тегів структури .

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

Щоб активувати постійні посилання PATHINFO, запустіть структуру постійної посилання з index.php /.

Ви можете використовувати ці теги, щоб налаштувати постійні посилання "Pretty" або "Almost Pretty". Кілька натяків:

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

% year% Рік публікації, чотири цифри, наприклад 2004% monthnum% Місяць року, наприклад 05% день% День місяця, наприклад 28% години% Годинник дня, наприклад, 15% хвилини % Хвилина години, наприклад, 43% секунд% Другої хвилини, наприклад 33% post_id% Унікальний ідентифікатор # публікації, наприклад 423% postname% Дезінфікована версія назви публікації (поле після публікації) на панелі редагування повідомлень / сторінок). Отже, «Це велика посада!» Стає цією посадою в URI. % category% Дезактивована версія назви категорії (поле slug категорій на панелі New / Edit Category). Вкладені підкатегорії відображаються як вкладені в URI. % author% Дезінфікована версія імені автора.

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

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

Типовими значеннями для них є категорія та тег. Ви можете змінити їх, але ви не можете повністю видалити їх з URL-адрес.

Користувальницькі permalinks працюють на більшості систем без будь-яких проблем, але все ще існують певні умови, де виникають проблеми.

При призначенні публікації декількох категорій лише одна може відображатися на постійній лінії. Категорії впорядковані за алфавітом. У кожній групі підкатегорій порядок також буде алфавітним. (подивитися Керувати категоріями ). Дописи будуть доступні через всі категорії як звичайно.

Спробуйте WP Категорія Постійне посилання плагін, якщо ви хочете вибрати, яка категорія відображається в постійній лінії.

Використання "Pretty" постійні посилання

Вимоги:

• Веб-сервер Apache з модулем mod_rewrite
• У домашньому каталозі WordPress,
  • The Опція FollowSymLinks увімкнено
  • Директиви FileInfo дозволено (наприклад, AllowOverride FileInfo або AllowOverride All)
  • Файл .htaccess (якщо цей файл відсутній, WordPress спробує створити його, коли ви активуєте "гарні" постійні посилання)
  • Якщо ви хочете, щоб WordPress автоматично оновлював файл .htaccess, WordPress потребуватиме доступу до файлу.

• Для nginx , веб-сервер, спрямований на високу конкурентоспроможність, високу продуктивність і низький рівень використання пам'яті, додати наступний блок розташування в блоці сервера:

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

• Для Hiawatha , веб-сервер із сильним акцентом на безпеці, використовуйте наступне правило UrlToolkit:

UrlToolkit {ToolkitID = wordpress RequestURI існує Return Match. * (. *) Переписати /index.php?$1 Match. * Rewrite /index.php}

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

Коли ви створюєте або оновлюєте "гарну" структуру постійної посилання, WordPress генеруватиме правила перезапису і намагатиметься вставити їх у відповідний файл .htaccess. Якщо це неможливо, він скаже щось на зразок Ви повинні оновлювати свій .htaccess зараз і роздрукувати правила для вас, щоб скопіювати і вставити у файл (покласти їх в кінці).

У версіях WordPress 2.0+, вам, ймовірно, доведеться робити це лише один раз, тому що WordPress виконує переписування внутрішньо. Якщо ви коли-небудь переміщуєте домашній каталог WordPress ( адреса сайту ), вам потрібно повторити цей крок.

WordPress відмінно гратиме з існуючим .htaccess і не буде видаляти існуючі RewriteRules або інші директиви. Якщо у вас є інші правила mod_rewrite, поставте їх перед WordPress.

Де мій файл .htaccess?

Файли індексу.php і .htaccess у WordPress повинні бути разом у каталозі, вказаному параметром Адреса сайту (URL) на сторінці Загальні параметри. Оскільки назва файлу починається з крапки, файл може бути невидимим через FTP-клієнт, якщо ви не зміните налаштування засобу FTP для показу всіх файлів, включаючи приховані файли. Деякі хости (наприклад, Godaddy) можуть не показувати або дозволяти редагувати .htaccess, якщо ви встановлюєте WordPress за допомогою установки Godaddy Hosting Connection.

Створення та редагування (.htaccess)

Якщо у вас ще немає файлу .htaccess, створіть його. Якщо ви маєте доступ до сервера, або просто ssh, простою командою touch.htaccess буде створено файл. Якщо ви використовуєте FTP для передачі файлів, створіть файл на локальному комп'ютері, зателефонуйте йому 1.htaccess, завантажте його в кореневу папку WordPress і перейменуйте його в .htaccess.

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

У вашому файлі .htaccess (починаючи з WordPress) повинен бути включений наступний код перезапису permalink 3.0 ):

# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine На RewriteBase / RewriteRule ^ index \ tphp $ - [L] RewriteCond% {REQUEST_FILENAME}! -F RewriteCond% {REQUEST_FILENAME}! -D RewriteRule. /index.php [L] </IfModule> # END 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 \ t

Якщо ви використовуєте IIS 7 і маєте права адміністратора на вашому сервері, ви можете використовувати Microsoft Модуль перезапису URL замість цього. Хоча це не повністю сумісна з mod_rewrite, вона підтримує досить постійні посилання WordPress. Після встановлення відкрийте файл web.config у папці WordPress і додайте наступне правило до елемента system.webServer.

&lt;? xml version = "1.0" encoding = "UTF-8"?> <configuration> <system.webServer> <виписка> <права> <назва правила = "Правило WordPress" stopProcessing = "true"> <match url = " . * "/> <conditions> <add input =" {REQUEST_FILENAME} "matchType =" IsFile "negate =" true "/> <додати вхід =" {REQUEST_FILENAME} "matchType =" IsDirectory "negate =" true "/> </conditions> <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, додайте ці 2 рядки до файлу php.ini та збережіть цей файл у вашому webroot:

cgi.fix_pathinfo = 1 cgi.force_redirect = 0

Інше рішення існує за допомогою переадресацій користувача 404 IIS. Це вимагає, щоб ваш веб-хост дозволив вам додати користувальницький переадресацію 404, але він не вимагає встановлення будь-якого програмного забезпечення mod_rewrite третьої сторони, і він також не вимагає, щоб ваша структура постійної посилання починалася з /index.php/.

Виправлення неполадок Постійне посилання

Виправлення проблем генерації .htaccess

Якщо ваша установка WordPress не генерує файл .htaccess, або якщо він не записує нові правила на ваш існуючий файл .htaccess, то є кілька причин, які можуть викликати це. Працюйте крок за кроком і переходьте до наступного кроку, лише якщо попередній крок не працює.

1. Зміна файлу Permissions: Ви повинні chmod файл .htaccess до 666, щоб редагувати його за допомогою WordPress редактор шаблонів , але це не рекомендується, оскільки, якщо ви це зробите, будь-який користувач вашого блогу, який може редагувати шаблони, зможе його редагувати. Ви можете змінити дозволи на 660, щоб зробити його доступним для запису на сервері, що знову ж таки матиме таке ж обмеження.
2. Блокування сервера. Можливо, ваш хост заблокував змінну SERVER_SOFTWARE, і це призведе до помилки генерації .htaccess у WordPress. Якщо ви впевнені, що ваш сервер працює з 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 (тобто видаліть знак хеш / фунт у передній частині рядка). Потім далі в тому ж файлі є розділ, який починається з рядка "Options FollowSymlinks". Змініть другий рядок у цьому розділі з "AllowOverride none" на AllowOverride all. Зберегти відредагований файл httpd.conf і перезапустити всі модулі WAMP. Ваші постійні посилання тепер повинні працювати.

Постійне посилання, .htaccess та MS Frontpage

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

WordPress працюватиме коректно з встановленими Frontpage Extensions, однак permalinks взагалі не будуть функціонувати, а будь-яка зміна в розділ постійних посилань з інтерфейсу адміністратора WordPress призведе до пошкодження розширень сервера Frontpage через додавання правил mod_rewrite до файлу .htaccess . Однак для цієї ситуації тепер є виправлення.

Швидкі виправлення, Frontpage або Permalinks

Виправлення передніх розширень: Якщо ви не дбаєте про постійні посилання і просто хочете, щоб розширення сервера MS Frontpage працювали знову, просто відредагуйте файл .htaccess і видаліть розділ WordPress з правилами перезапису.

Використовувати Постійне посилання: Якщо Ви не дбаєте про Frontpage (але ваша компанія хостингу має встановлені розширення)

Вам потрібно буде видалити (або зробити це з хостинговою компанією) розширень сервера MS Frontpage, або просто відредагувати файл .htaccess, щоб видалити всі лінії Frontpage, залишивши лише код модуля WordPress mod_rewrite.

Використання FrontPage І Permalinks разом

Нарешті, рішення.

На форумах підтримки було проведено низку тем, і до цих пір не було вирішення проблеми.

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

Тепер проблема полягає в тому, що FrontPage використовує файл .htaccess (який повинен мати доступ до правил WordPress mod_rewrite) для його "публікації" і "веб-авторизації" конфігурації. Як тільки код WordPress mod_rewrite буде додано до файлу, відбудеться дві речі - пермаленки не працюють, а розширення Frontpage Server пошкоджені.

Я пробую безліч способів обійти це, включаючи спроби використовувати правила перезапису, які "ігнорують"% {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. Переконайтеся, що ви дійсно використовуєте Permalinks .

2. Відредагуйте файл .htaccess та додайте наступне:

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

3. Перевірте його. Знайдіть ідентифікаційний номер публікації та введіть наступне (з інформацією) у своєму веб-переглядачі, і ви повинні бути перенаправлені на свою публікацію:

http://yourdomain.example.com/post/ (ідентифікатор #)

Варто також відзначити, що більшість програмного забезпечення електронної пошти не буде обрізати URL-адреси, позначені кутовими дужками (<і>), тому при вставлянні URL-адрес у повідомлення електронної пошти їх слід писати так:

Крім того, деякі пристойні клієнти електронної пошти пропонують опцію "preformat" під час створення текстових повідомлень. Використовуючи опцію "preformat", коли вставляти посилання, змусить клієнт електронної пошти не вставляти розриви рядків усередині посилань.

Виправлення інших проблем

Якщо ваш файл .htaccess генерується правильно, але Permalinks все ще не функціонують, може виникнути проблема. Якщо проблеми не зникнуть, напишіть нотатку в Форум WordPress Розділ Як.

AllowOverride Not Enabled

Ваш сервер може не мати включеної директиви AllowOverride. Якщо в вашому файлі Apache httpd.config директива AllowOverride встановлена ​​на None, файли .htaccess повністю ігноруються. У цьому випадку сервер не буде навіть намагатися читати файли .htaccess у файловій системі. Коли ця директива встановлена ​​на All, то будь-яка директива, що має контекст .htaccess, дозволена у файлах .htaccess. Приклад включеної директиви AllowOverride в httpd.config: <Directory /> Options 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, а потім у Options> Permalinks генеруйте новий набір правил htaccess, натиснувши кнопку Update Permalinks Structure. . Іноді користувачі визначають єдину крапку (.) Як базову категорію, щоб повністю видалити базу категорій з результуючої URL-адреси. Якщо це стосується налаштувань, спробуйте замінити крапку на фактичне слово. "category", "read", "cat", "useful" - корисні пропозиції. Якщо це все ще не працює, зверніться до форумів підтримки WordPress, зокрема, цю посаду підтримки . Посилання на сторінки не працюють Якщо ви спробували перейти до нещодавно створеного Сторінка і виникає помилка, вам, ймовірно, потрібно оновіть структуру Permalink . Пам'ятайте, що кожного разу, коли ви додаєте нову статичну сторінку до WordPress, нові правила повинні генеруватися та оновлюватися до .htaccess (WordPress 1.X) або до внутрішнього масиву перезаписів (WordPress 2.X). Permalinks to Ultimate Tag Warrior теги не працюють Якщо ви отримуєте 404 помилки на локальних тегах URL при використанні модуля UltimateTagWarrior на WordPress 2.X, це тому, що внутрішні перезаписи, створені за допомогою WordPress, є надто жадібними і викликаються до перезапису правил UTW є шанс. Зазвичай це відбувається лише при використанні власної структури постійної посилання (наприклад, /% postname% /). Також це можна виправити перемкніть структуру "Постійне посилання" на "Дата і ім'я на основі" або зламати додаток UTW для розміщення переписів UTW у верхній частині внутрішнього масиву перезаписів. Permalinks work, але жодні сторінки не повертаються Деякі версії 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 'permalinks enabled'; }?>

Дивіться також