Jump to content

Сделать ЧПУ на сайте по принципу


Recommended Posts

kors я сделал для себя, это не то решение которое нужно вам, по этому я его и не выкладываю.
Для кого писал, ёк макарёк?! Я начинаю задумываться в вашей адекватности. Столько раз писал одно и тоже и вы до сих пор этого не поняли. Ну как так-то ((
p.s. в первом посте вообще про 1.4 говориться, а я стараюсь делать только на 2.х ибо не вижу смысла развивать устаревший продукт.
Link to post
Share on other sites
Простейший случай: надо, например, чтобы
1. http://site.ru/divan - было ссылкой на категорию
2. http://site.ru/krovat - было ссылкой на статическую страницу

Этот простейший случай тащит за собой написание интерпретатора подвязанного к базе, ибо простейшими методами mod_rewrite вы этого не реализуете (и понятное дело, он же не может додумывать что вам нужно, статичную страницу или же динамичный массив).

Ваше решение подразумевает:
Отправление ВСЕХ страниц из запроса к новому модулю (файлу?) который будет брать запрос, прогонять его через базу, определять что это за тип страницы, и вызывать её. Тем самым вы по определению добавите нагрузку на сервер и увеличите время отклика сайта. Хотя если вдуматься решение так же достаточно простое. (только зачем оно - вопрос спорный)
Link to post
Share on other sites

Сейчас прикинул, можно вообще без базы сделать, только извратиться с запросами и сделать псевдоурлы. По аналогии с "хлебными крошками" сделать и всё.

Берём урл, выдираем из него первую часть запроса ($1) и смотрим что за страница, если "page" отправляем на статику, если "news" отправляем в новости, если что-то иное идем дальше.

Смотрим последнюю часть запроса ($?) и по ней загружаем либо категорию ("../../.../nazvanie_categoryy") либо товар ("../../../topvar.htm") тем самым мы сможем нагородить конструкцию вида - category/podcategory/tovar.htm и избавиться от лишних запросов.

Link to post
Share on other sites

aimatrix
Моё виденье аудитории симплы как-раз в тех, кто программист == пользователь, тоесть те люди кто не готов прибегать к написанию собственной системы но хочет сэкономить на доработках сделая только нужное. Как следствие простота ЧПУ это именно тот случай когда покупатель симплы сам в силах подправить вид чпу под себя. Это и реализовано.

Совсем не значит, что версия 2.x лучше.
Я не берусь решать что лучше что хуже. Мой опыт показывает что версия 2.х сейчас популярнее, и сделав одно решение я смогу обхватить большую аудиторию потенциальных покупателей, что "есть хорошо" для меня как для потенциального продавца доработок.

Об отсутствии этого интерпретатора и шла речь.
Понял вас.

Зачем извращаться? Должно быть сделано как положено, причем автором движка.
Затем что любое решение будет извращением, ибо затронет не 1 маленькое изменение а глубокое изменение системы, которое в свою очередь, в связи с отсутствием модульности, очень усложнит установку на доработанные системы и в последующем осложнит обновление всей системы == извращение. Что писать и как это уже решать автору а не нам с вами.
Link to post
Share on other sites
Кому - программисту? Просто должно быть пользователю.

Понадобился конкретному товару url скажем вида категория/подкатегория/товар - пользователь должен иметь возможность сделать это легко и как можно быстрее.

Ему же начинают оправдывать отсутствие банальных функций в системе домыслами.

Увеличение функциональности на 1% усложняет код на 10%. Импера яркий тому пример.
Link to post
Share on other sites

даю поверхностный намек как реализовать ваше ЧПУ, запрашиваем в БД по последнему сегменту урл (запррашиваем товар, категорию и т.д.) какой етап вернул результат тот и виев отображаем

Link to post
Share on other sites
даю поверхностный намек как реализовать ваше ЧПУ, запрашиваем в БД по последнему сегменту урл (запррашиваем товар, категорию и т.д.) какой етап вернул результат тот и виев отображаем

Верно, для каждой загрузки страницы прийдется делать поиск в таблице товаров, страниц, категорий, блога и тд. Куча лишних запросов на любой чих.
Плюс при редактировании товаров, страиц и тд нужно будет опять же искать по всей базе нет ли таких же URL у других товаров/страниц/категорий, при импорте, и во многих других местах.
Как я и сказал, увеличим функциональность на 1%, а сложность кода возрастет на 10%
Link to post
Share on other sites

kors тут как-раз всё наоборот, эта CMS для тех кто хочет простой код который сам может исправить даже простой человек, автор этого и добился. А ваши специальные запросы реализуются фрилансерами. И опять таки: не нравиться - не покупай.

Трудности и возрастание сложности кода на каждый из таких личных запросов превращает CMS в империю или подобные (функциональные, но совершенно недопиливаемые разумными методами)

Link to post
Share on other sites
  • 2 weeks later...

Очень странно. Поставлен конкретный вопрос, а половина топика - демагогия на тему идеологии CMS. :)
Если я правильно понял, то итогом темы является решение написать интерпретатор, подвязанный к базе. (sheeft)
Сколько способов реализации проблемы существует? Какие из них наиболее оптимальны с точки зрения нагрузки на сайт?

Link to post
Share on other sites

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

Link to post
Share on other sites
  • 1 year later...

Хоть и не понял, как Ваш странный вопрос относится к обсуждаемой теме, но могу ответить: до сих пор считал, что умею. Если не согласны, то объясняйтесь понятнее...

 

Мне нужно категория в ЧПУ. а у тебя ТОВАР!

Link to post
Share on other sites

Если имеете в виду тексты ссылок, то у меня в ЧПУ тексты произвольные.

Если имеете в виду, что Вам нужны ЧПУ для страниц категорий, то можно было бы и догадаться, что сделанное для товаров я бы мог перенести и на категории.

 

 

Думать и соображать хоть немного умеете?

Или ждете, что Вам кто-то поднесет готовое решение сразу на блюдечке с голубой каемочкой?

Надо меньше шлаком и пабликом барижить...

А вот на счет думать и соображать тут можно поспорить..

Я же не продаю паблик)

Link to post
Share on other sites
  • 2 months later...
  • 3 years later...

 

Верно, для каждой загрузки страницы прийдется делать поиск в таблице товаров, страниц, категорий, блога и тд. Куча лишних запросов на любой чих.

Плюс при редактировании товаров, страиц и тд нужно будет опять же искать по всей базе нет ли таких же URL у других товаров/страниц/категорий, при импорте, и во многих других местах.

Как я и сказал, увеличим функциональность на 1%, а сложность кода возрастет на 10%

Не обязательно проверять есть ли такая страница, бренд, пост, товар прочее, достаточно создать доп. таблицу в которой хранить ID объекта, сегмент URI и его контроллер\вид, далее при загрузке страницы в главном виде проверять текущий URI, а именно его последний сегмент, если такой найдется то используем вид который указан в таблице, иначе $module = 'PageView'; и $_get['page_url'] = '404';

На мой взгляд лучшее решение предложенное на форуме. Да тут есть один минус это доп. таблица, но она будет использоваться всего один раз, другой вопрос при обновлении объектов.

Edited by Noxter
Link to post
Share on other sites

Скоро появиться WIKI по симпле, там выложим свои решения, увидите насколько все просто и не дорого если думать головой ;)

Дайте ссылочку, пожалуйста.
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...