Добавить раскрывающий список с рубриками, не?
Уважаемый, вам же уже сказали, что зависит от движка.
Это могут быть и обычные свойства товара, вычитываемые из таблицы товаров, и вычисляемые походу величины, и т.п.
maks_m, как выше написали, вы немного не понимаете, как все это должно работать. Я вам недавно давал ссылку на простой фронт-энд-движок, в котором можно сделать шаблон вроде
<?php while ($row=getrow()): ?><div class="block"> <div class="num"><?=$row['num']?></div> <div class="task"><?=$row['task']?></div> <div class="desc"><?=$row['desc']?></div></div> <?php endwhile; ?>
и написать простой код для подготовки данных.
А потом уже пишете редактор (админку) для внесения записей в таблицу заданий без лишних тегов (теги форматирования, конечно, могут присутствовать, но серьезные структурные теги в БД в данном случае вносить не нужно). Если с написанием админки возникнут проблемы, можете воспользоваться подручными средствами вроде phpMyAdmin.
По cat_id все равно лучше. Если не хотите обременять себя лишними связями, можете сделать страницы категорий с адресами /category/<cat_id> и не выбирать названия категорий на других страницах (просто придумайте какое-нибудь абстрактное название типа «К списку»).
Также можно обойтись без непосредственного связывания таблиц. Просто считывайте таблицу категорий заранее, т.к. ее полное содержимое все равно может вам понадобиться (для меню и т.п.).
У вас что на каждый товар отдельный каталог с индексным файлом?!
Сделайте общее с главной правило, чтобы перенаправляло с обрезанием index.php в конце пути.
Цели разные. Какой-то раздел должен работать по защищенному HTTP. С какого-то раздела нужно грузить статик (картинки и т.п.). На каком-то разделе совсем другой движок. И т.п.
Именно так. Вот тут подруга выложила описание одного простого движка. Про детали реализации можно спросить там же, хотя принцип работы понятен и из описания. Таблицы роутинга как таковой нет. Вместо нее используется таблица категорий и достаточно строгий формат адреса, завязанный на нее и на таблицы объектов.
Поддержку Ragnarok в первом утверждении (обычно либо закрывают /article/page/1, оставляя для первой страницы адрес /article, либо, если вы по каким-то причинам решили использовать адрес с единицей, то делайте на нее постоянный редирект с /article). Еще дополню: подумайте над тем, чтобы оставить в поиске только стартовую страницу с адресом /article, а все остальные страницы списка закрыть.
Со вторым утверждением совершенно не согласен. Дублей не должно быть в принципе. Это касается и всяких INFO_PATHs, и GET-параметров. Возможно, к дублям с GET-параметрами поисковики относятся немного лояльнее (например, далеко не во всех движках есть контроль порядка их следования в запросе), но в описанной тут ситуации их точно нужно закрывать. Раз даже номера страниц передаются в пути, то вполне возможно что GET-параметры не используются на сайте вовсе. Тогда закрыть будет проще. В целом же все зависит от движка. .htaccess тут не всегда помогает. Приходится делать и хаки.
Как обычно, ставить на ауке освобождающихся сразу у нескольких осн. регистраторов. Вполне возможно, что этот домен интересен только вам и потенциальному покупателю, тогда достаточно, минуя аукцион, лишь подгадать время и надеяться, что покупатель не очень сведущ в делах перехвата.
Да, прикольная тема.
qpile, если он уведет у вас клиента, уволите его.
Пока что больше похоже на «ничего не хочу делать, даже общаться с клиентами! Где кнопка Бабло?!»
