помощь по ЧПУ

Здравствуйте, Гуру!

Подскажите, пожалуйста, можно ли сделать ЧПУ таким образом, чтобы ссылки с гет параметрами переадресовывали на произвольные ЧПУ урлы?

Что имею ввиду: есть ссылка вида 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 параметрами, и в другое поле произвольный ЧПУ.

Буду благодарен, если кто-нибудь подскажет какое правило нужно написать для этой задачи!

Создаете табличку с алиасами, получаете на вход произвольный сео урл, ищете по нему в БД рабочий урл с гет параметрами, с ним и работаете.

Я примерно так и хочу сделать, но не понятно, как это реализовать в самих скриптах, нужно роутер какой-то писать, в котором подгружать все правила перенаправлений?
А если страниц будет много, например, 10 к и более, запрос же будет долго выполняться...
Не понятно, как JoomSEF с этим справляется, пока не хватает уровня знаний, чтобы разобрать его осознанно)

Может, подскажите, как это в коде именно реализовать, в htaccess я так понял, все запросы надо переадресовывать на индексный файл так:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php

Но еще, видимо, в коде, что-то нужно дописать мудреного, а что, пока не понимаю( Наверняка же не все правила роутинга вытаскивать из базы, если страниц будет много, то загружаться правила будут долго, что не есть хорошо.

1. В современной J! есть компонент SH404SEF но и он не панацея.
2. Как один из простых вариантов - можно еще попробовать использовать REQUEST вместо GET (но это не самый лучший выход при работе с ЧПУ)

А при чем тут тогда J! и его расширения? Или может имеется в виду самописный компонент?

Зато хватает, чтобы написать свою CMS ))) по-моему не с того вы начали))

А теперь самое главное: зачем все эти БД и прилюдии? Придумайте правило роутинга. У J! помимо сторонних компонентов есть своя система роутинга, которая прекрасно работает вообще без БД

Компонент не для Joomla, а для своей CMS)
Она полностью написана, на это действительно хватило знаний))
И есть роутинг более-менее приемлемый, но хотелось бы реализовать что-то подобное, как в JoomSEF, а цель этой реализации в том, чтобы автоматом генерировать ЧПУ для разных компонентов из генератора компонентов, который уже тоже дописал, и чтобы не быть привязанным к структуре генерируемых ЧПУ.
На мой взгляд это очень удобно, генерировать внутреннюю ссылку, и ЧПУ ссылку, вопрос только в том, как сделать перенаправления ссылок с параметрами на ЧПУ, но при этом, чтобы в скриптах были доступны GET/POST переменные.

Однако, для того, чтобы GET/POST переменные были доступны в скриптах, сервер должен получить соответствующую ссылку с параметрами и/или post-форму...
Иначе, в случае с семантическим URL - параметры определяются при обработке этого URL и пишутся в соответствующие 'хранилища' (параметры вызываемой далее функции, переменные, объекты, сессии, базу, etc).
Не писать же их в глобальные массивы $_GET и $_POST, в самом-то деле...

1. POST доступен только если он был передан на конкретную страницу
2. GET доступен аналогично (но тогда рушится сам ЧПУ). Т.е. будет site.ru/catalog/page?id=3&param=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 (после точки).
Для наглядности

Я тоже это так понимаю, но вот в случае с JoomSEF всё как-то иначе реализовано, вызываешь документ по ЧПУ урлу, и при этом GET становится доступным внутри компонентов)
(Добавление)

Палка о 2 концах: либо используйте БД (но тогда будут просадки при большом кол-ве страниц), и JoomlaSEF не застрахована от этого как и любое приложение работающее с ЧПУ через БД. (а сама реализация - уже дело вашей фантазии)
Либо использовать правила роутинга для вашей CMS (будет выигрывать в скорости перед БД)
(Добавление)
А у вас получается задача:
Хочу чтобы сайт грузился за 1 сек, при этом там 5 слайдров с неограниченным числом картинок с разрешением в 4к, и все это работало на бесплатном хостинге при посещении 100к уников
Ну в общем аллегорию вы поняли...

Ну в JoomSEF вроде не возникает проблем с большим количеством страниц, думаю, что правила перенаправлений нет смысла грузить сразу все, зачем это, когда можно при обращении по ЧПУ вытащить 1 правило, и уже с ним работать?
Сейчас пришла мысль, вытаскивать по ЧПУ из базы ссылку с гет параметрами, парсить их, и заносить в массив, и уже с ним работать в компонентах, буду пробовать в общем)

Ну а в JoomlaSEF разве не по такой же логике работает?

Я, конечно, не знаю, что у вас за велосипед и какие задачи он(а) должна решать... Но я бы для удобства использования таблиц - использовал отдельное поле для хранения GET в виде json, отдельно ЧПУ линк, отдельно линк без ЧПУ. + может какие-то служебные данные типа кастомных мета-данных или еще что-либо... И конечно кэшировал бы всё, что существенно влияло бы на скорость обработки таких url.

JoomSEF не знаю все ли правила сразу подгружает, если все, то это не логично конечно.

А на счёт вашего совета, благодарю, так и поступлю, нет смысла по идее хранить линк с гет параметрами, можно всё в json объекте хранить, и ЧПУ в отдельном поле, можно было бы и титлы, кейвордсы с дескрипшн хранить тут же, но смысла не вижу, так как они уже хранятся в таблицах компонентов, и в шаблон из компонента подставляются. Сделаю в общем отдельную таблицу алиасов, и буду все правила хранить в ней, обращаться по 1-му запросу на документ, парсить json, его, кстати, можно загнать и в массив GET, чтобы получилось то, как в JoomSEF реализовано)) но не буду, смысла в этом не вижу, просто с объектом json и буду дальше работать. Плюсанул бы вам, но форум говорит, что недостаточно для этого отправленных сообщений.

nooblamer, первоначальная постановка задачи с кучей GET-параметров не совсем понятна. Если вы хотите сделать ЧПУ, выбирайте основные параметры непосредственно из пути. Простой пример: Как сделать единую точку входа с ЧПУ?

Кстати, из-за этих GET-параметров у пользователей джумлы постоянные проблемы с дублями, которые нужно специально закрывать. Т.е. сначала дубли собственноручно порождаются, а потом с ними приходится бороться
(Добавление)
P.S. Первой статьей на том же сайте идет описание движка с простой моделью данных, при которой не используются ни хранимые шаблоны адресов, ни хранимые полные пути/адреса. Вместо этого части пути (слаги) хранятся в отдельных таблицах вместе с объектами соотв. типа.

miketomlin я уже решил то, что мне надо было, на входе получаю ЧПУ урл, вытаскиваю из базы json объект по этому улру, и работаю с ним, на мой взгляд это куда удобнее, чем работать с параметрами из ЧПУ пути, так как отпадает необходимость привязываться к структуре ЧПУ урл, урл может иметь такой, например, вид: blalba/blabla/catname/subcatname /articleblabla для любого компонента и, например, параметра id документа, а если работать с параметрами в самом ЧПУ урла, то нужно было бы эксплодить его и быть привязанным к явному обозначению в первом параметре, как к компоненту (blalba/), во втором к опции компонента (blalba/) и т.д., а с моим примером нет этой необходимости, урл может быть любым для любого компонента, опции, параметров.

И проблему дублей страниц тоже предусмотрел, в случае если не находится запись по ЧПУ, отдаю хедер 404 и показываю страницу ошибки, а ЧПУ и json объект формируется еще при добавлении/редактировании документа, поэтому там изначально никаких ошибок нет, и если ЧПУ найден, то значит всё в порядке и дальше. Но благодарю!

А еще не очень хорошо если есть страница site.ru/catalog/items/page/2/
но при этом нет например страницы site.ru/catalog/items/
На сколько я знаю поисковики это не сильно любят
(Добавление)
А отсюда вытекает, что иметь роутинг с привязкой по правилам маршрутизации компонентов лучше, чем иметь "свободно редактируемый" роутинг