Використання дружніх URL-адрес

  1. 1) Робочий зразок .htaccess
  2. 2) Налаштуйте MODX Revolution
  3. 3) Редагувати шаблони
  4. 4) Очистити кеш сайту
  5. 5) Перетворити URL-адреси WWW на не-WWW або навпаки

Дружні URL-адреси можуть повністю функціонувати впродовж двох хвилин, виконавши простий чотирикроковий процес.

1) Робочий зразок .htaccess

MODX постачає файл ht.access для редагування, щоб він відповідав настройкам сервера. Він розташований у корені сайту MODX. Цей файл буде проігноровано сервером, поки ви не перейменуєте його або (краще) скопіюєте його до файлу з назвою .htaccess. Всякий раз, коли браузер запитує сторінку, сервер перевіряє файл з назвою .htaccess, який може містити інформацію про те, як повинні оброблятися різні URL-адреси.

Файл .htaccess може бути де-небудь над установкою MODX, але звичайне місце розташування знаходиться в корені сайту MODX (разом з файлом ht.access, а каталоги активів, менеджера та з'єднувачів, як показано на малюнку нижче). Для більшості інсталяцій вам не доведеться вносити будь-які зміни до файлу, щоб працювати з FURL. Існує одна зміна, яку ви повинні зробити, але спочатку потрібно працювати з FURL, і ми розглянемо цю зміну в кінці цієї сторінки.

Існує одна зміна, яку ви повинні зробити, але спочатку потрібно працювати з FURL, і ми розглянемо цю зміну в кінці цієї сторінки

Ось файл ht.access, який постачається з однією версією MODX (ваша версія може трохи відрізнятися).

# MODX підтримує дружні URL-адреси через цей файл .htaccess. Для використання цієї функції ви повинні подавати веб-сторінки через Apache за допомогою mod_rewrite, і ви повинні # змінити ім'я файлу з ht.access на .htaccess. # # Переконайтеся, що RewriteBase вказує на каталог, де встановлено MODX. # Наприклад, "/ modx", якщо ваша установка знаходиться в підкаталозі "modx". # # Ви можете зробити свої URL-адреси нечутливими до регістру, додавши директиву # до вашого правила: RewriteRule ^ (. *) $ Index.php? Q = $ 1 [L, QSA, NC] Перезаписати двигун на RewriteBase / # # # Переписати www.domain.com -> domain.com - використовується з плагіном SEO Strict URLs #RewriteCond% {HTTP_HOST}. #RewriteCond% {HTTP_HOST}! ^ Example-domain-please-change. .Com [NC] #RewriteRule (. *) Http://example-domain-please-change.com/$1 [R = 301, L] # # # або для протилежного domain.com -> www.domain.com використовуйте наступні # НЕ ВИКОРИСТОВУЙТЕ ОБ'ЯВУ # # #RewriteCond% {HTTP_HOST}. #RewriteCond% {HTTP_HOST}! ^ Www Змінити-домен-будь ласка-змінити. .Com [NC] #RewriteRule (. *) Http://www.example-domain-please-change.com/$1 [R = 301, L] # # # Переписати захищені запити належним чином, щоб запобігти попередженню SSL-сертифікатів, наприклад, запобігти # https://www.domain.com, коли ваш сертифікат дозволяє лише https://secure.domain.com #RewriteCond% {SERVER_PORT}! ^ 443 #RewriteRule (. *) Https://example-domain-please-change.com/$1 [R = 301, L] # # # Друга URL-адреса частина RewriteCond% {REQUEST_FILENAME}! -F RewriteCond% {REQUEST_FILENAME} ! -d RewriteRule ^ (. *) $ index.php? q = $ 1 [L, QSA] # # # # Переконайтеся, що файли .htc подаються з належним типом MIME, який є критичним # для XP SP2. Un-comment, якщо ваш хост дозволяє перевизначити тип htaccess MIME. #AddType text / x-component .htc # # # Якщо ваш сервер ще не налаштований як такий, наступну директиву # слід розкомментавати, щоб встановити параметр register_globals PHP у OFF. # Це закриває серйозну дірку безпеки, яку зловживає більшість XSS-атак. Для отримання додаткової інформації: http://php.net/register_globals # # Щоб переконатися, що цей параметр був встановлений на OFF, відкрийте диспетчер і виберіть # Звіти -> Інформація про систему, а потім натисніть посилання phpinfo (). Виконайте пошук на сторінці # для "register_globals". Місцеве значення має бути вимкнено. Якщо основне значення # вимкнено, то ця директива тут не потрібна. # # IF REGISTER_GLOBALS ДИРЕКТИВА ВИКЛАДАЄ 500 ВНУТРІШНІХ ПОШУК СЕРВЕРІВ: # # Ваш сервер не дозволяє встановлювати директиви PHP через .htaccess. У цьому випадку ви повинні внести цю зміну у ваш файл php.ini. Якщо ви використовуєте комерційний веб-хост, зверніться до адміністраторів для отримання допомоги в цьому. Не всі сервери дозволяють локальні файли php.ini, і вони повинні включати всі конфігурації PHP (а не тільки цю), або ви будете фактично # скинути всі значення за замовчуванням PHP. Зверніться до www.php.net для отримання більш детальної інформації про встановлення директив PHP. #php_flag register_globals Off # # # Для серверів, які підтримують стиснення виводу, ви повинні підібрати трохи швидкості #, не коментуючи наступні рядки. #php_flag zlib.output_compression На #php_value zlib.output_compression_level 5 # # # # Наступні директиви зупиняють мерехтіння екрана в IE на перекиданнях CSS. Якщо # потрібно, не коментуйте наступні правила. Коли вони знаходяться на місці, можливо, у вас є #, щоб зробити оновлення сили, щоб побачити зміни у своїх проектах. #ExpiresActive На зображенні #ExpiresByType / gif A2592000 #ExpiresByType image / jpeg A2592000 #ExpiresByType image / png A2592000 #BrowserMatch "MSIE" порушено = 1 #BrowserMatch "Mozilla / 4. [0-9] {2}" brokenvary = 1 #BrowserMatch "Опера"! Зламановажним #SetEnvIf порушенеперша сила 1-не-змінюється

Ви також можете помістити файл у / htdocs або / public_html або те, що використовує ваш сервер, якщо він знаходиться у кореневому каталозі MODX або вище.

Майте на увазі, що деякі хости хотіли б написати власний .htaccess трохи вище рівня сайту, але якщо ваш .htaccess знаходиться в корені сайту MODX, він повинен працювати нормально. Якщо ваш хост розмістив файл .htaccess у корені сайту MODX, вам доведеться вставити код з файлу ht.access MODX нижче коду хостів у цьому файлі. Обов'язково створіть резервну копію файлу хосту! Таким чином, ви можете відновити його, якщо справи йдуть погано.

Рядок RewriteBase має закінчуватися а / для кореневої інсталяції

RewriteBase для інсталяції підкаталогу може бути введена як: RewriteBase / subdirectoryName / хоча це зазвичай потрібно тільки на локальній установці. Рядок RewriteBase майже завжди повинен закінчуватися косою рискою.

2) Налаштуйте MODX Revolution

Далі, змініть параметри у зоні дружніх URL-адрес у системних настройках MODX (див. Наведене нижче зображення). У MODX 2.3 натисніть на значок шестерні у верхньому правому куті і виберіть "Системні параметри". У попередніх версіях перейдіть до System -> System Settings. У полі "Пошук за ключем" у верхньому правому кутку сітки введіть "дружній" (без лапок) і натисніть клавішу Enter. Це покаже всі налаштування Friendly URL. Головне, яке ви хочете, - у нижній частині: використовуйте Friendly URLs (friendly_urls). Двічі клацніть на "Ні" і змініть його на "Так".

Якщо ви не бачите всіх параметрів MODX FURL, просто змініть випадаюче поле "Area" у верхній частині сітки на Friendly URL, як я це зробив.

Ви не знайдете friendly_url_prefix та friendly_url_suffix серед налаштувань на зображенні нижче - вони застаріли на користь розширень, визначених користувачем Типи вмісту і container_suffix (для ресурсів контейнерів з типами вмісту, які мають тип mime_type text / html).

Параметр "Суфікс" за умовчанням зараз "/", що призводить до URL-адрес контейнерних ресурсів замість типу вмісту контейнера (іншими словами, URL-адреси ресурсів, позначених як контейнери, будуть / замість щось подібного .html). Якщо ви бажаєте, щоб ваші контейнерні ресурси показувалися як тип вмісту (наприклад, .html), видаліть "/" з цього налаштування. Якщо у вас є проблеми з пакетами, які використовують суфікс контейнера для FURLS (наприклад, Статті ), поверніть це налаштування на "/".

Якщо у вас є проблеми з пакетами, які використовують суфікс контейнера для FURLS (наприклад, Статті ), поверніть це налаштування на /

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

Параметр friendly_alias_urls видалено в MODX 2.1+. Увімкнення функції friendly_urls означає, що ви використовуєте friendly_alias_urls у версії 2.1+, і це налаштування більше не було корисним або необхідним.

3) Редагувати шаблони

Переконайтеся, що у головному розділі всіх ваших шаблонів є наступний тег. Якщо ви маєте лише один контекст інтерфейсу (наприклад, "web"), ви можете, як правило, виключити знак оклику швидкості завантаження сторінки:

<base href = "[[! ++ site_url]]" />

4) Очистити кеш сайту

І все готово!

Найпростіший спосіб скористатися перевагами використання повноцінних дружніх URL-адрес - дозволити MODX створювати посилання за допомогою тегів посилань, описаних на цій сторінці: синтаксис тегу посилання щоб створити посилання на різні ресурси, легко, як прив'язувати тег посилання нижче (де 1 - ідентифікатор ресурсу сторінки, на яку потрібно зв'язати). Це має додаткову перевагу, що дозволяє переміщати ресурси навколо веб-проекту, не потребуючи виправлення зв'язків, оскільки MODX буде автоматично оновлювати посилання, створені таким чином.
<a href="[[~1]]" title="some title"> Деякі сторінки </a>

5) Перетворити URL-адреси WWW на не-WWW або навпаки

Раніше ми згадували про одну зміну, яку ви завжди повинні робити у файлі .htaccess, як тільки ви працюєте з FURL. Це стосується URL-адрес, які починаються з "www" (чи ні). Користувач може дійти до більшості сайтів з доменним ім'ям або доменним іменем, перед яким стоїть "www". Ви завжди повинні перетворювати URL-адресу на одну або іншу. Причини складні, але якщо ви не зробите цього, на вашому сайті можуть статися незвичайні речі. Наприклад, користувачі, які увійшли в систему, можуть раптово втратити цей статус.

Виправити це дуже просто. У коді файлу .htaccess вище, ви побачите два розділи, обидва прокоментували. Один змінює URL-адреси без www на URL-адреси URL, інший робить навпаки. Вирішіть, який саме ви хочете, і просто розкомпонуйте розділ, який це робить, видаливши # на початку кожного рядка. Будьте обережні, розшифруйте лише три рядки.

Наприклад, щоб видалити "www". з усіх запитів на сайт із доменом "yoursite.com" змінити цей розділ:

# Rewrite www.domain.com -> domain.com - використовується з плагіном SEO Strict URLs #RewriteCond% {HTTP_HOST}. #RewriteCond% {HTTP_HOST}! ^ Example-domain-please-change. .Com [NC] #RewriteRule (. *) Http://example-domain-please-change.com/$1 [R = 301, L]

виглядати так:

# Rewrite www.domain.com -> domain.com - використовується з плагіном SEO Strict URLs RewriteCond% {HTTP_HOST}. RewriteCond% {HTTP_HOST}! ^ Ваш сайт. [NC] RewriteRule (. *) Http://yoursite.com/$1 [R = 301, L]

Зверніть увагу, що перший рядок ми не розкомпонували. Це реальний коментар. Розшифровка призведе до того, що сервер оброблятиме його як код, і це може призвести до збою сервера.

Розробники можуть бути дуже чутливі до того, що знаходиться у файлі .htaccess. Завжди створюйте резервні копії робочого файлу .htaccess перед його зміною. Таким чином, якщо ваша робота аварійно завершить роботу сервера, ви можете просто скопіювати збережену версію в .htaccess і почати знову.

Запропонувати редагування на цю сторінку на GitHub (вимагає облікового запису GitHub. Відкриває нове вікно / вкладку) або стати редактором документації MODX.

Php?
Php?