Комментарии 21
НЛО прилетело и опубликовало эту надпись здесь
Как вопрос относится к данному топику?
По описанию плагина — это антиспам и для блогов в том числе.
WP уже давно перерос «бложики» и на нем можно делать достаточно разнообразные по тематике сайты. При том, как показывает практика, конечному администратору сайта на данной CMS, мало понимающему в верстке, программировании — очень удобно пользоваться WP.
По описанию плагина — это антиспам и для блогов в том числе.
WP уже давно перерос «бложики» и на нем можно делать достаточно разнообразные по тематике сайты. При том, как показывает практика, конечному администратору сайта на данной CMS, мало понимающему в верстке, программировании — очень удобно пользоваться WP.
НЛО прилетело и опубликовало эту надпись здесь
> js, который собирается на бекенде — это, мягко говоря, очень пахнущий код.
Так это проблема уж не CMS, а плагинов, которые не могут предоставить возможность отключать кэш для каких-то блоков. Хотя смутно себе это представляю. Возможно, какой-то механизм должна предложить сама CMS для плагинов, чтобы не приходилось костыли писать для всевозможных плагинов кеширования.
> зачем так мужественно побеждать ВП и его говно-код, если можно использовать чтото более подходящее?
Кто-то побеждает, кто-то пользуется. Предложите пример хорошей CMS, на которой можно за 4-5 дня сделать хороший сайт-визитку, лендинг, за неделю-две сделать магазин, где не было бы проблем, говно-кода и т.д… При этом обычному пользователю не надо будет тратить кучу времени на панели администратора.
И да, я за качественное исполнение в программной части, но и не стоит забывать, что конечному заказчику не важно какой код, главное, безопасный. А WP обновляется достаточно часто и еще не было у меня случаев взлома WP.
> и да, минусить в карму — это вин, однозначно.
Зачем это писать? Кто минусил — ему это не интересно, думаю
Так это проблема уж не CMS, а плагинов, которые не могут предоставить возможность отключать кэш для каких-то блоков. Хотя смутно себе это представляю. Возможно, какой-то механизм должна предложить сама CMS для плагинов, чтобы не приходилось костыли писать для всевозможных плагинов кеширования.
> зачем так мужественно побеждать ВП и его говно-код, если можно использовать чтото более подходящее?
Кто-то побеждает, кто-то пользуется. Предложите пример хорошей CMS, на которой можно за 4-5 дня сделать хороший сайт-визитку, лендинг, за неделю-две сделать магазин, где не было бы проблем, говно-кода и т.д… При этом обычному пользователю не надо будет тратить кучу времени на панели администратора.
И да, я за качественное исполнение в программной части, но и не стоит забывать, что конечному заказчику не важно какой код, главное, безопасный. А WP обновляется достаточно часто и еще не было у меня случаев взлома WP.
> и да, минусить в карму — это вин, однозначно.
Зачем это писать? Кто минусил — ему это не интересно, думаю
Опишите что то более подходящее. На данный момент WP хорош соответствием понятию «Из коробки».
Большинство дргих систем требует девайс «Напильник», ssh и ftp доступ.
Видимо от вас и ждали реплики про карму.
Большинство дргих систем требует девайс «Напильник», ssh и ftp доступ.
Видимо от вас и ждали реплики про карму.
НЛО прилетело и опубликовало эту надпись здесь
Лендинг — согласен, статикой лучше.
openCart идеален по коду? Да, есть MVC. Но как насчет костылей с qmod (или как-то так), через который написано куча плагинов, т.к. иначе их не написать, не залезая в исходники движка. Не знаю, исправили это во 2 версии или нет, но в wordpress хоть хуки есть и они покрывают 95% необходимого, когда нужно внедрить свой функционал в систему.
И как в openCart решается вопрос, затронутый в данном топике?
«остается скачать с магазина тем понравившийся шаблон » — в 60-70% случаев шаблон приходится допиливать под потребности клиента. Чаще клиенты заказывают отдельно дизайн. Но при чем здесь CMS?
Вы же писали, что WP — это ужасный код. Отсюда и возник вопрос о CMS с нормальным кодом, где не нужны напильники.
openCart идеален по коду? Да, есть MVC. Но как насчет костылей с qmod (или как-то так), через который написано куча плагинов, т.к. иначе их не написать, не залезая в исходники движка. Не знаю, исправили это во 2 версии или нет, но в wordpress хоть хуки есть и они покрывают 95% необходимого, когда нужно внедрить свой функционал в систему.
И как в openCart решается вопрос, затронутый в данном топике?
«остается скачать с магазина тем понравившийся шаблон » — в 60-70% случаев шаблон приходится допиливать под потребности клиента. Чаще клиенты заказывают отдельно дизайн. Но при чем здесь CMS?
Вы же писали, что WP — это ужасный код. Отсюда и возник вопрос о CMS с нормальным кодом, где не нужны напильники.
НЛО прилетело и опубликовало эту надпись здесь
> да, он не идеален, но всяко лучше WP.
Обоснованно, да
> то что тему нужно допиливать под запрос клиента тоже не минус движка. под ВП точно также придется тему допиливать.
Видимо, у Вас не очень большой опыт.
Например, делал недавно интернет магазин, где своя система скидок, для которой нет готовых плагинов, соответственно, интеграции в шаблон. Допиливать пришлось бы под любую CMS.
Если так рассуждать, что некоторые потребности клиента не могут быть покрыты стандартным функционалом, то тут можно начинать с корня, что значит и бизнес построен неправильно, да?
> если хотите прямо академический код, то смотрите на мадженто или ShopWare
Мадженто для магазина в 10000 товаров — это как пушкой по воробьям.
> не используется js генерируемый на бекенде, как и везде, кроме плагинов ВП видимо
Если у нас есть конфигурируемые параметры, которые затем обрабатываются с помощью JS, то как выходить из положения?
И да, у купленных тем тоже таких примеров куча — настройки слайдеров, например. Значит это неправильные шаблоны? Если отказываться от настраиваемости, то мы вернемся к пункту, которые обсудили ранее, где шаблон не может покрыть требования заказчика.
Обоснованно, да
> то что тему нужно допиливать под запрос клиента тоже не минус движка. под ВП точно также придется тему допиливать.
Видимо, у Вас не очень большой опыт.
Например, делал недавно интернет магазин, где своя система скидок, для которой нет готовых плагинов, соответственно, интеграции в шаблон. Допиливать пришлось бы под любую CMS.
Если так рассуждать, что некоторые потребности клиента не могут быть покрыты стандартным функционалом, то тут можно начинать с корня, что значит и бизнес построен неправильно, да?
> если хотите прямо академический код, то смотрите на мадженто или ShopWare
Мадженто для магазина в 10000 товаров — это как пушкой по воробьям.
> не используется js генерируемый на бекенде, как и везде, кроме плагинов ВП видимо
Если у нас есть конфигурируемые параметры, которые затем обрабатываются с помощью JS, то как выходить из положения?
И да, у купленных тем тоже таких примеров куча — настройки слайдеров, например. Значит это неправильные шаблоны? Если отказываться от настраиваемости, то мы вернемся к пункту, которые обсудили ранее, где шаблон не может покрыть требования заказчика.
НЛО прилетело и опубликовало эту надпись здесь
>> хотябы приличный MVC, который позволяет отделить мух (вывод инфы) от котлет (кастомной системы скидок)
Только, как написал выше, без внедрения в системные файлы — в openCart не внедрить свою систему. А обновили системные файлы — потеряли возможность обновляться.
В Wordpress реализовал это с помощью хуков, система обновляется без проблем и функционал не ломается.
> в e-commerce движках скидки в каком либо виде присутствуют всегда. Значит в нормальном движке вам нужно подпилить/заменить БЛ (рассчет этой скидки в зависимости от нужных параметров), а уж в шаблоне они выведутся нормально
Есть 3 типа товаров (как их пометить?). Для каждого типа есть свой порог для оптовой цены и для среднего опта. Скидка считается из расчета набранной суммы в корзине + по прошлым покупкам для каждого типа товара отдельно. Назовите хоть 1 плагин, который сможет такое сделать из коробки. Назовите хоть 1 шаблон, который адаптировался под все доработки такого плана.
>> Если у нас есть конфигурируемые параметры, которые затем обрабатываются с помощью JS, то как выходить из положения?
уж всяко не генерацией js-а на бекенде. js должен быть статическим, и в идеале грузиться с cdn.
в случае слайдеров:
1) либо верстка слайдеров генерится на бекенде и js её оживляет, добавляя реакцию на клики/свайпы
2) либо js аяксом тянет с бекенда список елеметов и ихъ параметры и динамически генерит контент на странице
но ни в 1 ни во 2 случае ему не нужны никакие динамические параметры
Хм, разве не п. 2 предлагается в статье?
> ЗЫ: имхо, качество кода самого ВП лишь стимулирует писать под него такие же плагины.
Я не спорю, что код там не очень, но иногда вопрос результата и клиентов не волнует код. CMS удобна, гибкая под разные задачи, при должном подходе не ломают
Только, как написал выше, без внедрения в системные файлы — в openCart не внедрить свою систему. А обновили системные файлы — потеряли возможность обновляться.
В Wordpress реализовал это с помощью хуков, система обновляется без проблем и функционал не ломается.
> в e-commerce движках скидки в каком либо виде присутствуют всегда. Значит в нормальном движке вам нужно подпилить/заменить БЛ (рассчет этой скидки в зависимости от нужных параметров), а уж в шаблоне они выведутся нормально
Есть 3 типа товаров (как их пометить?). Для каждого типа есть свой порог для оптовой цены и для среднего опта. Скидка считается из расчета набранной суммы в корзине + по прошлым покупкам для каждого типа товара отдельно. Назовите хоть 1 плагин, который сможет такое сделать из коробки. Назовите хоть 1 шаблон, который адаптировался под все доработки такого плана.
>> Если у нас есть конфигурируемые параметры, которые затем обрабатываются с помощью JS, то как выходить из положения?
уж всяко не генерацией js-а на бекенде. js должен быть статическим, и в идеале грузиться с cdn.
в случае слайдеров:
1) либо верстка слайдеров генерится на бекенде и js её оживляет, добавляя реакцию на клики/свайпы
2) либо js аяксом тянет с бекенда список елеметов и ихъ параметры и динамически генерит контент на странице
но ни в 1 ни во 2 случае ему не нужны никакие динамические параметры
Хм, разве не п. 2 предлагается в статье?
> ЗЫ: имхо, качество кода самого ВП лишь стимулирует писать под него такие же плагины.
Я не спорю, что код там не очень, но иногда вопрос результата и клиентов не волнует код. CMS удобна, гибкая под разные задачи, при должном подходе не ломают
НЛО прилетело и опубликовало эту надпись здесь
>именно с модулями openCart бодаться не приходилось. хватало доступных в магазине.
50% модулей для не 2 версии устанавливаются с заменой системных файлов. Часть из них через qmod. Если просто заменяют, то 2 модуля перезатирают друг друга.
> а вот модули в magento и OXID встраиваются в систему без проблем.
Не сталкивался, не могу ничего сказать
>> Есть 3 типа товаров (как их пометить?)
а как вы их разделяете? по категории? по артикулу? по названиях? не факт что для этого вообще нужны какието допилы
По тегам
>> Для каждого типа есть свой порог для оптовой цены и для среднего опта. Скидка считается из расчета набранной суммы в корзине + по прошлым покупкам для каждого типа товара отдельно. Назовите хоть 1 плагин, который сможет такое сделать из коробки. Назовите хоть 1 шаблон, который адаптировался под все доработки такого плана.
Скейл цены от количества искаропки:
http://i.piccy.info/i9/d6807c9075551da6419daf5abab0b5e6/1461076128/37491/1026532/scale.png
Не подходит, считается не по количеству товара, а по общей сумме товаров определенного типа, находящегося в корзине и приобретенного ранее.
>искаропки там также есть разные цены для груп юзеров, скидки для груп юзеров, смена цен по наступлению определенной даты (флеш распродажи например), расчет скидка от суммы заказа,
в сторе модулей есть модули бонусных систем (накопление бонусов за покупку и их последующее использование в новых заказах)
В моем случае — было для всех групп пользователей. Бонусные начисления за покупки тоже не решают задачу.
>> Хм, разве не п. 2 предлагается в статье?
в статье это предлагается как решение проблемы для ВП. хотя в нормальных системах такой пробелмы просто нет.
Не совсем понимаю логики.
Думаю, что обсуждение ушло совсем в другое русло, поэтому, откланиваюсь. Всего хорошего
50% модулей для не 2 версии устанавливаются с заменой системных файлов. Часть из них через qmod. Если просто заменяют, то 2 модуля перезатирают друг друга.
> а вот модули в magento и OXID встраиваются в систему без проблем.
Не сталкивался, не могу ничего сказать
>> Есть 3 типа товаров (как их пометить?)
а как вы их разделяете? по категории? по артикулу? по названиях? не факт что для этого вообще нужны какието допилы
По тегам
>> Для каждого типа есть свой порог для оптовой цены и для среднего опта. Скидка считается из расчета набранной суммы в корзине + по прошлым покупкам для каждого типа товара отдельно. Назовите хоть 1 плагин, который сможет такое сделать из коробки. Назовите хоть 1 шаблон, который адаптировался под все доработки такого плана.
Скейл цены от количества искаропки:
http://i.piccy.info/i9/d6807c9075551da6419daf5abab0b5e6/1461076128/37491/1026532/scale.png
Не подходит, считается не по количеству товара, а по общей сумме товаров определенного типа, находящегося в корзине и приобретенного ранее.
>искаропки там также есть разные цены для груп юзеров, скидки для груп юзеров, смена цен по наступлению определенной даты (флеш распродажи например), расчет скидка от суммы заказа,
в сторе модулей есть модули бонусных систем (накопление бонусов за покупку и их последующее использование в новых заказах)
В моем случае — было для всех групп пользователей. Бонусные начисления за покупки тоже не решают задачу.
>> Хм, разве не п. 2 предлагается в статье?
в статье это предлагается как решение проблемы для ВП. хотя в нормальных системах такой пробелмы просто нет.
Не совсем понимаю логики.
Думаю, что обсуждение ушло совсем в другое русло, поэтому, откланиваюсь. Всего хорошего
НЛО прилетело и опубликовало эту надпись здесь
По долгу службы приходится развивать плагины для более чем 10 CMS, так вот в поддержку WordPress скажу, что тамошняя система хуков наиболее продуманная и документированная.
Поддерживать тамошние плагины одно удовольствие.
Поддерживать тамошние плагины одно удовольствие.
О том и речь была, что цепочку обсуждения потеряли.
Система скидок, которую сделал хуками не затрагивает фронт и при отключении прекрасно все работает без нее, а Вы уже все перемешали и выставили ситуацию иначе.
Система скидок, которую сделал хуками не затрагивает фронт и при отключении прекрасно все работает без нее, а Вы уже все перемешали и выставили ситуацию иначе.
Чтобы js-код кэшировался, его не нужно генерировать динамически, а необходимые переменные запрашивать по ajax с сервера по динамическому адресу. Вот и вся статья.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Решаем проблему с кешированием динамического JavaScript кода на фронтенд WordPress