SeVlad

У тебя есть другие критерии оценки уровня сложности реализации той или иной задачи? Предложи - с удовольствием послушаю.

Я пока знаю только эти и поэтому на них и опираюсь.

Но лучше бы ты вообще не трогал технические вещи, право слово.

Ну зрдамояра... А я как-то по другому сказал? Я  в ответ на твой отсыл к испокон века (ака в "стародавние времена" первых версий джумлы) так и сказал - "тогда в джумле не было ЧПУ, а потом появился отдельный модуль". А вот  про "до сих пор этого нет" ничего не говорил.

Твой ламерский бред не имеет ничего общего с реальностью и вызван тем что я тебя неоднократно уличал в ламерстве и феймётстве балабоки.

А сколько это будет стоит и сколько займёт времени?  (Я даже открою секрет - "пасить" урлы будут разве что ламеры.)

Ок, разобрали, занесли - дальше что? Где в твоём "решении" логика формирования новых УРЛ (ты вообще понимаешь что ЧПУ формируются строго по задаваемым в движке правилам)? А где про эти циферки для новых станиц/товаров/итд?

:)

1. Насчёт "все" - ты сильно ошибаешься. ОЧЕНЬ сильно. :)

2. Картинки оптимизируют на сервере - единицы и те редко. Для обычного юзера на десктопе и проще и правильнее.

3. Процесс загрузки не станет сложнее. Те кто понимает -  уже делает как надо. Те же, кто [пока] нет - ровно так как ты написал в коде. :)

4. Да, ты прав - оптимизация обработка бинарников на сервере - один из методов борьбы с заливкой таких зловредов.

И всё это - не "из-за гугла", а следствие повышения квалификации.

Ну да, гугл можно сказать спасибо, что в тыкает в размеры графики. Правда, не всегда адекватно, но всё же хоть какая-то польза для ламеров.

Блин, я же уже это объяснил:

Это не понятно? Надо подробней?

А я ещё Мамбу помню. И? А рассказывать приходится т.к. то ли ты не знаешь, что в ядре джумлы "испокон веков" не было ЧПУ то ли делаешь вид что не знаешь что это был отдельный модуль.  Как сейчас - я действительно не в курсе, тк лет 10 её в руки не брал.

Давай я попробую ещё раз.

Если в адресах не используется ID (реальный ID), то перенос контента не взывает никаких дополнительных проблем/работ.

Если это они есть, то в случае пересвоения  ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)

Всё смешалось в доме Облонских :)

"Там" и не про ранжирование (про ражирование спрашивал ТС), и не про датировку (это частный случай). Там про цифры в урле для гуглоньса.

Если бы не было ЧПУ - тогда так и было бы. А тут по любому надо или полностью работать с ЧПУ либо парсить урл, вычленяя цифры. А с учетом того, что с другими адресами/сущностными где нет цифр движок уже как-то ж работает, то городить второй вариант как-то не логично и нецелесообразно.

Не, я не говорю что такого не может быть - я говорю, что это не так однозначно. Т.е. "легче" - далеко не всегда.

Я уже объяснил Антонию принципы строения базы и контента в ней. Не думал что и тебе надо было это разжевывать...

В джумле испокон веков не было ЧПУ :). Потом появился модуль SEF, который, если мне не изменяет память являлся костылём (таким же как модуль ЧПУ в SMF напр) - там не нормальный роутинг, а виртуальная страница, в которую инклудился контент. И да, в этом случае и нужен был ID тк по другому ещё сложнее определить что инклудить (писать сопоставления в базу, создавая тормоза напр).

ЗЫ. И у джумлы ИДшники писались в начало слага, а не в конце.

Нет никаких "групп" ID. SCU - это доп. поле данных, а не ID. ID в базе  - это чётко обозначенная сущность. "Искусственный ID" по большому счёту не является ID с т.з. базы.

Поэтому я и говорил... то что говорил в комменте Sitealert-у.

При том, что я комментировал "зачем это делалось". А  ТС просто интересуется длинной урла как факта ранжирования.

:) Если Вы такие умные - почему строем не ходите? (с) анек.

Я не говорил что невозможно - я говорил, что это может стать проблемой. Т.е. как минимум доп. расходами финансов и времени.