Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

Блог RGB

  • записей
    6
  • комментариев
    246
  • просмотров
    12 205

Как сделать толковый шаблон, вставая с дивана?


RGB

4 608 просмотров

 Поделиться

1405fe0512c5ed7c1791f596e75e65ac.png

У меня давно в голове назревала идея создать некое руководство с лучшими практиками и примерами того, как нужно и как не нужно делать при разработке шаблонов. Никакой саморекламы тут не будет, я адекватно воспринимаю критику и никогда не считал свои шаблоны (особенно первый – кто знает, тот поймет :)) эталонными с точки зрения разработчика, так что аргументированная критика только приветствуется.


Многие разработчики и фрилансеры называют лучшим шаблоном – default и в целом негативно относятся к коллегам-«шаблонописателям», на то есть немало причин, которые мы тут и обсудим. Для удобства восприятия информации дальнейшее изложение будет структурировано по пунктам, от более общих понятий к более частным.

 

1. Не воруйте чужие решения
 

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

 

Думаю, всем очевидно, что это – плохо, причем плохо не только с моральной или этической точки зрения, но и с точки зрения атмосферы в самом сообществе в целом (а еще про вас напишет Yoda). Одно дело, когда код шифруется от пиратов, но когда разработчику приходится скрывать свой код от коллег, т.к. он понимает, что его могут просто украсть – это никоим образом не способствует ни сплочению сообщества, ни доверию к разработчикам в целом.

 

 

2. Не шифруйте все подряд
 

Очевидный совет, который относится и к разработчикам модулей. Да, я знаю, что есть пираты (мне ли не знать этого?), с которыми вы так боретесь, но зачем кубить все? Каким образом стороннему разработчику потом разбираться в вашем коде? Каким образом пользователю внести свои индивидуальные доработки, если у вас закодированы и модель, и контроллер? А может быть в зашифрованном коде скрываются не только авторские решения, но и позаимствованные у коллег?

 

 

3. Не бойтесь пиратов
 

По моему опыту те пользователи шаблонов, что стабильно используют взломанные версии с вареза, никогда ничего у вас не купят, это просто не их путь. По этой же причине малоэффективно тратить время и силы на пуленепробиваемую антипиратскую защиту шаблона – если даже у вас получится сделать что-то подобное и шаблон чудом не будет взломан, то этот факт вовсе не заставит сотню пользователей вареза пойти к вам его покупать, им гораздо проще взять любой другой пиратский шаблон, чем тратить деньги на ваш.


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


Также не стоит забывать о том, что есть определенная категория пользователей, которые любят тестировать дополнения с вареза, а уже потом их покупают, поэтому если у вас не предполагается тестовой версии шаблона – это еще одна причина не бояться пиратов, а воспринимать их как один из своеобразных рекламных каналов.

 

 

4. Не демпингуйте

 

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

 

 

5. Следите за чистотой кода

 

Еще один очевидный совет, которым многие пренебрегают – все мы знаем, какое «удовольствие» разбирать чужой код. Порой читабельность кода не особо вырастает даже когда он не зашифрован, причем речь не только о коде как таковом, но и о верстке, скриптах и стилях.

 

Если в самом опенкарте полностью избежать спагетти-кода (и не создать проблем с совместимостью) не получится при всем желании, то это вовсе не значит, что стоит пускаться во все тяжкие и запихивать $this->config->get в tpl-файлы (знаю-знаю, у меня в 1-м шаблоне именно так все и сделано и мне до сих пор стыдно) или делать множественные sql-запросы в контроллерах. Если вы не знаете, что и как сделать правильно – установите на локалку девственно чистый опенкарт и изучайте его структуру и его файлы, он сам по себе как документация (которой нет).

 

 

6. Забудьте о «разработке через страдания»
 

Если вы хотите сделать толковый шаблон, то забудьте о принципе «Разработка через страдания», который звучит так: сначала сделай, чтобы было, затем — чтобы было красиво, затем — чтобы было быстро. Он совершенно неприменим к шаблонам. У вас все должно быть по возможности быстро, красиво и продумано до мелочей с самой первой версии, поскольку иначе ваш продукт просто не заметят и не оценят покупатели, а потом будет уже поздно.


Даже если у вас горят все сроки по возврату кредита/ипотеки и вся надежда только на скорейший релиз шаблона – не выпускайте сырой «неупакованный» продукт, вы этим сделаете только хуже! Наполнение вашего демо не должно быть основано на стандартных унылых товарах и баннерах OpenCart, презентация шаблона не должна быть написана в последний вечер на коленке в ворде, а в самом шаблоне должны быть продуманы даже такие мелочи, как склонения числительных в таймере акций (никаких «Осталось: 13 дн 11 час 18 мин», вы шаблон делаете для живых людей, у которых в русском языке есть склонения, а не для роботов).


На форуме представлена масса интересных и полезных дополнений, которые никогда не станут популярными по той простой причине, что их авторы – в первую очередь программисты, они не думают про упаковку своего продукта и считают простыню голого текста в описании дополнения презентацией. Они не думают о том, чтобы тратить время на «вылизывание» своего продукта и продумывание всех мелочей. Выражение «pixel-perfect» воспринимаются ими как что-то ужасно долгое и ненужное, но это совершенно не так, по крайней мере в случае с шаблонами – дьявол часто кроется именно в деталях.


Если у вас однотипные элементы имеют разную высоту, абзацы выравниваются с произвольными отступами, а иконка в круглой рамке выводится не по центру, а смещена вниз – уделите этому свое время. Разумеется, все должно быть в меру, а лучшее – враг хорошего, поэтому маниакальным перфекционизмом заниматься тоже не стоит, важнейший навык в этом плане – найти золотую середину между скоростью и качеством работы.

 

 

7. Не превращайте шаблон в сборку

 

Изначально задачи шаблонов заключались в обеспечении привлекательной «внешности» магазина, а функциональность обеспечивалась модулями. Но со временем началась своеобразная инфляция возможностей шаблонов, каждый новый старался превзойти предшественника по количеству настроек и модулей, входящих в комплект.

 

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


Почему же так произошло? Да потому что сложно «продать» средненький шаблончик, когда через дорогу продается такой же, но с фильтром и тележкой модулей в комплекте.
Правильный ли это путь? Конечно нет, поскольку понятие шаблона смешивается с понятием сборки, от чего страдают абсолютно все:

 

  • Пользователи получают неповоротливые громоздкие решения все-в-одном, чрезмерно сложные в целом и слабые по своим отдельным компонентам, в сравнении со специализированными модулями (смеха ради посмотрите возможности комплектного фильтра, входящего в состав какого-нибудь популярного шаблона, и модуля ocFilter), а постоянное наращивание таких решений у конкурентов вызывает у пользователя ложное предположение, что это нормальная практика – когда в шаблон впихивается модуль фильтра-блога-кешировщика и прочие несвязанные вещи
  • Разработчики модулей теряют потенциальных клиентов, поскольку пользователю шаблона порой легче мучиться со встроенным в шаблон решением, чем искать нормальную отдельную альтернативу, которую к тому же придется адаптировать под шаблон
  • Разработчики шаблонов вместо работы над внешним видом шаблона вынуждены постоянно наращивать его функциональность, стараясь угнаться за конкурентами, что доходит до абсурда и встраивания низкокачественных (а порой и вовсе чужих) решений, лишь бы не отстать в этой гонке

 

 

8. Не будьте эгоистом – ваш шаблон не единственный в мире

 

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

 

Самая распространенная ситуация – когда многочисленная орава комплектных модулей супер-шаблона имеет файлы шаблонов исключительно для каталога самого супер-шаблона и не имеют своих адаптированных версий (или хотя бы копий!) для каталога дефолтного шаблона. В итоге при переключении на default все страницы магазина, где использовались модули супер-шаблона, перестают открываться, ведь опенкарт просто физически не может найти файлы шаблонов этих модулей. Несчастному пользователю придется вручную выискивать и отключать все модули супер-шаблона лишь для того, чтобы хотя бы вернутся к исходному состоянию системы со стандартным шаблоном.


Вторая по распространенности ситуация – когда разработчику лень описать в документации процесс установки по шагам и все сводится к копированию всех файлов на хостинг (а модификаторов в /system) – уже догадались, что происходит при смене шаблона, когда пользователь понятия не имеет, что ему еще нужно по FTP ковыряться в системном каталоге и вручную удалять оттуда все модификаторы старого шаблона? И зачем в опенкарте сделан раздел Модификаторы с возможностью установки/удаления из админки?


И напоследок уже довольно редкий сценарий – разработчик просто перезаписывает файлы шаблона default (и хорошо если только файлы шаблона, а не контроллеры или библиотеки). Думаю, объяснять последствия таких действий нет смысла, тут проще обрадовать пользователя, все сжечь и ставить движок с нуля.

 

 

9. Думайте о совместимости с другими дополнениями

 

Бывает так, что у разработчика очень чешутся руки и он решает отказаться от устаревшего барахла, используемого опенкартом – убирает jquery, вырезает bootstrap или обновляет его с версии 3 на 4.5, убирает font awesome и т.д. Это все прекрасно и похвально, когда вы занимаетесь своим собственным магазином или выполняете работу для одного постоянного клиента и предупреждаете его о возможных рисках. Но если вы хотите сделать продукт, которым будете пользоваться не только вы и ваши друзья, подумайте на мгновение о том, с чем столкнется ваш пользователь при попытке установить какой-нибудь самый безобидный модуль, в котором используется сетка bootstrap (а это по определению абсолютно все модули, где идет вывод товаров), иконки font awesome (аналогично), а операции с DOM осуществляются через jquery.


Конечно, можно следовать трендам и делать костыли для поддержки других дополнений (к примеру, убрать bootstrap и спустя пару десятков недовольных пользователей сделать опцию в админке «Подключить Bootstrap» – гениально же?), но не проще ли следовать стандартам? Поверьте, рядовому пользователю плевать на то, современный ли вы используете фреймворк и все ли у вас сверстано на флексах или на таблицах, ему важно, чтобы все работало как положено и сайт не разваливался при попытке поставить сторонний модуль. А сделать говно можно как на Bootstrap и jQuery, так и на каком-нибудь Foundation с ваниальным js или нодой. Это все лишь инструменты в руках разработчика, только вот успешность проекта зависит не от инструментов, а от навыков, с которыми эти инструменты используются.

 

 

10. Учите матчасть

 

Один из последних пунктов по порядку, но не по важности – уделяйте внимание теории, причем я пишу не только про техническую составляющую, рассмотренную в п.5. Если вы делаете шаблон, то я бы очень советовал почитать Стива Круга, Филипа Котлера и других специалистов. Конечно, вы можете все делать и «по подобию» других шаблонов, ничего не понимая в дизайне, юзабилити и маркетинге, вдохновляясь на themeforest или на всяких дизайнерских CSSWinner и CSSDesignAwards, но есть один нюанс.


Если проводить аналогии, то похожим образом на китайских ноунейм-фабриках делают дешевые велосипеды с тяжелой стальной рамой, неправильной геометрией, посадкой и «одноразовыми» компонентами. При этом со стороны их изделия действительно выглядят как велосипеды (ну а что там такого, два колеса, рама и руль), но если присмотреться поближе или проехаться на них, имея опыт эксплуатации нормальных моделей – все станет очевидно. Недаром есть термин BSO (Bike-Shaped Object, объект в форме велосипеда), которым и нарекают подобные продукты.

 

Так и с шаблонами – если вы взялись их делать, стоит ли слепо копировать дизайн Юлмарта/Розетки в десятый раз? Почитайте пару книжек, поймите ошибки существующих решений и сделайте лучше!

 

 

11. Избегайте обращений к своему серверу

 

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

 

Конечно, разработчик может возразить, что он – профессионал, доступ к его серверу есть только у него, а сам сервер невероятно надежен и полностью защищен. Пока петух не клюнет, все так говорят, к примеру, один печально известный «эксперт по php и OpenCart» @addist, пока из-за обращений к его серверу у пользователей не начались массовые проблемы с доступностью магазинов, а в его модулях не нашли критическую уязвимость. Или одна печально известная веб-студия N***** у которой модули по окончанию срока действия лицензии в определенных ситуациях просто «вешали» сайты клиентов. Не все разработчики понимают, что это не просто неудачные реализации и недоработки – это огромные убытки для работающего магазина, которые могут не только лишить владельца какой-то прибыли, но и привести даже к закрытию всего бизнеса, поэтому таких практик нужно избегать любой ценой.

 

 

12. Полная документация сэкономит время как вам, так и пользователям

 

Думаю, тут и так все понятно из заголовка. Кто-то возразит, что пользователи – лентяи, поэтому документацию не читают, я с этим полностью согласен, но есть очень важный нюанс. Рано или поздно в общении с пользователями вы поймете, что чаще всего задаются одни и те же типовые вопросы, поэтому если вы их опишете в документации, то в будущем не будете тратить время, отвечая в -надцатый раз на вопрос о перекраске кнопок, а сможете дать ссылку на конкретный пункт в вашей документации.

 

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

 

 

13. Ведите лог разработки и обновлений

 

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

 

Речь пойдет о плагиате и способах обоснованно избежать обвинений в нем. Причем я пишу не о плагиате, например, с многострадальной Розетки, удивительное сходство с которой можно без проблем увидеть даже в самых новых шаблонах. Я имею в виду другой плагиат – когда элементы более нового шаблона напоминают элементы другого, более старого шаблона.

 

Пример из личного опыта – я уже третий год разрабатываю новый шаблон (назовем его A), в котором, среди прочих нововведений, используются градиентные кнопки, на карточке товара есть плавающий блок покупки, а на демо – фото айфонов. И вот неделю назад один разработчик выпускает свой новый шаблон B, в котором используются – угадали? – градиентные кнопки, на карточке товара есть плавающий блок покупки, а на демо фото айфонов в том числе :) Конечно, если через несколько месяцев будет релиз моего шаблона A, то некоторые персонажи могут усмотреть в этом плагиат с шаблона В другого разработчика. Но я веду историю разработки и в ней есть железные доказательства того, что, к примеру, градиенты на кнопках в моем новом шаблоне A были уже весной 2021-го года, когда шаблона В, естественно, еще не существовало и увидеть его будущий дизайн я физически никак не мог.

 

Так вот, чтобы всего этого избежать и быть готовым в случае чего доказать свою правоту и авторство – у вас должна быть история разработки, в которой не только будет видно эволюцию шаблона, дизайн-макеты и прочее, но в ней также должны быть четкие (и независимые от вас) временные отметки по всем важным этапам разработки. В самом примитивном виде – снимок вашего тестового сервера из WebArchive или даже какие-нибудь скриншоты, пересланные в Telegram – такие данные не подделаешь, потому что там видно оригинальные даты, поэтому чем больше у вас таких данных – тем сильнее ваша позиция.

 

 

  • +1 18
 Поделиться

49 комментариев


Рекомендованные комментарии



Как же я не согласен с 9 пунктом. Аргументирую,

 

У каждого инструмента есть свои возможности, достоинства и недостатки. Они РАЗВИВАЮТСЯ, в отличие от default-шаблона, и игнорировать их развитие - это большая проблема сообщества.

 

Выбирая изначально устаревшие библиотеки, а bootstrap 3 является ОЧЕНЬ УСТАРЕВШЕЙ библиотекой, Вы обрекаете на страдания ВСЕХ участников.

  • Разработчики, которые толковые, продолжают страдать и использовать заведомо худшие технологии, когда уже ничто не мешает переключиться на новые. Ну согласитесь, на флексах и сетка удобнее и блоки верстаются намного понятнее. Боюсь представить, что будет у большей части в при виде display: grid;
  • Владелец сайта, получает заведомо устаревший сайт, поддержка которого в перспективе будет стоить дороже/проблемнее, так как нужно будет поддерживать безусловно легаси-код. Т.е. он будет изначально нанимать не разработчика, а ремесленника, который изначально занимается не развитием проектов, а "кнопки красит" на 400 проектах, вы будете всего лишь 401.
  • Посетители сайта, так как загружают кучу ненужного барахла, только ради того, чтобы быть увереным что модуль от Васи и Пети не развалится, которое используется раз-два за всю загрузку страницы, если вообще используется. Почему это иконки сайта должны быть как у всех? У меня дизайнер нарисует их лучше, так зачем я буду загружать то, что мне не нужно изначально? Я готов предоставить крутые иконки всем покупателей шаблона, А если модулю от Васи и Пети испоьзуется иконка от FontAwesome, так может стоит проверить её подключение и вообще наличие? Может стоить продумать вариант, что если её не будет и вывести что-то другое? А почему это jquery должен быть загружен перед загрузкой контента первой необходимости? Может jquery подождет? А модуль от Васи и Пети проверит подключение этой самой jquery? Используешь стороннию библиотеку, ПРОВЕРЬ, что она уже подгружена.

Так вот не надо перекладывать с больной головы на здоровую, если модуль от Пети и Васи не может разные библиотеки, не может проверять, так это может проблема Васи и Пети? Ведь Васи и Пети научились как-то делать модули под разные версии PHP и не возбухают, может и научатся уже проверять наличие библиотек, которые они используют в модуле ПЕРЕД их использованием.

 

Вы мне можете тут начать заявлять, что cdn, кеширование, и вообще в нашем муравейнике так принято.

Ну ок, посмотрим на актуальные шаблоны и что мы там видим? Ой-ли... Bootstrap 4.5, SVG-спрайты, custom properties... продолжать?


Ну да, зато ленивые жопы модулеписателей, которые убеждены, что jquery всегда готов к их услугам в первую очередь без каких-либо проверок, что font-awesome всегда подключен и вообще.. почему бы нам не наделать еще дополнительных <div> с clearfix? Одним больше, другим меньше... А может уже пора делать обновить модули и для тех, кто вне танка? Ну можете не делать, вы сами загоняете собственное сообщество в угол. Если вы считаете, что для массы - на старье, для индивидуальной разработки - что хочешь, то всегда найдутся решения с более расторопными разработчиками. 


Я просто напомню, что на дворе заканчивается 2020 год, а вы пропагандируете то, что не было актуально еще в 2016

 

p.s. я понял про какой шаблон этот самый пункт 9.

Ссылка на комментарий
1 минуту назад, matroskin92 сказал:

Как же я не согласен с 9 пунктом.


Но вы можете основную сетку сделать mobile first grid with critical css inline но с поддержкой блоков bootstrap (включать к примеру опцией переключателя, как и иконки)  в основной сетке (и самое главное с id-шниками default) ;)
Вот о чем идет речь (правильно ли я вас понял @RGB ?). А не писать всё строго на bootstrap старой версии.

Ссылка на комментарий
2 часа назад, matroskin92 сказал:

Разработчики, которые толковые, продолжают страдать и использовать заведомо худшие технологии, когда уже ничто не мешает переключиться на новые. Ну согласитесь, на флексах и сетка удобнее и блоки верстаются намного понятнее. Боюсь представить, что будет у большей части в при виде display: grid;

На мой взгляд, если разработчик «страдает» от этого, то он ошибся с выбором движка и ему лучше перекатиться в сторону чего-то более современного просто в силу возраста и пути развития опенкарта, который далек от трендов и вряд ли когда-либо станет их догонять.

 

2 часа назад, matroskin92 сказал:

Владелец сайта, получает заведомо устаревший сайт, поддержка которого в перспективе будет стоить дороже/проблемнее, так как нужно будет поддерживать безусловно легаси-код. Т.е. он будет изначально нанимать не разработчика, а ремесленника, который изначально занимается не развитием проектов, а "кнопки красит" на 400 проектах, вы будете всего лишь 401.

Это вы очень сильно утрируете, словно я предлагаю использовать перфокарты в вычислениях или «верстать» во FrontPage. Поддержка сайта на том же bootstrap 3 и jQuery 2 ничем не дороже поддержки сайта на bootstrap 4 и ванильном JS (а порой и вовсе дешевле как раз в силу своей массовости), css/js/html везде практически одинаков и верстальщик не может не уметь работать с блочной версткой, разбираясь лишь во флексах, или знать JS и не суметь понять элементарный jQuery.

 

2 часа назад, matroskin92 сказал:

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

Посетителю сайта в 2020-м играет роль лишний мегабайт статики, которая после первой загрузки спокойно улетит в кеш браузера?

 

2 часа назад, matroskin92 сказал:

Так вот не надо перекладывать с больной головы на здоровую, если модуль от Пети и Васи не может разные библиотеки, не может проверять, так это может проблема Васи и Пети? Ведь Васи и Пети научились как-то делать модули под разные версии PHP и не возбухают, может и научатся уже проверять наличие библиотек, которые они используют в модуле ПЕРЕД их использованием.

Так получилось, что шаблонов намного меньше, чем модулей, поэтому если даже авторы шаблонов повально делают такие глупости, как перечисленные в п.8, стоит ли ожидать от авторов модулей, что они будут проверять, подключена та или иная библиотека? Или полагаться на авось и хороший code-style в среде модулеписателей, у которых порог вхождения еще ниже, чем среди шаблонописателей?

 

2 часа назад, matroskin92 сказал:

Вы мне можете тут начать заявлять, что cdn, кеширование, и вообще в нашем муравейнике так принято.

Ну ок, посмотрим на актуальные шаблоны и что мы там видим? Ой-ли... Bootstrap 4.5, SVG-спрайты, custom properties... продолжать?

А вы думаете плохие примеры для этой записи выбраны только из неактуальных шаблонов с bootstrap 3 и без svg-спрайтов? :) Так я вас, наверное, разочарую, но чем дальше в лес – тем больше новых дров на модных, современных технологиях.

 

2 часа назад, matroskin92 сказал:

Ну да, зато ленивые жопы модулеписателей, которые убеждены, что jquery всегда готов к их услугам в первую очередь без каких-либо проверок, что font-awesome всегда подключен и вообще.. почему бы нам не наделать еще дополнительных <div> с clearfix? Одним больше, другим меньше... А может уже пора делать обновить модули и для тех, кто вне танка? Ну можете не делать, вы сами загоняете собственное сообщество в угол. Если вы считаете, что для массы - на старье, для индивидуальной разработки - что хочешь, то всегда найдутся решения с более расторопными разработчиками. 

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

 

2 часа назад, matroskin92 сказал:

Я просто напомню, что на дворе заканчивается 2020 год, а вы пропагандируете то, что не было актуально еще в 2016

Не знал, что следование стандартам утратило свою актуальность в 2016 :)

 

2 часа назад, matroskin92 сказал:

p.s. я понял про какой шаблон этот самый пункт 9.

Да вроде это далеко не в одном шаблоне такое. Если вы на свой счет восприняли, то зря, никоим образом не хотел никого обидеть, в записи выжимка из моего опыта общения с десятками шаблонов самых разных авторов, тут нет какой-то одной конкретной цели для критики.

 

1 час назад, markimax сказал:


Но вы можете основную сетку сделать mobile first grid with critical css inline но с поддержкой блоков bootstrap (включать к примеру опцией переключателя, как и иконки)  в основной сетке (и самое главное с id-шниками default) ;)
Вот о чем идет речь (правильно ли я вас понял @RGB ?). А не писать всё строго на bootstrap старой версии.

Так никто не запрещает использовать новые технологии, вопрос в другом – зачем отказываться от поддержки старых, если это практически неминуемо вызовет проблемы в вышеописанных ситуациях? Делайте все флексами на здоровье, если с блоками не получается добиться желаемого. Но предусмотрите возможность корректного отображения сайта при использовании дополнений какого-нибудь ретрограда и учитывайте общий уровень разработчиков, которые с очень малой вероятностью будут заморачиваться вопросами поддержки чего-нибудь нестандартного, проверять подключения стандартных библиотек, иконочных шрифтов и т.д.

 

P.S. Запомнилась одна цитата из обсуждения работы с legacy-системами, которая, как мне кажется, будет весьма уместна, хоть и с оговорками:

Цитата

Страсть любого молодого разработчика — все выкинуть и написать заново. И когда вы ему говорите — нет, нельзя выбрасывать тонны старого кода — в нем и только в нем зашиты тысячи решений, о которых никто уже не помнит, когда вы ему напоминаете о синдроме второй системы — он уже твердо уверен, что вы просто ретроград (в лучшем случае) или не умеете программировать (он в тайне в этом очень быстро уверяется). Ведь у него есть золотой молоток, какой-нибудь аглуляр новой версии — и он-то как раз все и спасет. Методики? Протоколы? Документация? Не смешите его! У него ЕСТЬ НОВЫЙ ФРЕЙМВОРК! Он подобен Богу! И Он пришел здесь все разрушить
Ну ничего, рано или поздно и молодой разработчик поумнее и повзрослеет. И научится уважать старый код

 

Ссылка на комментарий

Говоришь про модули и сборка ? 

Moneymaker  Встроено как Вы же и описали 41 модуль - тут точно уже своя сборка выходит почти !!! 
 

  • +1 1
Ссылка на комментарий

Во-первых эта запись не о моем шаблоне и его никто не приводит в пример как образцовый, во-вторых - если вы внимательно посмотрите на шаблон, то увидите, что отдельных модулей в нем ровно 2, а все остальное - встроенная функциональность. Хотя что толку объяснять, если вы ни первый абзац записи не осилили:

Цитата

я адекватно воспринимаю критику и никогда не считал свои шаблоны эталонными с точки зрения разработчика

ни отдельное пояснение в процитированном вами же пункте про сборку:

Цитата

прекрасно понимаю шаблонописателей, которые пошли по этому пути, да и сам не без греха, хоть и старался не перегружать шаблон лишней функциональностью

Дальнейшие подобные комментарии будут удаляться, чтобы не захламлять обсуждение записи оффтопом и прочими глупостями

Ссылка на комментарий
2 часа назад, RGB сказал:

На мой взгляд, если разработчик «страдает» от этого, то он ошибся с выбором движка и ему лучше перекатиться в сторону чего-то более современного просто в силу возраста и пути развития опенкарта, который далек от трендов и вряд ли когда-либо станет их догонять.

Возраста? Пффф, что за бред? Может просто новым участникам пора немного разворошить немного зависшее сообщество?

 

2 часа назад, RGB сказал:

Это вы очень сильно утрируете, словно я предлагаю использовать перфокарты в вычислениях или «верстать» во FrontPage. Поддержка сайта на том же bootstrap 3 и jQuery 2 ничем не дороже поддержки сайта на bootstrap 4 и ванильном JS (а порой и вовсе дешевле как раз в силу своей массовости), css/js/html везде практически одинаков и верстальщик не может не уметь работать с блочной версткой, разбираясь лишь во флексах, или знать JS и не суметь понять элементарный jQuery.

Вот я и говорю как раз об уровне разработчика, если он справится только jquery и bootstrap, то ждать от него заказчику чего-то толкового не придется. А бизнес-задачи растут, ожидается что и платформа и разработчики будет расти, а не тормозить бизнес.

 

2 часа назад, RGB сказал:

Посетителю сайта в 2020-м играет роль лишний мегабайт статики, которая после первой загрузки спокойно улетит в кеш браузера?

Карантин и все дела, домашний интернет действительно хорош. Но хорошо ли он ловит в дороге, в метро или на пустыре у новостроек? А каждая секунда бизнесу при открытии сайта на вес золота. И не забывайте, что лишние 10-100кб JS !== 10-100кб картинки, совсем не равны. 

 

2 часа назад, RGB сказал:

Так получилось, что шаблонов намного меньше, чем модулей, поэтому если даже авторы шаблонов повально делают такие глупости, как перечисленные в п.8, стоит ли ожидать от авторов модулей, что они будут проверять, подключена та или иная библиотека? Или полагаться на авось и хороший code-style в среде модулеписателей, у которых порог вхождения еще ниже, чем среди шаблонописателей?

Так делают все разработчики в своих даже ОЧЕНЬ популярных модулях, поэтому если уходим немного в кастом и оптимизацию и все валится к чертям. Я молчу об элементарной семантике в самом популярном модуле, который приходится перетряхивать.

 

2 часа назад, RGB сказал:

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

Чем современнее технологии, тем проще делать крутые вещи, тем дешевле это бизнесу в разработке. Просто сравните шаблоны на Bootstrap 3 и Bootstrap 4 и их возможности.

 

2 часа назад, RGB сказал:

Не знал, что следование стандартам утратило свою актуальность в 2016

Bootstrap 3 версии потерял свою актуальность в 2016

 

 

Ссылка на комментарий
20 минут назад, matroskin92 сказал:

Возраста? Пффф, что за бред? Может просто новым участникам пора немного разворошить немного зависшее сообщество?

Вы же в курсе, что опенкарту уже больше 10 лет и многое в нем тянется именно с самого его начала развития и от этого не избавиться без значительного переделывания «всего и сразу»?

 

21 минуту назад, matroskin92 сказал:

Вот я и говорю как раз об уровне разработчика, если он справится только jquery и bootstrap, то ждать от него заказчику чего-то толкового не придется. А бизнес-задачи растут, ожидается что и платформа и разработчики будет расти, а не тормозить бизнес.

25 минут назад, matroskin92 сказал:

Чем современнее технологии, тем проще делать крутые вещи, тем дешевле это бизнесу в разработке. Просто сравните шаблоны на Bootstrap 3 и Bootstrap 4 и их возможности.

33 минуты назад, matroskin92 сказал:

Bootstrap 3 версии потерял свою актуальность в 2016

Вообще смысл записи, опять же, не в сравнении возможностей bs4 и bs3 и не в споре о том, кто из них круче, но можете привести пример такой бизнес-задачи, а заодно и возможности, которая реализуется только на bootstrap 4 и физически нереализуема на bootstrap 3 при знании css?

 

29 минут назад, matroskin92 сказал:

Карантин и все дела, домашний интернет действительно хорош. Но хорошо ли он ловит в дороге, в метро или на пустыре у новостроек? А каждая секунда бизнесу при открытии сайта на вес золота. И не забывайте, что лишние 10-100кб JS !== 10-100кб картинки, совсем не равны. 

А сколько золота стоит бизнесу сайт, развалившийся после установки дополнения, которое теперь нужно адаптировать, ведь автор шаблона – впереди планеты всей и не пользуется этим вашим bs3, jquery и прочим устаревшим барахлом, которое почему-то до сих поддерживают авторы модулей? :) 

 

23 минуты назад, matroskin92 сказал:

Так делают все разработчики в своих даже ОЧЕНЬ популярных модулях, поэтому если уходим немного в кастом и оптимизацию и все валится к чертям. Я молчу об элементарной семантике в самом популярном модуле, который приходится перетряхивать.

И что вы предлагаете - брать каждого разработчика за пуговку и учить писать хороший код на современных инструментах? На мой взгляд, это утопия

 

Ссылка на комментарий

у opencart есть база и codestyle

думаю это все что надо знать о bs4 флексах гридах и тп

никто как бы не против, как говорится любой каприз

Ссылка на комментарий
51 минуту назад, RGB сказал:

почему-то до сих поддерживают авторы модулей? :) 

потому что это базовая основа  фронта движка
 

 

52 минуты назад, RGB сказал:

А сколько золота стоит бизнесу

Вот!!!
 

Ссылка на комментарий

Ну элементарно же можно придерживаться стиля дефолтной темы, где-то классы сохранить.

Где-то id основных блоков сохранить. Некоторые темы даже не имеют элемента id="product" на странице товара.

Это разве противоречит использованию bs4?

 

А в twig неужели сложно писать в code style дефолтной темы?

Вместо {{ product.product_id }}

Чего только не встретишь:

{{product['product_id']}}

{{ product['product_id'] }}

{{product.product_id}}

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

Если в модификаторе таких мест 5, то для каждой вариации написания потом ещё и клонировать.

 

Есть в common.js устоявшиеся сущности: cart, wishlist и т.д.

Если тема не использует штатный common.js, то неужели сложно сущности назвать так же?

Чтобы была совместимость со штатными скриптами по написанию.

Ну вот что в этой строке мешает новым технологиям?

onclick="wishlist.add('{{ product.product_id }}');"

Но в большинстве тем:

megaThemeCatalogWishlistAdd(...)

И т.д. 

 

Что из сказанного противоречит использованию нового?

И это только совсем малая часть всех этих "нововведений".

 

  • +1 3
Ссылка на комментарий

 Я правильно понимаю?

Есть абстрактный магазин на каких-то там технологиях 2016 года.
Который торгует. Ну скажем на полмиллиарда рублей в год. Ну есть у меня такие подопечные.

И приходит какой-то @matroskin92, говорит. Чуваки. вы тут все черти тупорылые. И ничего не понимаете.

Важно не стабильность вашего бизнеса и стоимость разработки которую вы вложили в ресурс.
А чтобы ваш сайт отвечал станадартам свежим. И бутстрап 4.5. 

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

 

Реально среди моих друзей есть очень успешные проекты, в которые уже лет 5 в верстку никто не лазил. Всех все устраивает. А вот это вот все.. 
Я такой начитался про Bootstrap 4.5 и теперь - не подходите. Да дружище, иди броди со своими решениями. Они никому не нужны. Решения нужны в рамках существующего стека. И без головной боли для владельца магазина. А какой это там бутстрап - ваще никого не волнует!

  • +1 3
Ссылка на комментарий
12 часов назад, RGB сказал:

А сколько золота стоит бизнесу сайт, развалившийся после установки дополнения, которое теперь нужно адаптировать, ведь автор шаблона – впереди планеты всей и не пользуется этим вашим bs3, jquery и прочим устаревшим барахлом, которое почему-то до сих поддерживают авторы модулей? :) 

Если владелец сайта устанавливает на рабочий сайт модуль не глядя... ну а что еще ожидать?

 

8 часов назад, Yoda сказал:

Есть абстрактный магазин на каких-то там технологиях 2016 года.
Который торгует. Ну скажем на полмиллиарда рублей в год. Ну есть у меня такие подопечные.

А теперь читаем внимательно статью и мои комментарий и вуаля, речь то идет не о том что срочно всем магазинам обновить библиотеки, а том что в НОВЫХ проектах нужно использовать СВЕЖИЕ версии тех же самых библотек, а модулеписателем перед тем, как использовать ту или иную библиотеку УДОСТОВЕРИТЬСЯ, что она подключена и готова к использованию. Это так сложно? 

 

Повторюсь, никого не смещают разные версии модулей для разных версий PHP, но разные версии бутстрапа всех пугают до белой горячки, вы адекватны?

Ссылка на комментарий
1 час назад, matroskin92 сказал:
14 часов назад, RGB сказал:

А сколько золота стоит бизнесу сайт, развалившийся после установки дополнения, которое теперь нужно адаптировать, ведь автор шаблона – впереди планеты всей и не пользуется этим вашим bs3, jquery и прочим устаревшим барахлом, которое почему-то до сих поддерживают авторы модулей? :) 

Если владелец сайта устанавливает на рабочий сайт модуль не глядя... ну а что еще ожидать?

 

перечитайте внимательно комментарии выше

речь о том, чтобы придерживаться стандартов движка

как раз для исключения проблем совместимости

 

владелец сайта вообще не обязан разбираться в хитросплетениях версий различных библиотек

он ожидает что модуль с заявленной поддержкой версии его движка и PHP будет работать на его сайте

из коробки или с небольшими адаптациями

 

чего он никак не ожидает - это выяснения факта,

что автор его такого передового и замечательного шаблона, использующего последние ноу-хау

наср@л на совместимость и в итоге бОльшая часть всевозможных дополнений на нем не работают

а их доработку для этого шаблона авторы оценивают по тройному тарифу (см. ноу-хау)

  • +1 3
Ссылка на комментарий
15 часов назад, matroskin92 сказал:

Если владелец сайта устанавливает на рабочий сайт модуль не глядя... ну а что еще ожидать?

 

А теперь читаем внимательно статью и мои комментарий и вуаля, речь то идет не о том что срочно всем магазинам обновить библиотеки, а том что в НОВЫХ проектах нужно использовать СВЕЖИЕ версии тех же самых библотек, а модулеписателем перед тем, как использовать ту или иную библиотеку УДОСТОВЕРИТЬСЯ, что она подключена и готова к использованию. Это так сложно? 

 

Повторюсь, никого не смещают разные версии модулей для разных версий PHP, но разные версии бутстрапа всех пугают до белой горячки, вы адекватны?



Это очень сложно, потому что Legacy!!! Везде Legacy...

Дай вам бог поработать на паре серьезных проектов, может тогда будет нам о чем говорить. 

Ссылка на комментарий
13 часов назад, AlexDW сказал:

 

перечитайте внимательно комментарии выше

речь о том, чтобы придерживаться стандартов движка

как раз для исключения проблем совместимости

 

владелец сайта вообще не обязан разбираться в хитросплетениях версий различных библиотек

он ожидает что модуль с заявленной поддержкой версии его движка и PHP будет работать на его сайте

из коробки или с небольшими адаптациями

 

чего он никак не ожидает - это выяснения факта,

что автор его такого передового и замечательного шаблона, использующего последние ноу-хау

наср@л на совместимость и в итоге бОльшая часть всевозможных дополнений на нем не работают

а их доработку для этого шаблона авторы оценивают по тройному тарифу (см. ноу-хау)

 

ПОДПИШУСЬ ПОД КАЖДЫМ СЛОВОМ!!!
Вот почему у некоторых не хватает извилин, для понимания таких простых вещей ?

Ссылка на комментарий

подобная проблема будет всегда, и от этого никуда не денемся. Я думаю никто не против использовать более новые технологии и инструменты,и для нас, как для разработчиков это удобнее и полезнее. Но в целом для проекта, в контексте опенкарта, мы должны выбырать решения, которые владельцу принесут деньги, а не проблемы. И я согласен с тем, что вред о того, что на проект могут поставить любой +- адекватный модуль, который требует очень нелюбымый сейчас многими  jquery будет в разы больше, чем от использования устаревших библилитек. И потом переписывать придется чуть ли не каждый модуль, который где-то как-то приглянетя владельцу. 

 Просто это факт, который не можно отрицать.

А если у тебя где-то совсем другой проект и другая база, да без проблем, почему бы не использовать гриды, ванильный js, последний бутстрап и все что хочешь.

Ссылка на комментарий
2 минуты назад, Seriusis сказал:

многими  jquery будет в разы больше, чем от использования устаревших библилитек.

К сожалению персонажи выше читают только свои сообщения, я постараюсь ещё кратко объяснить в чем проблема.

 

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

 

Получается, что модулеписатели опираются на неписанные стандарты и снимают с себя ответственность, а потом бузят, что все вокруг не правы. 

  • +1 1
Ссылка на комментарий
15 минут назад, matroskin92 сказал:

Перед использованием любой библиотеки, которая входит или не входит, может быть другая версия по разным причинам, проверь, есть ли она?

тут нужно понимать, что jquery должен быть подключен в любом случае. А если проверять и его нет, иначе что, писать дублирующийся код на js или как? а таком случае насколько будет оправдано это дублирование ? Нужно исходить из того, что он есть и авторам шаблонов и модулей.

Если это какая-то специфическая библиотека, то, как правило, ее включают в архив с модулем, чтобы проблем не было. Кроме того все стандартные библиотеки есть в папке javascript, их просто подключаем, т.е проверять нет смысла

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

Ссылка на комментарий

Если авторы шаблонов не прислушаются к статье - то авторы модулей придут писать шаблоны, надеюсь там среди вас места много, и поверьте все ваши версталы к нам побегут ибо кодеры ваши просто ноль как я

  • +1 2
Ссылка на комментарий

Судя по отсутствию какой-либо реакции со стороны авторов шаблонов (кроме борцов с такими опасными явлениями, как jQuery и Bootstrap 3), всем все понятно, но каждый делает как ему в голову взбредет :) 

Ссылка на комментарий
В 03.10.2020 в 01:31, Yoda сказал:

 Я правильно понимаю?

Есть абстрактный магазин на каких-то там технологиях 2016 года.
Который торгует. Ну скажем на полмиллиарда рублей в год. Ну есть у меня такие подопечные.

И приходит какой-то @matroskin92, говорит. Чуваки. вы тут все черти тупорылые. И ничего не понимаете.

Важно не стабильность вашего бизнеса и стоимость разработки которую вы вложили в ресурс.
А чтобы ваш сайт отвечал станадартам свежим. И бутстрап 4.5. 

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

 

Реально среди моих друзей есть очень успешные проекты, в которые уже лет 5 в верстку никто не лазил. Всех все устраивает. А вот это вот все.. 
Я такой начитался про Bootstrap 4.5 и теперь - не подходите. Да дружище, иди броди со своими решениями. Они никому не нужны. Решения нужны в рамках существующего стека. И без головной боли для владельца магазина. А какой это там бутстрап - ваще никого не волнует!

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

Этот "комбайн" рабочий нельзя останавливать в кризисное время.

Ссылка на комментарий

А кто-нибудь пробовал опенкарт 2.3 натянуть на бустрап 5 ?

Вот задумал такое.. Опенкарт 3 не вижу смысла, опять все модули покупать и костыли свои вспоминать, не проще ли самому default тему перевести на бустрап 5.. 

Ссылка на комментарий

А зачем? Если предполагается возможность дальнейшей установки на такую систему сторонних дополнений, то вам придется конструировать некоторые костыли для того, чтобы модули, расчитанные на бутстрап 3, нормально отображались на пятом

Ссылка на комментарий

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.