1000 товаров и по 10 свойств в каждом уже 10 тыщ записей.
Мне кажется что все-таки лучше хранить в JSON в той же таблице товаров (ну или связанной, если работать по нормализации) и выбирать поиском при необходимости можно так же из JSON строки, вроде с 5.7 Mysql это умеет с новыми функциями
1 - так вы не ставьте класс burger_active для меню по умолчанию, пусть будет скрыто (медиа запросами или иначе), по клику на бутер делаем toggleClass('burger_active') и аналогично по клику на пункт скрытого меню убираем этот класс
maiskiykot, Движок не мертвый отнюдь, развивается постоянно.
А вот Jcomment умер года 3-4 назад полностью и апдейтов не будет.
Если сайт рабочий, но нужны изменения - посмотрел бы в сторону других компонентов и мигрировал туда данные из JC, но тоже процесс не на 5 минут
maiskiykot, Так я про это и говорю - весь компонент выводится плагином группы content по событию onAfterDisplayContent (оно прописано в шаблоне материала).
Можно попробовать переписать плагин на модуль и разместить его в нужном месте, но подобного делать не приходилось
Комменты вставляются плагином на событие onAfterDisplayContent, то есть в шаблоне материала после текста материала, а то что там внизу за пределами контента какие-то модули ему без разницы
Просто вывести комменты можно в любом месте несложным кодом, но вот подцепить туда функционал формы\пагинации и прочие плюшки - увы, без танцев никак
Как написали, можно на SVG но зачем - тупо фоновыми картинками (если нужно для верстки) и редактировать позиционирование для разных экранов через медиа запросы.
С СВГ тоже запаритесь подгонять
dom1n1k, Или мы с вами не понимаем друг друга или вы ошибаетесь.
Есть CMS, которая дает функционал, есть шаблон, который работает на базе API CMS и выводит результат. Шаблоны можно переделывать как угодно, внешний вид ничего общего с системой не имеет. При обновлении CMS наш шаблон фронта останется неизменным.
Конечно, речь не о клубных шаблонах, в которые пользователь изменения не вносят и они тоже будут обновляться (на системах Joomla, WP и подобных), но я не видел готового шаблона, оставшийся без изменений для реального сайта
Порядок и количество полей должно быть обязательно одинаково, если пропущен один элемент (без пустой строки между разделителем) - то и вывод на фронт будет иной
Ну базовую разметку блоков я никогда не оставляю на стандартные классы фреймворков.
Бывает что на главной и внутренних отступы разные, потому и варьируется подход.
Где-то page с margin-top а где наоборот, у header margin-bottom
Иногда и паддингами отбивается, и отрицательным позиционированием или абсолютным. По ситуации, уникального подхода не бывает
Тут причина в другом, популярные интернет магазины это большие старые проекты, в котором затронь строчку кода - и придет пушной зверек, потому главное правило - работает - не трожь
Новые все проекты верстаю на флексе и гридах, старые - крайне редко перевожу на новую парадигму
Arman, Да, упустил, что 4-й на флексе. Но тогда тем более непонятен первый вопрос, враппер у нас 100% ставим дочерним 24% и они в 4 колонки красиво расставляются ...
Хотя я против бутстрапа, он сушит мозг
UPDATE `table` SET `field_name`= REPLACE(`field_name`, 'что меняем', 'на что меняем');
Добавить туда только нужные регулярки, например style="([^"]*)"
вырежет все style="bla bla"
Потом почистить от открывающих и закрывающих спанов.
Где то встречал более масштабную регулярку в одну строку, но не помню увы
Так что точечно с бекапами и простыми регулярками только...
Я не спорю и сразу говорил, что можно обойтись стандартным API движка.
Только один прежний момент - если в входящем массиве $this->category (ну или любом другом на уровне) нет этих данных - то все обращения к лейаутам будут делать отдельные излишние запросы к БД
он есть, но достается запросами к БД в АПИ движка, которые могут тянуть и другие вещи, вам ненужные.
Проще сделать просто запрос на одно поле из БД в шаблоне и это будет быстрее, нежели использовать апи движка
rowd, Можно, прокатит, но вы же будете заменять и закрывающие теги на а это может привести к поломке верстки материалов от слова вообще.
Я бы сделал через костыль (на одном проекте помогло) - вывод в шаблоне материала сделал через strip_tags запретив все кроме абзацев ссылок, списков UL LI и стронга
Если в приходящем массиве нет информации о категории - все штатные средства API движка все равно будут делать запросы к БД (при этом не самые оптимальные)
Так что лучше руками дернуть одну строку, нежели подключать сюда АПИ
Мне кажется что все-таки лучше хранить в JSON в той же таблице товаров (ну или связанной, если работать по нормализации) и выбирать поиском при необходимости можно так же из JSON строки, вроде с 5.7 Mysql это умеет с новыми функциями