А я ещё Мамбу помню. И? А рассказывать приходится т.к. то ли ты не знаешь, что в ядре джумлы "испокон веков" не было ЧПУ то ли делаешь вид что не знаешь что это был отдельный модуль. Как сейчас - я действительно не в курсе, тк лет 10 её в руки не брал.
Давай я попробую ещё раз.
Если в адресах не используется ID (реальный ID), то перенос контента не взывает никаких дополнительных проблем/работ.
Если это они есть, то в случае пересвоения ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)
Всё смешалось в доме Облонских :)
"Там" и не про ранжирование (про ражирование спрашивал ТС), и не про датировку (это частный случай). Там про цифры в урле для гуглоньса.
Если бы не было ЧПУ - тогда так и было бы. А тут по любому надо или полностью работать с ЧПУ либо парсить урл, вычленяя цифры. А с учетом того, что с другими адресами/сущностными где нет цифр движок уже как-то ж работает, то городить второй вариант как-то не логично и нецелесообразно.
Не, я не говорю что такого не может быть - я говорю, что это не так однозначно. Т.е. "легче" - далеко не всегда.
Я уже объяснил Антонию принципы строения базы и контента в ней. Не думал что и тебе надо было это разжевывать...
В джумле испокон веков не было ЧПУ :). Потом появился модуль SEF, который, если мне не изменяет память являлся костылём (таким же как модуль ЧПУ в SMF напр) - там не нормальный роутинг, а виртуальная страница, в которую инклудился контент. И да, в этом случае и нужен был ID тк по другому ещё сложнее определить что инклудить (писать сопоставления в базу, создавая тормоза напр).
ЗЫ. И у джумлы ИДшники писались в начало слага, а не в конце.
Нет никаких "групп" ID. SCU - это доп. поле данных, а не ID. ID в базе - это чётко обозначенная сущность. "Искусственный ID" по большому счёту не является ID с т.з. базы.
Поэтому я и говорил... то что говорил в комменте Sitealert-у.
При том, что я комментировал "зачем это делалось". А ТС просто интересуется длинной урла как факта ранжирования.
:) Если Вы такие умные - почему строем не ходите? (с) анек.
Я не говорил что невозможно - я говорил, что это может стать проблемой. Т.е. как минимум доп. расходами финансов и времени.
Вот потому что ты не технарь - поэтому не знаешь что такое реальный и потому и не видишь проблемы.
Ок. объясню. Реальный ID - это ID записи в базе данных. (а "по товарной номенклатуре" называется SCU) Это уникальное значение в пределах как минимум одной таблицы, а то и всей базы.
Как правило эти ID движок сам назначает, автоматически. При импорте контента (не путать с импортом дампа базы!) эти ID в 99,9% случаев будут изменены.
А вот если применяются искусственные ID (доп произвольные поле данных) - тогда проблем намного меньше. Но всё равно, хоть и небольшие, но лишние телодвижения.
К сож, ни за что ты не отвечаешь - ты просто дешёвая балаболка.
В таком случае я смело могу заявлять что ты накроман, кидала и нетрадиционный.
1. "Страница 404" - ещё не ответ сервера 404. Проверяй именно ответ сервера.
2. Наверняка есть ссылки на эту страницу. Ищи их.
Вопрос о простоте работы с базой весьма спорный. ЧПУ есть ЧПУ.
Но если в урлах действительно ID (настоящие, а не искусственные), то это может стать большой проблемой при переносе контента. Не говоря уже про смену движка.
А делается (делалось так во всяком случае) тк. гугл требовал цифер в урле.. для гуглоньюс что ли, не помню уже, давно это было. Много одно время вопросов было - как добавить эти цифры в урл.
АПД. Да, точно, память не подвела - оно. :) После чего стало много подобных запросов.
Немножко беременна :)
В вопросах безопасности если такой шанс присутствует - это уже дыра, которую надо латать/защищаться от её использования.
Дешевый стрелочник-фейкомёт, ты тут показал кто не умеет - это у тебя не переезжает :)
