Как сделать чпу для сайта на php

Добавил пользователь Alex
Обновлено: 19.09.2024

ЧПУ – это исковерканная англоязычная аббревиатура 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 в корне сайта, и пишем следующее

Собственно — все. Если что непонятно — буду рад помочь в меру своих скромных способностей.

Читайте также:

  
• Подшить шторы своими руками
  
• Ремонт унитаза своими руками
  
• Сироп от кашля своими руками
  
• Распылитель монтажной пены своими руками
  
• Обратный клапан из шприца своими руками