php url без get параметров
Website-create.ru
Сегодня поговорим о том, как получить адрес страницы в php.
Зачем это может быть нужно?
Сценарии могут быть разными. Например, у нас используется один и тот же шаблон для разных разделов. Но в одном из разделов нам необходимо вывести (или не вывести) какой-то специфичный блок, которого в других разделах быть не должно.
Вероятно мы захотим сделать это по условию. И именно в условии мы и будем проверять тот ли это раздел.
Возможно с архитектурной точки зрения — это не самое лучшее решение. Однако, очень часто нам достаются уже готовые проекты, с которыми нужно что-то делать.
Получаем URL текущей страницы
Если вы хотите посмотреть всё, что хранит этот массив, то можете воспользоваться следующим кодом, который в читабельном виде выведет все значения:
Итак, давайте представим, что у нас есть веб страница следующего вида: http://localhost/php-lessons/url/?name=anna&city=Valencia.
Я тестирую на локальном сервере. Когда вы будете работать с реальным сайтом, который лежит в сети, то вместо localhost у вас будет имя вашего сайта (например exmple.ru).
Что мы видим в нашем подопытном url?
Давайте разберемся с каждой ситуацией.
Получаем полный URL страницы в php
Чтобы получить полный URL страницы вместе с GET-параметрами, воспользуемся следующим кодом:
Сначала мы проверяем, какой протокол используется: https или http.
Далее мы присоединяем двоеточие и 2 слэша, имя домена (хоста) и остальную часть нашего URL.
Результат будет вот таким:
Если протокол нам получать не нужно, то можно сократить код до такого:
Результат тогда будет следующим:
Получаем URL страницы без GET-параметров в php
Иногда нас не интересуют GET-параметры, которые передаются как часть URL, и нам нужно получить адрес без них.
GET-параметры в нашем случает — это name=anna&city=Valencia
Чтобы отсечь их мы можем использовать php-функцию explode, которая разбивает строку по разделителю.
Наш URL — это ни что иное, как строка. GET-параметры всегда начинают передаваться после знака «?». Следовательно разделителем будет вопросительный знак.
Функция explode превратит строку в массив с двумя элементами. В первом будет содержаться наш искомый url без GET-параметров, а во втором останутся GET-параметры.
Результат будет таким: http://localhost/php-lessons/url/
Получаем GET-параметры из URL
Здесь совсем все просто. Чтобы получить только GET-параметры будем использовать следующий код:
Дальше мы можете разобрать это строку, например, с помощью функции explode или сделать с ними что-либо еще (в зависимости от стоящей перед вами задачи).
А у меня на сегодня всё!
Ставьте лайки, оставляйте комментарии, подписывайтесь на обновления!
В этой статье будет рассказано о том, как в языке программирования PHP получить адрес текущей страницы. Также вы узнаете о работе переменной $_SERVER.
Первое, о чём следует сказать, — зачем вообще получать ссылки (urls) в PHP? На практике варианты могут различаться. Представьте, что у нас для разных разделов применяется один и тот же шаблон. И возникает потребность в том, чтобы вывести (либо не вывести — зависит от ситуации) какой-нибудь специальный блок, причём в других разделах вывод этого блока не нужен.
В большинстве случаев мы пожелаем выполнить поставленную задачу по условию. То есть сделаем условие, в котором будем выполнять проверку того либо иного раздела. Можно сказать, что с точки зрения архитектуры данное решение не является оптимальным. Но на практике нам нередко достаются уже реализованные проекты, с которыми необходимо что-то решать с учётом уже имеющейся архитектуры.
Но давайте не будем много говорить, а лучше приступим к решению поставленной задачи — получению ссылки в PHP.
Получение ссылки текущей страницы в PHP
Идём дальше. Представьте, что у вас есть web-страница, имеющая следующий вид: http://localhost/php-lessons/url/?name=anna&city=Valencia. Тестирование в данном примере осуществляется на локальном сервере. Если надо тестировать код на реальном веб-сайте, доступном в интернете, достаточно вместо localhost прописать имя сайта (домен) — тот же otus.ru.
Что же мы увидим в подопытном url? Нас могут интересовать следующие данные: — адрес веб-страницы без GET-параметров; — URL с GET-параметрами; — непосредственно GET-параметры без текущей ссылки (адреса веб-страницы).
Лучше всего разобраться с каждым из случаев по отдельности — так будет гораздо понятнее.
Получение полного URL в PHP
Для получения полного URL вместе с имеющимися GET-параметрами, пригодится следующий код:
На втором этапе выполняется присоединение двоеточия и двух слэшев, имени домена и остальной части URL.
Итог выполнения кода будет следующим:
Если протокол получать не требуется, код на PHP можно немного сократить:
Смотрим на результат и видим, что протокол отсутствует:
Получение URL в PHP без GET-параметров
Иногда эти параметры, передаваемые в качестве части ссылки, нас не интересуют, то есть требуется получить адрес без них. Мы говорим о следующих параметрах: name=anna&city=Valencia.
В действительности их можно отсечь, используя функцию explode в PHP, разбивающую строку по разделителю. Не стоит объяснять, что ссылка представляет собой строку, а параметры GET начинают прописываться после «?». В результате вопросительный знак и станет разделителем, а функция explode сделает из строки массив с 2-мя элементами. Первый элемент станет содержать искомую ссылку без GET-параметров, так как эти самые параметры останутся во втором элементе.
Получение только параметров GET
С помощью этого кода получим:
Параметры сервера
Имя хоста, обычно совпадает с доменом.
Версия CGI на сервере.
Название и версия сервера.
Версия сервера и имя виртуального хоста, обычно пуста.
Имя и версия используемого HTTP протокола.
Значение из директивы конфигурационного файла Apache.
На хостингах указывают контактный e-mail.
Параметры соединения
Имя сервера, как правило, совпадает с доменом.
IP-адрес, с которого пользователь просматривает текущую страницу.
Удаленный хост, с которого пользователь просматривает текущую страницу.
Порт на удаленной машине, который используется для связи с веб-сервером.
Метод запроса к странице.
Время запроса к серверу в Unix timestamp.
Время запроса к серверу с точностью до микросекунд.
Пути на сервере
Директория корня сайта, в которой выполняется текущий скрипт.
Содержит путь, содержащийся после имени скрипта.
Например для адреса http://site.ru/index.php/123 значение будет следующим:
Исходное значение переменной PATH_INFO перед обработкой PHP.
Путь и имя выполняемого скрипта.
Абсолютный путь к исполняемому скрипту.
Метод HTTP аутентификации.
HTTPS
Значения в примерах приведены для адреса http://site.ru/index.php?page=1&sort=2
URI страницы с GET-параметрами, без домена.
Содержит URL страницы без GET-параметров и домена.
Заголовки браузера
Строка, обозначающая браузер и операционную систему, который открыл данную страницу.
Адрес страницы, с которой браузер пользователя перешёл на текущую страницу.
Содержимое заголовка Accept из текущего запроса.
HTTP заголовок переданный клиентом, говорящий о том какие алгоритмы сжатия он может понять.
Предпочтения клиента относительно кодировки.
ЧПУ, роутинг, единая точка входа на PHP
Единая точка входа
Принцип работы единой точки входа очень прост.
Вот и весь принцип единой точки входа. Именно так она работает в популярных CMS вроде WordPress и Opencart, в фреймворках Laravel, Symfony и т.д.
Лично я предпочитаю также перенаправлять их на index.php.
На самом деле на сайтах часто используются 2 точки входа.
Плюсы единой точки входа
Единая точка входа с Apache
Этот файл позволяет переопределять настройки Apache для определённых сайтов и папок.
Также в интернете часто можно встретить другой вариант конфига, отличается он только последней строкой:
Единая точка входа с Nginx
Открываем конфиг домена и внутри секции server прописываем следующее правило:
Простой роутинг
Если единая точка входа настроена правильно, то при заходе по любому несуществующему URL-адресу, например /test должен запуститься файл index.php.
Теперь мы можем написать очень простой роутер, который смотрит на текущий URL и подключает соответствующий скрипт:
Внесём ещё пару доработок. Во-первых, зачастую URL-адреса должны работать вне зависимости от наличия GET-параметров, поэтому вырежем их из URI:
Кроме этого, часто требуется получить доступ к определённой части URL. Для этого разобьём URL на части по слешу:
Теперь мы можем легко добавить маршруты для админки:
Это самый простой вариант роутинга. Не идеальный, конечно, но и не требующий знания регулярных выражений (хотя никто не мешает их использовать) и подключения сторонних библиотек.
При хранении URL адресов в базе данных роутинг будет выглядеть примерно так (реальный код зависит от библиотеки, которую вы используете для взаимодействия с БД):
Роутинг средствами htaccess
Какое-то время назад было популярно прописывать правила роутинга прямо в htaccess, вот несколько примеров:
У этого подхода есть несколько недостатков:
Короче, не используйте этот подход.
Структура URL адресов в админке
Обычно URL адреса в админке формируются по одной из следующих схем:
И сразу рассмотрим простой пример:
Перепишем пример, написанный нами в единой точке входа, под новую схему URL:
Итак, мы берём 1-ый фрагмент URL и проверяем, существует ли в папке pages файл с таким названием.
Как видите, при таком подходе нам больше не нужно прописывать соответствие URL-адресов и PHP-файлов. PHP сам будет искать нужный файл в папке pages по первому фрагменту URL.
Вот так выглядит обработка действий. Мы смотрим на второй фрагмент URL и ищем обработчик этого действия. Для каждого действия (add, update, delete) нужно прописать отдельный блок elseif.
Если вам не нравится вложенная проверка метода, можно сделать иначе. В файле index.php сохраним метод в отдельную переменную:
Затем в products.php меняем заготовку на следующую:
Готово. Да, если вам не нравится, что в коде 2 раза встречается одно и то же действие, только с разными методами, можете использовать немного упрощённую схему URL-адресов из фреймворка Laravel:
Добавление префикса /admin/ в URL
Немного изменим код index.php :
Продвинутый роутер FastRoute
Если вы ищете более серьёзную систему роутинга, рекомендую изучить библиотеку FastRoute. Это очень мощный роутер, идеально подходящий для сложных приложений, особенно если вы используете ООП.
Типы HTTP-запросов и философия REST
Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.
В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.
Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 🙂
Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.
Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:
где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).
Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.
Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.
Пример HTTP-взаимодействия
Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует
Ресурсы и методы
Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).
Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».
В игру вступает REST
REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — одним из разработчиков протокола HTTP — в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.
REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 — это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).
REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).
В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET — возвращает ресурс, POST — создает новый, PUT — обновляет существующий, DELETE — удаляет.
Проблемы?
Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.
PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.
Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем «_method», а в качестве значения указать название метода (например, «PUT») — в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.