сам модуль каталога, как набор скриптов ставится конечно как набор файлов в одноимённую папку, например \includes\Modules\Catalog\ затем прописывается в системе в табличке engine_modules , дальше все найстройки делаются в БД через админку, и все категории и т.д. и т.п. тоже в админке задаются.
хваленый ЧПУ. Пока только в разделах(категориях) и некоторые системные штуки забиндены на нем (/cart , /registration). Но системные штуки хранятся в файле в виде массива и приоритет у них выше. /?m=cat&cid=18 эквивелентно /air-conditioner или /air-conditioner/ и даже /air-conditioner/?foo=bar вместе с /air-conditioner?foo=bar кроме того если отключен mod_rewrite можно воспользоваться ссылками типа /index.php/air-conditioner думаю о введении кириллицы, но скорее всего она будет превращаться в %33%43 и тд
а мне кажется логичнее, если будут вложенные ссылки т.е. в микроволновых печках есть "гриль" и когда выбираем гриль, логичнее и красивее будет ссылка вида /microwave/grille/
d1gi согласен. А какая-нить печка с моделью CE283DNR будет находиться по адресу "/microwave/grille/ce283dnr.html". Просто в данном примере хотел показать что можно делать как угодно, за исключением существующих файлов и системных rewrites. А вообще в админке будет кнопка "сшенерировать nice url". И формат таких urls можно будет настроить, отдельно для товаров, отдельно для категорий. Проблемка лишь в том, что русскоязычные titles будут транслитерироваться, а это не очень красиво.
Koc а не могли бы вы выложить код для реализации таких урл) А то больно интересна эта тема, а решения так и не понял
так-с, алгоритм: есть таблица url_rewrites (id, url, data) AS r есть таблица categories (id, title, rewrite_id) AS c добавляем раздел и заносим его в таблицу c. Если введен url проверяем его (что б не было повторяющихся, что б в нем не использовались символы ? + & и тд), добавляем в таблицу r и присваиваем c.rewrite_id идентификатор вставленной строки. В поле data вводим JSON или сериализованный массив данных о модуле и идентификаторе раздела. json(array('m'=> 'cat', 'id'=> id_вставленного_раздела)); перенаправляем в .htaccess все запросы на несуществующие директории или файлы к index.php в index.php получаем $_SERVER['REQUEST_URI'], отрезаем все, что правее символа ?, если такой существует конечно. Оставшуюся часть (пускай это переменная $url) trim'аем, отрезая не только пробелы но и слеш - /. Теперь в таблице r ищем строку у которой url равен нашей переменной $url. Если такой строки нет - 404, есть - достаем ячейку data и десериализуем ее (или json_decode). Получаем массив, который мержим с $_GET или $_REQUEST. Дальше работаем как хотим. Типа (include 'modules/' . $_GET['m'] . 'php'); внимание: если слева от ? ничего не осталось, то мы возможно в корне и ничего искать в таблице не нужно. Или эта строка не использует ЧПУ.
У меня реализовано вот так mod_rewrite и ЧПУ. Работает в связке с mysql, незнаю, хорошо это или плохо, но пока устраивает
А само решение, которое я использую оно как?? Потянет?? просто встречал в своей практике уж очень завернутые мод-реврайты, что не слишком ли все по-простому то бишь примитивному?
проблема (или нет проблемы?) моего решения в том, что параметры нужно указывать не через '/' а через какой-то другой символ, например ';'. то есть index.php/gallery/ya_na_otdihe/page/2 - нельзя index.php/gallery/ya_na_otdihe;page:2 - можно может добавить какие-то зарезервированные слова (page, from), которые сразу обрезать? или символ ';' вместо '/' тоже неплохо?
а еще фигня: предположим, что URL для новости будет: /news/2008/08/31/bla-bla - строка для нее будет найдена в базе, а новость показана. сотрем /31/bla-bla /news/2008/08 - по логике должно вывести все новости за август 2008. Но такой строки в базе нет. И откуда ей взяться? Да, можно сделать страницу контента и для нее сделать спецшаблон, который вызывал бы августовские новости. НО: это что же получается: для каждого месяца создавать страницу и свой шаблон? бред. Нужно вводить поддержку /news/%i/%i/%i/%s - как-то так в Drupal'е сделано. Но как это делать? проходить по строке регуляркой. А если таких правил будет сотня - проходить в цикле и проверять все регулярки? тогда распарсивание URL'ов будет дольше, чем генерация контента
index.php PHP: <? $url = trim($_SERVER['SCRIPT_URL'], '/'); $url = explode('/', $url); $pages = array( 'news' => 'news.php' //... ); if (array_key_exists($url[0], $pages)) { require_once( INCLUDE_DIR_ICQ . $pages[$url[0]] ); } else ... ?> news.php PHP: <? list(,$year, $month, $day) = $url; // в таком случае удобно хранить год, месяц и день в отдельных полях if ($year) { $sql[] = 'year'=$year; } if ($month) { $sql[] = 'month'=$month; } if ($day) { $sql[] = 'day'=$day; } $sql = implode(' AND ', $sql); ?>
Вльдемар дело в том, что модуль называется articles. И на основе него пользователи будут делать и новости и блоги и еще чего-нить. (первый уровень раздела - блог|новость, второй-третий - категории, подкатегории новостей, блогов) ну и урлы значит будут: /blogs/2008/11/23/blogozapis1 /blogs/2008/11/24/blogozapis-2 /news/2008/12/03/shok-timati-i-sobchak /news/2008/12/06/grud-kakoi-to-tetki это URLs для новостей. Они прикреплены непосредственно к модулю articles и записям с какими-то id. а вот когда стираем часть в конце /news/2008/12/03/ - должно выводить новости, добавленные 03.12.2008 /blogs/2008/11/24/ - блогозаписи за 24.11.2008 так вот, я не знаю, что конечный пользователь захочет поставить перед датой. Может быть для блогов даты не будет, будет категории (/blogs/cat1/cat2); для новостей будет дата.
имхо! наоборот! оч правильно навигацию объясняет тема лебедев http://www.artlebedev.ru/kovodstvo/sections/49/ я считаю что в УРЛе не должно быть НИКАКИХ двоеточий, запятых и тд и тп. кроме естественно вопросов и знака "=". бред типа "/o_kompanii" надо при создании страницы (к примеру если она хранится в базе) искоренять в "/about_us/". делается это просто: создается два поля в таблице, одно - для заголовка ("О компании"), другое - для УРЛа ("about_us"). лично мне, при просмотре сайтов с гавеной навигацией, часто, чтобы вернуться на уровень вверх, удобнее стереть с адресной строки буковки, до последней косой черты. думаю, я такой не один
1. Не нужны. Перевод на англ рулит 2. Не нужны такие, которые ты привел выше. Оптимальный вариант "/monitors/931cw", а оттуда уже "monitors/931cw/specification", "monitors/931cw/where_to_buy". Кстати у меня неделю назад полетел монитор 931BF А вообще в идеале, как описано в протоколе HTML и как это понимают поисковики, должно быть так: /monitors/index.html (HTML!!!) /monitors/931cw.html или /monitors/931cw/index.html /monitors/931cw/specifications.html
только не "where_to_buy", а "where-to-buy", потому что слово написанное через подчеркивание для поисковика есть одно слово. а через дефис - разные слова.