Здравствуйте, Гуру!
Подскажите, пожалуйста, можно ли сделать ЧПУ таким образом, чтобы ссылки с гет параметрами переадресовывали на произвольные ЧПУ урлы?
Что имею ввиду: есть ссылка вида index.php?op=news&cat=1&subcat=1&id=1 и т.д.
хотелось бы получить по ней произвольное ЧПУ вида: text_article_blablabla
и чтобы в скриптах не нужно было парсить ничего, а работать только с GET переменными op, cat, subcat, id.
В Joomla 1.0 есть такой замечательный компонент JoomSEF, который позволяет делать именно подобное, в нём можно настроить переадресацию, в поле "Внутренняя сылка" занести любой внутренний URL с GET параметрами, а в поле "Новая SEF-ссылка" занести произвольный ЧПУ URL, и при обращении по этому произвольному ЧПУ URL в компоненте будут доступны те самые GET параметры.
Идея тут в том, чтобы при сохранении новости в своей самописной CMS прописывать в дополнительное поле в базе URL с GEt параметрами, и в другое поле произвольный ЧПУ.
Буду благодарен, если кто-нибудь подскажет какое правило нужно написать для этой задачи!
1. nooblamer - 28 Ноября, 2016 - 18:59:33 - перейти к сообщению
2. andrewkard - 28 Ноября, 2016 - 22:24:23 - перейти к сообщению
Создаете табличку с алиасами, получаете на вход произвольный сео урл, ищете по нему в БД рабочий урл с гет параметрами, с ним и работаете.
3. nooblamer - 28 Ноября, 2016 - 22:38:26 - перейти к сообщению
andrewkard пишет:
Создаете табличку с алиасами, получаете на вход произвольный сео урл, ищете по нему в БД рабочий урл с гет параметрами, с ним и работаете.
Я примерно так и хочу сделать, но не понятно, как это реализовать в самих скриптах, нужно роутер какой-то писать, в котором подгружать все правила перенаправлений?
А если страниц будет много, например, 10 к и более, запрос же будет долго выполняться...
Не понятно, как JoomSEF с этим справляется, пока не хватает уровня знаний, чтобы разобрать его осознанно)
Может, подскажите, как это в коде именно реализовать, в htaccess я так понял, все запросы надо переадресовывать на индексный файл так:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php
Но еще, видимо, в коде, что-то нужно дописать мудреного, а что, пока не понимаю( Наверняка же не все правила роутинга вытаскивать из базы, если страниц будет много, то загружаться правила будут долго, что не есть хорошо.
4. NeuroZ - 29 Ноября, 2016 - 08:43:59 - перейти к сообщению
nooblamer пишет:
В Joomla 1.0 есть такой замечательный компонент JoomSEF, который позволяет делать именно подобное, в нём можно настроить переадресацию, в поле "Внутренняя сылка" занести любой внутренний URL с GET параметрами, а в поле "Новая SEF-ссылка" занести произвольный ЧПУ URL, и при обращении по этому произвольному ЧПУ URL в компоненте будут доступны те самые GET параметры.
1. В современной J! есть компонент SH404SEF но и он не панацея.
2. Как один из простых вариантов - можно еще попробовать использовать REQUEST вместо GET (но это не самый лучший выход при работе с ЧПУ)
nooblamer пишет:
в своей самописной CMS
А при чем тут тогда J! и его расширения? Или может имеется в виду самописный компонент?
nooblamer пишет:
Не понятно, как JoomSEF с этим справляется, пока не хватает уровня знаний, чтобы разобрать его осознанно)
Зато хватает, чтобы написать свою CMS ))) по-моему не с того вы начали))
А теперь самое главное: зачем все эти БД и прилюдии? Придумайте правило роутинга. У J! помимо сторонних компонентов есть своя система роутинга, которая прекрасно работает вообще без БД
5. nooblamer - 29 Ноября, 2016 - 10:08:40 - перейти к сообщению
NeuroZ пишет:
1. В современной J! есть компонент SH404SEF но и он не панацея.
2. Как один из простых вариантов - можно еще попробовать использовать REQUEST вместо GET (но это не самый лучший выход при работе с ЧПУ)
А при чем тут тогда J! и его расширения? Или может имеется в виду самописный компонент?
Зато хватает, чтобы написать свою CMS ))) по-моему не с того вы начали))
А теперь самое главное: зачем все эти БД и прилюдии? Придумайте правило роутинга. У J! помимо сторонних компонентов есть своя система роутинга, которая прекрасно работает вообще без БД
nooblamer пишет:
В Joomla 1.0 есть такой замечательный компонент JoomSEF, который позволяет делать именно подобное, в нём можно настроить переадресацию, в поле "Внутренняя сылка" занести любой внутренний URL с GET параметрами, а в поле "Новая SEF-ссылка" занести произвольный ЧПУ URL, и при обращении по этому произвольному ЧПУ URL в компоненте будут доступны те самые GET параметры.
1. В современной J! есть компонент SH404SEF но и он не панацея.
2. Как один из простых вариантов - можно еще попробовать использовать REQUEST вместо GET (но это не самый лучший выход при работе с ЧПУ)
nooblamer пишет:
в своей самописной CMS
А при чем тут тогда J! и его расширения? Или может имеется в виду самописный компонент?
nooblamer пишет:
Не понятно, как JoomSEF с этим справляется, пока не хватает уровня знаний, чтобы разобрать его осознанно)
Зато хватает, чтобы написать свою CMS ))) по-моему не с того вы начали))
А теперь самое главное: зачем все эти БД и прилюдии? Придумайте правило роутинга. У J! помимо сторонних компонентов есть своя система роутинга, которая прекрасно работает вообще без БД
Компонент не для Joomla, а для своей CMS)
Она полностью написана, на это действительно хватило знаний))
И есть роутинг более-менее приемлемый, но хотелось бы реализовать что-то подобное, как в JoomSEF, а цель этой реализации в том, чтобы автоматом генерировать ЧПУ для разных компонентов из генератора компонентов, который уже тоже дописал, и чтобы не быть привязанным к структуре генерируемых ЧПУ.
На мой взгляд это очень удобно, генерировать внутреннюю ссылку, и ЧПУ ссылку, вопрос только в том, как сделать перенаправления ссылок с параметрами на ЧПУ, но при этом, чтобы в скриптах были доступны GET/POST переменные.
6. Sail - 29 Ноября, 2016 - 10:34:38 - перейти к сообщению
nooblamer пишет:
перенаправления ссылок с параметрами на ЧПУ, но при этом, чтобы в скриптах были доступны GET/POST переменные
Однако, для того, чтобы GET/POST переменные были доступны в скриптах, сервер должен получить соответствующую ссылку с параметрами и/или post-форму...
Иначе, в случае с семантическим URL - параметры определяются при обработке этого URL и пишутся в соответствующие 'хранилища' (параметры вызываемой далее функции, переменные, объекты, сессии, базу, etc).
Не писать же их в глобальные массивы $_GET и $_POST, в самом-то деле...
7. NeuroZ - 29 Ноября, 2016 - 10:36:39 - перейти к сообщению
1. POST доступен только если он был передан на конкретную страницу
2. GET доступен аналогично (но тогда рушится сам ЧПУ). Т.е. будет site.ru/catalog/page?id=3¶m=somedata&...
3. Чтобы избежать проблем в пункте 2 нужно создать с вой роутинг с правилами. Я могу расписать пример работу роутинга J! может это наведет вас на какие-то идеи, касательно вашей CMS.
Итак,
-При выключенном ЧПУ в url содержится весь GET запрос страницы и ее параметров.
-При включенном ЧПУ подключается файл router.php который переопределяется для каждого компонента.
А. Если такого файла нет, то действует стандартный J! роутинг.
В. Если нет пунктам меню (ItemID в GET), то первой частью url будет /component/
С. Далее (точно не помню) подставляется значения option из GET /option/
Д. Затем значение view из GET
Е. Все остальные GET переменные либо обрабатываются согласно правилам router.php либо идут как обычные GET параметры (как я описал выше в п.2)
Если надо отправить POST- то ничего общего с роутингом он не имеет. Есть опредленные правила парсинга переменных. Если в POST есть option и task разделенный точкой, то это значит, что запрос пойдет на контроллер с именем (первая часть task (до точки)) компонента option и вызовет там метод task (после точки).
Для наглядности
2. GET доступен аналогично (но тогда рушится сам ЧПУ). Т.е. будет site.ru/catalog/page?id=3¶m=somedata&...
3. Чтобы избежать проблем в пункте 2 нужно создать с вой роутинг с правилами. Я могу расписать пример работу роутинга J! может это наведет вас на какие-то идеи, касательно вашей CMS.
Итак,
-При выключенном ЧПУ в url содержится весь GET запрос страницы и ее параметров.
-При включенном ЧПУ подключается файл router.php который переопределяется для каждого компонента.
А. Если такого файла нет, то действует стандартный J! роутинг.
В. Если нет пунктам меню (ItemID в GET), то первой частью url будет /component/
С. Далее (точно не помню) подставляется значения option из GET /option/
Д. Затем значение view из GET
Е. Все остальные GET переменные либо обрабатываются согласно правилам router.php либо идут как обычные GET параметры (как я описал выше в п.2)
Если надо отправить POST- то ничего общего с роутингом он не имеет. Есть опредленные правила парсинга переменных. Если в POST есть option и task разделенный точкой, то это значит, что запрос пойдет на контроллер с именем (первая часть task (до точки)) компонента option и вызовет там метод task (после точки).
Для наглядности
CODE (html):
скопировать код в буфер обмена
скопировать код в буфер обмена
- <form action="#" method="post">
- <input type="hidden" name="option" value="com_test" />
- <input type="hidden" name="task" value="user.create" />
- </form>
в action можно также подставить строку index.php?option=com_test&task=user.create - а в метод добавить переменную отвечающую за способ отправки get/post. И таким образом, если будет выбран get, то функционировать код не перестанет.
Но возвращаясь к описанию:
будет вызван метод create контроллера user.php из компонента com_test. Вот и все)