Не ломайте голову.
Во-первых нужно экранировать точку перед html.
Во-вторых для Вашей цели с перечисленными адресами регулярка будет работать.
Если действие выражения нужно ограничить только псевдокаталогом catalog - нужно немного ее модифицировать.
как то так, но я не спец по регуляркам - по идее должно работать
Если я правильно все понял, то в первой части правила надо использовать что-то похожее на:
правда в [a-z] надо указать все допустимые символы. Но это слишком упрощенное правило, если направление мысли я понял правильно, то его надо будет слегка подправить
вообще постановка вопроса с произвольным url - это в корне неправильно. ЧПУ изначально - приведение строки запроса в понятный юзеру вид. Да и проблемы потом возможны с дублями страниц и т.п.
Сам получаю все параметры из урл в скрипте - удобнее намного.
ИМХО чем короче url - тем лучше.
Редирект или перенаправление запроса на исполняемый скрипт с параметрами?
Ни одной ссылки не увидел. Дайте ссылки на успешные магазины "обо всем", с такой же системой работы, которую Вы предлагаете.
Я поверю в возможную успешность проекта в том случае, если всем заниматься будете Вы сами, лишь беря за заказы с людей определенный процент. А вот если они сами должны будут заниматься наполнением магазина, сео, юзабилити... вообщем это будет бред. Но в этом случае никто не мешает Вам найти не компанию, которой за процент Вы будете сливать заказы, а поставщиков и отдел доставки + управляющего направлением, которые будут приносить Вам в разы больше прибыли.
Я обозначу минусы (топик не читал):
- Проблема с сео (если не на поддоменах - то вообще лажа) - адаптация очень тяжелая будет под ПС.
- Проблема с наполнением - каждый товар по своему продается. Одному надо кучу характеристик, второму - определенную подачу, третий продается комплектом с еще десятком приблуд
- Проблема с пересечениями ассортимента магазинов - она вообще не решаема.
- Развитие - отдельная проблема. За Вас развивать никто не будет, а со стороны магазинов - ну кто будет всерьез вкладывать пусть даже и трудоресурсы в то, что он не контролирует, и ему не принадлежит.
Вообщем на мой взгляд слишком много минусов, слишком тяжело будет в реализации, очень тяжело будет в маркетинговом продвижении, чрезвычайно тяжело будет в поисковом продвижении и очень (ИМХО) скуден будет выхлоп. Имхо опять же, но за это время с многократно меньшими вложениями и денег и времени можно наштамповать с десяток своих магазинчиков и наслаждаться жизнью. По крайней мере отдача будет обязательно.
Можно. $_REQUEST.
При помощи записи в базу данных, записи в файл, наконец накопления в памяти (вариант для мазахистов, но все же). Все обработанные ссылки пишем куда надо, потом при проверке необходимости получения страницы сверяем ее url с записями в базе(файле, памяти) и если такой записи нет - заходим на страницу.
При этом не забудьте учитывать возможное добавление идентификатора сессий, иначе бродить придется до бесконечности.
Ссылку я дал. Интеграция еще проще, чем раньше - на том же сайте есть примеры. Работает очень быстро, переваривает очень большие объемы.
Но в главном я поддержу отписавшихся тут - если на Вас работает программист, если у Вас нет человека, администрирующего сервер - то и убить базу врядли у Вас получится, поэтому надобность в этом стремиться к нулю. В сложных ситуациях обойтись бэкапом из админки тоже врядли получится, поэтому придется прибегать пусть к единичным, но обращениям к специалисту.
nikonlay, мне кажется что Вы просто искали работу по интересам =) А то что Ваши навыки небыли бы востребованы полностью - это нормально. Покажите выпускника любого высшего учебного заведения, который в работе использует все знания, которые давались ему по программе обучения....
Не знаю для чего это Вам... На всякий случай можете проверить все запросы, по которым идут обращения при генерации страницы. В CMS зачастую запросы дублируются в различных модулях - возможно обойтись и без доп.запроса. Иногда проще сохранить в массив выборку и использовать ее глобально по всему коду генерации страницы.
Я для таких целей пользовался классом работы с БД и выводил все запросы с временем их генерации в отладочное окно. Потом проверял обращения к таблицам, выявлял избыточные, дублирующиеся запросы, тяжелые...
Но скажу точно - JOIN очень медленный и ресурсоемкий - лучше бОльше легких запросов использовать.
