Ну зрдамояра... А я как-то по другому сказал? Я в ответ на твой отсыл к испокон века (ака в "стародавние времена" первых версий джумлы) так и сказал - "тогда в джумле не было ЧПУ, а потом появился отдельный модуль". А вот про "до сих пор этого нет" ничего не говорил.
Антоний Казанский#: та задача из разряда начального уровня - спарсить, разобрать, занести нужные данные в таблицы БД, сформировать новые URL-ы и далее для контроля - сравнить перечень URL-ов старого сайта с новым.
А сколько это будет стоит и сколько займёт времени? (Я даже открою секрет - "пасить" урлы будут разве что ламеры.)
Ок, разобрали, занесли - дальше что? Где в твоём "решении" логика формирования новых УРЛ (ты вообще понимаешь что ЧПУ формируются строго по задаваемым в движке правилам)? А где про эти циферки для новых станиц/товаров/итд?
timo-71#: После того, как гугла пнул оптимизировать картинки, со временем все станут это делать. => процесс загрузки картинки, станет несколько сложней чем
:)
1. Насчёт "все" - ты сильно ошибаешься. ОЧЕНЬ сильно. :)
2. Картинки оптимизируют на сервере - единицы и те редко. Для обычного юзера на десктопе и проще и правильнее.
3. Процесс загрузки не станет сложнее. Те кто понимает - уже делает как надо. Те же, кто [пока] нет - ровно так как ты написал в коде. :)
4. Да, ты прав - оптимизация обработка бинарников на сервере - один из методов борьбы с заливкой таких зловредов.
И всё это - не "из-за гугла", а следствие повышения квалификации.
Ну да, гугл можно сказать спасибо, что в тыкает в размеры графики. Правда, не всегда адекватно, но всё же хоть какая-то польза для ламеров.
Антоний Казанский#: Новые ID сгенерированные CMS-ой в URL-е не выводить, а выводить те, что мы спарсили из исходной строчки (тогда это уже даже не ID, а просто параметр в строке URL-а). Так чего ж там такого особенного-то?
Блин, я же уже это объяснил:
SeVlad#: Если это они есть, то в случае пересвоения ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)
Sitealert#: Что-то несусветное городишь. И да, я с Джумлой работаю с самой первой версии. Так что можешь не рассказывать, что там было и что там есть.
А я ещё Мамбу помню. И? А рассказывать приходится т.к. то ли ты не знаешь, что в ядре джумлы "испокон веков" не было ЧПУ то ли делаешь вид что не знаешь что это был отдельный модуль. Как сейчас - я действительно не в курсе, тк лет 10 её в руки не брал.
Антоний Казанский#: Ok. Я бы сказал - доп. задачей. Любые направленные рабочие действия - это и есть набор задач. Но каким-то отличительных проблем здесь я действительно не вижу.
Давай я попробую ещё раз.
Если в адресах не используется ID (реальный ID), то перенос контента не взывает никаких дополнительных проблем/работ.
Если это они есть, то в случае пересвоения ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)
Антоний Казанский#: Так там не про ранжирование, там про датировку материалов в учете Гугл.Новостей.
Всё смешалось в доме Облонских :)
"Там" и не про ранжирование (про ражирование спрашивал ТС), и не про датировку (это частный случай). Там про цифры в урле для гуглоньса.
Sitealert#: Ничего спорного. По ID продукт мгновенно находится в БД, без всяких ухищрений.
Если бы не было ЧПУ - тогда так и было бы. А тут по любому надо или полностью работать с ЧПУ либо парсить урл, вычленяя цифры. А с учетом того, что с другими адресами/сущностными где нет цифр движок уже как-то ж работает, то городить второй вариант как-то не логично и нецелесообразно.
Не, я не говорю что такого не может быть - я говорю, что это не так однозначно. Т.е. "легче" - далеко не всегда.
Sitealert#: В остальных случаях больших проблем нет.
Я уже объяснил Антонию принципы строения базы и контента в ней. Не думал что и тебе надо было это разжевывать...
Sitealert#: А в той же Джумле испокон века ID писался в URL именно по соображениям удобства работы с БД, без каких-либо указок Гугла.
В джумле испокон веков не было ЧПУ :). Потом появился модуль SEF, который, если мне не изменяет память являлся костылём (таким же как модуль ЧПУ в SMF напр) - там не нормальный роутинг, а виртуальная страница, в которую инклудился контент. И да, в этом случае и нужен был ID тк по другому ещё сложнее определить что инклудить (писать сопоставления в базу, создавая тормоза напр).
ЗЫ. И у джумлы ИДшники писались в начало слага, а не в конце.
Антоний Казанский#: Мы и говорим про базу данных. Есть две области данных. Одна группа - ID движка, другая группа - SCU.
Нет никаких "групп" ID. SCU - это доп. поле данных, а не ID. ID в базе - это чётко обозначенная сущность. "Искусственный ID" по большому счёту не является ID с т.з. базы.
Поэтому я и говорил... то что говорил в комменте Sitealert-у.
Антоний Казанский#: Причём тут Гугл.Новости? TC приводит пример товарных URL-ов.
При том, что я комментировал "зачем это делалось". А ТС просто интересуется длинной урла как факта ранжирования.
Антоний Казанский#: конечно не сам, а через ТЗ программисту, но здесь решительно нет ничего сложного, для тех программистов, которые конечно умеют это делать.
:) Если Вы такие умные - почему строем не ходите? (с) анек.
Я не говорил что невозможно - я говорил, что это может стать проблемой. Т.е. как минимум доп. расходами финансов и времени.
Причём тут время и деньги?
У тебя есть другие критерии оценки уровня сложности реализации той или иной задачи? Предложи - с удовольствием послушаю.
Я пока знаю только эти и поэтому на них и опираюсь.
Всё, дальше точно не хочу обсуждать банальные вещи.
Но лучше бы ты вообще не трогал технические вещи, право слово.
Антоний Казанский #:
Нужная логика определяется на уровне ТЗ
..
программист затачивает движок
..
Умелым программером движок настраиваться и затачивается под любые нужды
Ну вот так и написал бы сразу.
Ну зрдамояра... А я как-то по другому сказал? Я в ответ на твой отсыл к испокон века (ака в "стародавние времена" первых версий джумлы) так и сказал - "тогда в джумле не было ЧПУ, а потом появился отдельный модуль". А вот про "до сих пор этого нет" ничего не говорил.
ты можешь заявлять что угодно, тут на форуме никто не воспринимает тебя всерьез
Твой ламерский бред не имеет ничего общего с реальностью и вызван тем что я тебя неоднократно уличал в ламерстве и феймётстве балабоки.
Смотри
та задача из разряда начального уровня - спарсить, разобрать, занести нужные данные в таблицы БД, сформировать новые URL-ы и далее для контроля - сравнить перечень URL-ов старого сайта с новым.
А сколько это будет стоит и сколько займёт времени? (Я даже открою секрет - "пасить" урлы будут разве что ламеры.)
Ок, разобрали, занесли - дальше что? Где в твоём "решении" логика формирования новых УРЛ (ты вообще понимаешь что ЧПУ формируются строго по задаваемым в движке правилам)? А где про эти циферки для новых станиц/товаров/итд?
А если ещё и связи..? Не, не слыхал про такое?После того, как гугла пнул оптимизировать картинки, со временем все станут это делать. => процесс загрузки картинки, станет несколько сложней чем
:)
1. Насчёт "все" - ты сильно ошибаешься. ОЧЕНЬ сильно. :)
2. Картинки оптимизируют на сервере - единицы и те редко. Для обычного юзера на десктопе и проще и правильнее.
3. Процесс загрузки не станет сложнее. Те кто понимает - уже делает как надо. Те же, кто [пока] нет - ровно так как ты написал в коде. :)
4. Да, ты прав - оптимизация обработка бинарников на сервере - один из методов борьбы с заливкой таких зловредов.
И всё это - не "из-за гугла", а следствие повышения квалификации.
Ну да, гугл можно сказать спасибо, что в тыкает в размеры графики. Правда, не всегда адекватно, но всё же хоть какая-то польза для ламеров.
Новые ID сгенерированные CMS-ой в URL-е не выводить, а выводить те, что мы спарсили из исходной строчки (тогда это уже даже не ID, а просто параметр в строке URL-а). Так чего ж там такого особенного-то?
Блин, я же уже это объяснил:
Если это они есть, то в случае пересвоения ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)
Это не понятно? Надо подробней?
Что-то несусветное городишь. И да, я с Джумлой работаю с самой первой версии. Так что можешь не рассказывать, что там было и что там есть.
А я ещё Мамбу помню. И? А рассказывать приходится т.к. то ли ты не знаешь, что в ядре джумлы "испокон веков" не было ЧПУ то ли делаешь вид что не знаешь что это был отдельный модуль. Как сейчас - я действительно не в курсе, тк лет 10 её в руки не брал.
Ok. Я бы сказал - доп. задачей. Любые направленные рабочие действия - это и есть набор задач. Но каким-то отличительных проблем здесь я действительно не вижу.
Давай я попробую ещё раз.
Если в адресах не используется ID (реальный ID), то перенос контента не взывает никаких дополнительных проблем/работ.
Если это они есть, то в случае пересвоения ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)
Так там не про ранжирование, там про датировку материалов в учете Гугл.Новостей.
Всё смешалось в доме Облонских :)
"Там" и не про ранжирование (про ражирование спрашивал ТС), и не про датировку (это частный случай). Там про цифры в урле для гуглоньса.
Ничего спорного. По ID продукт мгновенно находится в БД, без всяких ухищрений.
Если бы не было ЧПУ - тогда так и было бы. А тут по любому надо или полностью работать с ЧПУ либо парсить урл, вычленяя цифры. А с учетом того, что с другими адресами/сущностными где нет цифр движок уже как-то ж работает, то городить второй вариант как-то не логично и нецелесообразно.
Не, я не говорю что такого не может быть - я говорю, что это не так однозначно. Т.е. "легче" - далеко не всегда.
В остальных случаях больших проблем нет.
Я уже объяснил Антонию принципы строения базы и контента в ней. Не думал что и тебе надо было это разжевывать...
А в той же Джумле испокон века ID писался в URL именно по соображениям удобства работы с БД, без каких-либо указок Гугла.
В джумле испокон веков не было ЧПУ :). Потом появился модуль SEF, который, если мне не изменяет память являлся костылём (таким же как модуль ЧПУ в SMF напр) - там не нормальный роутинг, а виртуальная страница, в которую инклудился контент. И да, в этом случае и нужен был ID тк по другому ещё сложнее определить что инклудить (писать сопоставления в базу, создавая тормоза напр).
ЗЫ. И у джумлы ИДшники писались в начало слага, а не в конце.
Мы и говорим про базу данных. Есть две области данных. Одна группа - ID движка, другая группа - SCU.
Нет никаких "групп" ID. SCU - это доп. поле данных, а не ID. ID в базе - это чётко обозначенная сущность. "Искусственный ID" по большому счёту не является ID с т.з. базы.
Поэтому я и говорил... то что говорил в комменте Sitealert-у.
Причём тут Гугл.Новости? TC приводит пример товарных URL-ов.
При том, что я комментировал "зачем это делалось". А ТС просто интересуется длинной урла как факта ранжирования.
конечно не сам, а через ТЗ программисту, но здесь решительно нет ничего сложного, для тех программистов, которые конечно умеют это делать.
:) Если Вы такие умные - почему строем не ходите? (с) анек.
Я не говорил что невозможно - я говорил, что это может стать проблемой. Т.е. как минимум доп. расходами финансов и времени.