Как сделать чпу для сайта на php
ЧПУ – это исковерканная англоязычная аббревиатура SEF URL (search engines friendly url). Она обозначает адреса ссылок, которые дружелюбны для поисковых систем. О ЧПУ я также писал в статье про внутреннюю оптимизацию сайта. В русскоязычном варианте SEF URL пишется как ЧПУ – человеко-понятные url. Что всё это значит? Это значит, что адреса ваших ссылок будут иметь осознанный текст, а не технический мусор, за примером можете сходить по ссылке выше.
Какие преимущества дают SEF URL?
Недостатки ЧПУ ссылок
Когда ЧПУ не нужны?
ЧПУ ссылки могут быть и лишними, например, если у вас закрытый корпоративный портал, где вся работа осуществляется только авторизованными пользователями, а для всех остальных, в том числе и для поисковых роботов доступ закрыт.
Также ЧПУ будет излишеством в back-end вашего сайта, то есть в панели администратора.
Что ещё нужно знать о ЧПУ?
Во всех актуальных версиях CMS данная проблема уже решена.
Пример в joomla:
category 1/article1">article1
Суть в том, чтобы из красивого и понятного человеку URL (ЧПУ) сделать на лету URL, который будет полезен разработчику PHP (не ЧПУ):
category 1&article=article1">article1
При этом всем на свете (посетителям, поисковым системам, всем) будет видна именно ЧПУ ссылка, но мы как разработчики PHP будем знать, что таит в себе URL на самом деле. В конце статьи, для полного понимания, я покажу все этапы, как работают ЧПУ.
Создание SEF ссылок с помощью mod_rewrite
Все наши правила преобразований URL записываются в небезызвестный файл .htaccess, который должен лежать в корне нашего сайта.
Для корректной работы mod_rewrite в нём обязательно должна быть написана следующая строка:
Или, в частности, для моего хостинга:
Далее подключаем наш модуль rewrite к конкретной папке, то есть к папке, в которой лежит наш .htaccess:
Имеем следующий файл .htaccess:
Правила и условия mod_rewrite
Все правила записываются с помощью команды RewriteRule, после которой ставится пробел и записывается шаблон ваших ЧПУ с помощью регулярных выражений, далее ставится ещё один пробел и указывается строка, в которую мы хотим преобразовать данный шаблон, где $1,$2,…$n – наши переменные. Более подробно о регулярных выражениях вы можете узнать по приведённой выше ссылке, а также далее в данной статье. Давайте рассмотрим пример:
Где ^ category 1/([a-z]*) – это шаблон ожидаемого url,
а /index.php?category= category 1&article=$1 – это то, во что мы его конвертируем, если пришедший URL подошёл под шаблон.
При этом $1 равен тому, что написано в круглых скобках, то есть $1 = [a-z]* Если бы круглые скобки встречались 2 раза, то у нас были бы переменная $1 и $2, если круглые скобки встречаются 3 раза, то переменные $1, $2, $3 и так далее. При этом переменные создаются в том же порядке, как идут круглые скобочки.
Хочу обратить ваше внимание на то, что для лучшего понимания статьи, вы уже должны обладать начальными знаниями о PHP, а также о работе с методами GET и POST.
Для того чтобы наш обработчик, то есть mod_rewrite не срабатывал каждый раз без надобности, мы в RewriteRule указываем шаблон, которому должны соответствовать приходящие URL. Если URL не соответствует шаблону, то mod_rewrite просто не сработает и не преобразует пришедший SEF URL в URL, с которым мы можем работать.
То есть на данном этапе вам важно понять саму суть: в ЧПУ ссылках не передаются параметры, а без параметров мы не можем ничего сделать в PHP с этой ссылкой, поэтому с помощью mod_rewrite мы преобразуем ЧПУ ссылку без параметров в не ЧПУ ссылку с параметрами. Что такое параметры? В примере выше имеем 2 параметра:
/index.php?category= category 1&article=$1
Параметр category и параметр article.
Опять-таки обращаю ваше внимание, что про параметры вы уже должны были знать, я лишь вкратце вам напомнил.
В шаблонах мы можем использовать символы и символьные классы. Символ точки обозначает абсолютно любой символ.
. – любой одиночный символ
[redf] – это класс символов. Обозначает наличие одного из перечисленных символов с учётом регистра.
[a-z] – класс символов. Обозначает наличие одного из символов в промежутки от a до z, то есть весь английский алфавит.
[a-zA-Z] – то же самое, только без учёта регистра, то есть весь алфавит, включая и большие и маленькие буквы.
Можно и с цифрами: 4
Естественно, всё можно комбинировать: [a-zA-Z0-9]
[^rewfad] – класс символов, но со знаком ^ внутри квадратных скобочек обозначает, что шаблон НЕ должен содержать данных символов.
site|cite – обозначает альтернативу: подходит site или cite.
Квантификаторы или кванторы
Все предыдущие примеры обозначали один символ (одну единицу), а что если мы хотим показать, что символов из этого промежутка [a-zA-Z] может быть не один, а сколько угодно. Для этого мы должны использовать квантификаторы:
? — 0 или 1 символ из предшествующего текста (класса символов, символа и тд.)
* — 0 или любое количество символов из предшествующего текста (n>0)
+ — 1 или любое количество символов из предшествующего текста (n>1)
— ровно n символов, где n – конкретное число.
Например:
— должно быть ровно 4 символа из предшествующего текста.
— 4 или 5 символов
— от нуля до 6 символов
— от 4 до бесконечности символов
Примером может послужить наша уже известная строчка:
RewriteRule ^ category 1/([a-z]*)
В которой мы применили квантификатор (квантор) звёздочку (*) после класса символов [a-z]. Это значит, что в нашем URL после useful/ могут находиться символы от a до z в любом количестве и, естественно, в любой последовательности, а могут и не быть вовсе. Домен в счёт не берём, он подразумевается сам по себе.
Экранирование
Также при составлении шаблона не стоит забывать и про экранирование. Если вы хотите заключить в класс символов, например, символ точки, то вам нужно её заэкранировать, так как без экранирования точка (служебный символ) обозначает абсолютно любой символ:
[a-zA-Z0-9\.]
Тоже самое касается и квадратных скобочек, они у нас обозначают класс символов, поэтому если в вашем url могут быть квадратные скобочки их нужно заэкранировать:
[a-zA-Z0-9\.\[\]]
Ограничение начала и конца строки (маркеры)
Для того чтобы указать начало или конец строки, без учёта домена, используются символы:
^ - начало URL
$ - конец URL
То есть в нашем первом примере мы указали, что наш шаблон начинается именно с начала URL, а не откуда угодно (с середины, с конца):
RewriteRule ^ category 1/([a-z])
Обращаю ваше внимание на то, что знак ^ внутри квадратных скобок обозначает отрицание, не путайте!
Обратные связи в mod_rewrite
%n – то же самое, только в RewriteCond. RewriteCond мы ещё не рассматривали, он у нас впереди.
Итак, если RewriteRule – это наши правила преобразования URL, то RewriteCond – это условие, аналог if в PHP. RewriteCond нужно в ситуациях, когда вам необходимо выполнить URL преобразование (RewriteRule) только при выполнении какого-то условия.
У сервера есть свои собственные переменные, которые мы можем использовать в наших условиях RewriteCond:
Соединение и запрос:
Синтаксис применения серверных переменных таков:
%
Давайте составим наше первое условие:
Если посетитель зашёл с браузера Mozilla Firefox, то выполняем следующее правило. Как видите, в отличие от PHP мы не используем фигурные скобки для обрамления нашего правила, которое выполнится, если условие TRUE.
RewriteCond позволяет использовать операторы сравнения: (больше), = (равно). Также есть специальные значения, например:
-d (является ли каталогом)
-f (является ли файлом)
-s (является ли файлом с ненулевым размером)
! – отрицание.
Флаги
nocase|NC – можно писать либо nocase, либо NC, это одно и то же, обозначает регистро-независмость. То есть мы можем больше не писать:
Вместо этого написать так:
ornext|OR – если это, либо следующее условие TRUE, то выполняем RewriteRule. Пример:
Last|L – последнее правило. Если правило применилось, то правила, расположенные ниже по коду, не сработают.
next|N – некий аналог continue. Если правило применилось, заставляет отыгрывать все правила с самого начала, но при этом с уже преобразованной строкой.
redirect|R – редирект. По умолчанию 302. Можно указать другой код редиректа, например:
forbidden|F – URL становится запрещённым.
gone|G – посылает 410 ответ сервера.
chain|C -связь. Если правило не сработало, то связанные с ним правила тоже автоматически не сработают.
type|T – MIME-тип. Принудительное выставление типа файла. Можно выдавать одно расширение файла за другое :) Например, лежат у нас файлы с расширением .zip, а на самом деле это картинки, так вот чтобы отдавать эти файлы как картинку(.jpg, .jpg и тд.), можно использовать данный флаг.
skip|S – пропустить следующее правило, можно указывать сразу несколько, например:
[S=2]
env|E=VAR:VAL – установить переменную окружения.
cookie|CO – послать куки.
Если нужно поставить одновременно несколько флагов, ставим их через запятую, например:
Как вы уже могли догадаться, mod_rewrite можно использовать не только для ЧПУ, но и для многих других интересный целей, например, клоакинга – это метод чёрного SEO, когда по одному и тому же адресу посетителям отдаётся одна страница, а поисковым роботам совершенно другая. Ну и под конец статьи, я покажу вам живой пример использования всего написанного выше и как же это всё работает взаимодействуя с нашим PHP.
Живой пример использования mod_rewrite
Итак, вот какой вид имеет мой файл .htaccess:
Человекопонятный URL (ЧПУ) - одна из самых часто затрагиваемых тем на различных форумах, посвящённых языку PHP. Можно до бесконечности спорить, нужны ли красивые URL-адреса для SEO-оптимизации, но факт того, что веб-сайт с ЧПУ выглядит аккуратно и профессионально отрицать глупо.
выглядит опрятно и интуитивно понятно для пользователя, нежели адрес вида
Кроме того, более-менее продвинутый пользователь в строке адреса броузера может стереть или заменить определенный путь иерархии в URL адресе, попав тем самым в нужное для него место на сайте (об этом хорошо написал Лебедев ещё в 2000 году - "Боремся за чистоту урлов", "Дублирующая навигация").
ЧПУ на базе модуля Apache mod_rewrite
Долгое вря ЧПУ делались с помощью небезызвестного модуля веб-сервера Apache mod_rewrite, который предназначен для манипуляции URL адресами. Директивы для mod_rewrite обычно писались разработчиками в .htaccess файле конфигурации Apache и выглядели примерно так:
Чем плох подобный механизм преобразований URL адресов, освоенный на mode_rewrite? Ничем не плох, но для разработки гибких веб-приложений он не подходит. В первую очередь потому, что преобразованием занимается сам mod_rewrite и система фактически завязана на файле конфигурации .htaccess. Мы не имеем возможности влиять на процесс преобразования, добавлять в автоматическом режиме новые виртуальные URL адреса, привязывать сложную логику к определённым виртуальным URL-адресам и делать многое другое.
Данная запись означает буквально следующее: если запрошенный URL-адрес не является файлом, не является символической ссылкой и не является директорией, то подменить виртуальный адрес файлом index.php. При этом, суперглобальная переменная PHP $_SERVER['REQUEST_URI'] будет содержать именно запрошенный виртуальный адрес. Что это нам даёт? Фактически - безграничные возможности для манипулирования виртуальными адресами!
Пример № 1.
Во многих фреймворках ЧПУ строится по следующему принципу:
"Распарсить" такой URL и получить имя модуля, действие и параметры нет никаких проблем.
В данном случае под определением "модуль" и "действие" можно понимать что угодно:
Модуль - подключаемый файл, действие - функция или конструкция в блоке if-else
Модуль - класс, действие - метод класса
т.е. все зависит от вашей архитектуры приложения.
Далее по тексту "модуль" и "действие" будет также называться совокупным определением "обработчик".
Возьмем в пример такой URL-адрес:
и "распарсим" его с помощью нижестоящего кода, который поместим в единую точку входа - в index.php:
Если же будет запрошен ошибочный URL -адрес:
то сработает исключение и в качестве обработчика будет фигурировать обработчик 404 ошибки:
Пример № 2.
Для понимания следующего подхода вам необходимы базовые знания Perl-совместимых регулярных выражений (POSIX).
Данный подход очень гибок и интересен, т.к. позволяет создавать практические любые виртуальные адреса, с абсолютно произвольной структурой и в отличие от предыдущего подхода - без упоминания в URL реального имени обработчика (модуля или действия). Суть метода заключается в следующем: каждый виртуальный URL-адрес, который может быть в системе, необходимо описать в виде регулярного выражения. Назначить для него обработчик. Если запрошенный URL совпадает с одним из таких регулярных выражений, то с помощью функций регулярных выражений нужно получить из URL необходимые данные, после чего передать их в обработчик. Пример:
Как видно из примера, так нужно будет описать все виртуальные URL адреса проекта. Напишем обработчик таких URL адресов:
Теперь при запросе
мы получим информацию о нужном нам обработчике (классе и методе класса), а так же массив параметров, с помощью которых и получим из СУБД информацию о теме в форуме:
Соответственно, инстанцирование нужного обработчика, т.е. класса Forum и запуск его метода viewTopick аналогичны запуску обработчика из примера №1.
Человекопонятные URL (ЧПУ) в адресах важно использовать, поскольку они влияют на поисковую оптимизацию сайта и создают дружественный URL для пользователей. Разбираемся, как их настроить.
Прежде чем говорить о настройке ЧПУ-адресов, необходимо разъяснить, что такое человекопонятные URL и для чего они нужны. Большинство CMS-движков при создании страниц присваивают им URL, состоящие из хаотичного набора символов, которые не несут для обычного пользователя никакой смысловой нагрузки. Пример ссылки:
Они ухудшают внешний вид сайта в глазах человека и негативно сказываются на ранжировании в поисковой выдаче. На помощь приходит система ЧПУ (человекопонятный URL). С английского SEF — Search Engine Friendly URL — это адрес, который удобен для восприятия посетителями и поисковой системой. Он должен логично описывать структуру сайта и путь к странице, быть кратким. Вот пример красивого SEO URL, который соответствует всем вышеупомянутым характеристикам:
ЧПУ-ссылки улучшают позиции сайта в выдаче поисковиков и повышают удобство в использовании ресурса. Это связано с тем, что в SEF-URLs зачастую входят ключевые слова запроса, на что положительно реагируют поисковые системы. Грамотно построенные ЧПУ сайта привлекают клиентов, в то время как длинные URL из хаотичного набора символов отпугивают потенциальных посетителей.
Как и любой другой инструмент, человекопонятные URL имеют
преимущества и недостатки, которые необходимо учитывать при их использовании.
Плюсы ЧПУ для пользователей сайта:
- SEF-URLs приятны для восприятия и привлекают больше внимания;
- ссылки легко запоминаются;
- по внешнему виду ссылки можно понять, какую информацию она содержит;
- ЧПУ улучшают навигацию по сайту.
- в ЧПУ можно вводить ключевые слова запроса;
- все URL прописаны на транслите;
- ссылка отображает структуру сайта и путь по нему;
- семантические URL положительно влияют на позиции сайта в поисковой выдаче.
- транслитерация русских слов в ЧПУ требует ручной настройки или установки дополнительных плагинов. Например, плагин Cyr-to-Lat для WordPress;
- SEF-URLs увеличивают нагрузку на сервер;
- если сайт создан не через CMS-движок, то ЧПУ для каждой страницы придется прописывать вручную. Платформы CMS дают возможность автоматической настройки семантических URL.
Используйте ЧПУ для эффективного продвижения сайта и удобства посетителей. Помните: только грамотно построенный ЧПУ URL способен выполнить все эти функции. Основные принципы построения ЧПУ:
Сегодня поговорим о том, как реализовать человекопонятные URL, а точнее, мы поговорим о том, как я это делаю.
Не будем вдаваться в споры — лучше или хуже, просто сразу к делу.
Итак. Для того, чтобы сделать ЧПУ нам необходимо прийти к общему знаменателю, а именно:
— данные хранятся в базе данных (субд MySQL)
— данные имеют уникальный идентификатор (id), являющийся полем int AUTO INCREMENT
— для отображения содержимого на странице мы используем строку GET типа index.php?id=3, само собой, как называть переменные — не имеет значения.
— на данный момент ваш sql запрос в коде выглядит как то так
— структура таблицы выглядит как то так
Если все выше написанное у вас имеется — перейдем к делу.
Давайте поймем как все работает сейчас, и как оно должно работать в будущем, когда у нас будет ЧПУ.
Сейчас мы получаем какой то id страницы, и тащим всю информацию, которая соответствует полю с этим id в таблице.
В случае с ЧПУ все должно быть примерно также, за исключением того, что выборку по id мы больше делать не будем.. мы будем делать выборку по URL, а для того, чтобы не было повторов URL мы будем всячески извращаться в админской части.
Итак, если ранее мы просто вбивали в БД данные, то теперь нам нужно создавать еще два поля, для формирования ЧПУ
как видите, я добавил два поля — url и url_num. Поле url это само собой, сам URL (как получить транслит), но нам нужно учесть, что при добавлении записи в БД мы можем иметь одинаковые названия (у меня url формируется из названия: название + транслит = URL), но нам нельзя допускать совпадений, так как мы по сути эмулируем id, по которому будет происходить выборка из бд, поэтому, мы вручную будем проверять наличие только что созданного URL в базе данных.
Затем мы обычным способом вносим в БД наши данные, не забыв при этом внести в поле url значение $chpu2.
При выборке на странице пользователю мы уже отправляем не id, а url, т.е. вначале мы получим что то вроде
index.php?id=eto_ssylka_stranicy
Но ведь тоже не фонтан, правда? Мы ж хотим быть как все, чтобы все красиво и без закорючек и переменных. Для этого мы будем использовать mod_rewrite.
Начать нужно с того, что отдавая ссылки пользователю, нужно преобразовывать их в тот вид, который нужен вам, т.е. НЕ
затем мы открываем (или создаем) файл .htaccess в корне сайта, и пишем следующее
Собственно — все. Если что непонятно — буду рад помочь в меру своих скромных способностей.
Читайте также: