добавлять изображения для карточек товаров через конструктор

Всем привет и здравствуйте!
Это мой первый пост на этом ресурсе )
Была задача сделать максимально похожий по содержимому и функционалу сайт. Решил сделать как обычно - на Yootheme PRO. Но вот незадача - оказалось что в конструкторе не могу сделать обычную, всем привычную галерею с прокруткой превьюшек и лайтбоксом.
Подскажите, пожалуйста, как все же сделать эту галерею как здесь _ozon.lutsk.ua/products/promenada.
В конечном результате этим должен пользоваться человек не имеющий знаний в верстке, потому очень важно чтобы это работало в режиме конструктора - кликами мышки.
Пока сижу расстроенный от того, что один из лучших пейджбилдеров не позволяет это реализовать.

Заранее большое спасибо!

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

У меня так:
Но у меня без прокрутки превьюшек.

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

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

Wedal пишет: Дмитрий, ваши скриншоты отдаются болью в моем сердце. Это ж кошмар какой-то. Как вы можете добавлять изображения для карточек товаров через конструктор?

Привет Виталий!
Я не разделяю Ваш скепсис по этому поводу. С JoomShopping я не знаком, а вот с компонентом VM имел дело, иногда и сейчас приходится иметь. Очень хорошо помню геморрой VM с удалением изображений (когда из базы удалялись, а файлы оставались), а вот преимуществ не наблюдаю (если не ставить плагин пакетной загрузки).
Не поделитесь своими соображениями, чем добавление через компонент (с занесением в базу) лучше добавления через билдер (HTML).

Wedal пишет: Так или иначе, создание каталога товаров через билдер я вижу как большое, нет, огромное извращение.

Я бы не был столь категоричен, думаю исходить стоит из задачи. Но хочу отметить, что билдер Yootheme PRO можно приспособить и для создания вполне стандартизированных карточек товара, хотя в полную силу он раскрывается когда нужна глубокая кастомизация некоторых карточек.

З. Ы.
Если считаете это сообщение офтопом, выделите обсуждение в отдельную тему, с удовольствием продолжу обсуждение.

Дмитрий, простейший вопрос: КАК
1) Как вы будете выводить модули последних просмотренных, рекомендуемых, популярных товаров? Тоже загружать через билдер в виде HTML?
2) Как вы будете массово экспортировать/импортировать товары (и изображения в частности)?
3) Как вы будете показывать изображения товаров в корзине, в письме с заказом?

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

Wedal пишет: Может быть билдер имеет надстройку, которая позволяет добавляемые через него изображения карточек товаров загружать в VM, именно в медиа-менеджер, как будто это сделано через стандартный интерфейс VM.

Виталий, извините я забыл написать, что используется компонент магазина оперирующий стандартными материалами JOOMLA. Вернее не забыл, написал, но этот пост не опубликовался. А когда писал второй раз, уже сократил все (настроения не было писать длинно).
Соответственно, к каждому материалу прикреплены два штатных изображения (миниатюра и полноразмерное), остальные загружаю через билдер в виде HTML. Можно конечно добавить их в базу (через настраиваемые поля), но я смысла не вижу. Может я не прав?

Wedal пишет: Дмитрий, простейший вопрос: КАК

К сожалению сайт не мой, а владелец не уполномочивал меня светить (в открытом доступе) на каком программном продукте сделан сайт. Но если интересно, я могу сбросить в личку ссылку на видео. Если отвечать коротко, то через динамический контент Yootheme PRO.

Дмитрий,

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

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

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

Wedal пишет: не очень здорово, как и использовать магазин на стандартных материалах Joomla (разве что только он имеет очень маленький каталог товаров).

Я знаком с этой точкой зрения, только не очень понимаю на чем она основана. Насколько я знаю, существуют вполне эффективные статейники (на Joomla), с десятками тысяч статей. Почему тогда е-маг (с несколькими тысячами товаров) не сделать по этой же технологии? Если не секрет, поделитесь своими мыслями, о минусах решения на базе стандартных материалов Joomla...
А я, постараюсь, написать о плюсах (к концу выходных). Ну и о том, как сделать очень маленький каталог товаров (до 10 категорий, до 10 производители) на билдере Yootheme PRO (буквально за несколько часов, без знания HTML, пользуясь лишь визуальным конструктором) в середине июля выйдет видео.

Дмитрий, минус решения создания каталога на стандартных материалах Joomla в том, что они для этого не предназначены. Да, вы можете создать каталог, создать доп.поля., прикрутить расширение корзины, фильтр. Но где в этом случае будут храниться заказы, статусы заказов, купоны, налоги и скидки и т.п? Т.е. я не говорю, что это нельзя сделать в принципе, но это похоже на изобретение своего велосипеда. А ради чего это всё? Только чтобы использовать билдер? Зачем? Чтобы не учить HTML и CSS.
Вы ищите простой путь. Нельзя сказать однозначно, что это плохо. Это быстро. Но это имеет мало общего с нормальной веб-разработкой.

Wedal пишет: Дмитрий, минус решения создания каталога на стандартных материалах Joomla в том, что они для этого не предназначены.

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

Wedal пишет: Да, вы можете создать каталог, создать доп.поля., прикрутить расширение корзины, фильтр. Но где в этом случае будут храниться заказы, статусы заказов, купоны, налоги и скидки и т.п?

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

Joomla имеет компоненты перенаправления и тегов (метки), с которыми не умеет работать VM. И это очень, не очень! Стандартная (для интернет магазина) процедура: после удаления товара поставить редирект на похожий товар, превращается в эротическое приключение с VM. Удивительно, что за много лет существования компонента метки в Joomla, создатели VM не удосужились обеспечить совместимость (своего детища) с ним.

Joomla умеет создавать материалы огромного объема, а VM еще недавно сильно ограничивал объем полного описания товара. Если честно, я не помню есть ли сейчас ограничения на количество символов в кратком описании VM, и если есть то какие, но раньше они были очень жесткими.

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

VM умеет размещать один товар в нескольких категориях (что не редко требуется для интернет магазинов). При этом, VM (хотя и относительно недавно) научился корректно проставлять тег rel="canonical", что позволяет избегать дублей страниц. У Joomla, я до сих пор, наблюдаю проблемы с каноническими ссылками.

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

VM умеет работать с доп.полями, но реализация этой работы гораздо слабее чем в Joomla (это исключительно мое ИМХО).
Если припомню еще чего, потом добавлю.

Wedal пишет: Т.е. я не говорю, что это нельзя сделать в принципе, но это похоже на изобретение своего велосипеда.

У меня складывается впечатление, что свой велосипед изобретают именно создатели VM. Причем велосипед с квадратными колесами они прикрутили к нормальному, и пытаются убедить всех, что это отличное решение. Возникает закономерный вопрос: Что от Joomla использует VM, если большинство компонентов Joomla не работает с ним? И не проще ли выделить VM в самостоятельную CMS, если от Джумлы ему нужно так мало?

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

Wedal пишет: Вы ищите простой путь. Нельзя сказать однозначно, что это плохо. Это быстро. Но это имеет мало общего с нормальной веб-разработкой.

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

Wedal пишет: А ради чего это всё? Только чтобы использовать билдер? Зачем? Чтобы не учить HTML и CSS.

Уффф, извините притомился я много писать. С Вашего позволения, оставлю тему билдера на следующий раз.

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

Насчет настраиваемых полей:
Проблемы с полями Joomla начнутся не сразу. Дьявол, как всегда, в деталях. Что, если вам потребуются поля, которые должны влиять на конечную стоимость товара и передаваться в корзину (например цвет)? Что, если вам потребуются поля, которые будут реализовывать функционал так называемых дочерних товаров (к примеру, вы продаете телефон и нужно дать возможность пользователю выбрать объем памяти, который будет влиять на цену и на остатки)? А если потребуются взаимозависимые поля, которые влияют на остатки (цена + объем памяти)? Да, вы можете создать каждый такой товар отдельно на сайте, но это будут практически дубли. К тому же совокупность 3 объемов памяти и 3 цветов даст уже 9 товаров на сайте. А если появится еще и третий параметр...

VM далеко не такой простой, как может показаться на первый взгляд. В нем уже давно отработан функционал по огромному количеству тонкостей, о которых при создании интернет-магазина вообще и не думаешь. Да, он берет от Joomla не так много по умолчанию. Но берет. Главное, что он интергирован в Joomla. Мы можем выводить товары VM в статьях J, можем выводить статьи и модули J в товарах VM. Можем показывать в модулях последние товары. Можем очень много. Поймите меня правильно, я бы и сам с удовольствием отказался от VM в пользу стандартных материалов J, но на данном этапе он умеет гораздо, гораздо больше.

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

Wedal пишет: Дмитрий, я не хочу сказать, что ваш подход в корне неверный. Нет. Это ваш выбор и вы этот выбор достаточно аргументированно защищаете.

Спасибо! Похоже сейчас мы вышли на общею волну разговора, а не как раньше...

Wedal пишет: Что, если вам потребуются поля, которые будут реализовывать функционал так называемых дочерних товаров (к примеру, вы продаете телефон и нужно дать возможность пользователю выбрать объем памяти, который будет влиять на цену и на остатки)? А если потребуются взаимозависимые поля, которые влияют на остатки (цена + объем памяти)? Да, вы можете создать каждый такой товар отдельно на сайте, но это будут практически дубли. К тому же совокупность 3 объемов памяти и 3 цветов даст уже 9 товаров на сайте. А если появится еще и третий параметр...

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

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

Вы бы рекомендовали завести эти товары как один (с цветовыми вариациями), как дочерние или как самостоятельные товары? Если возможно, обоснуйте макс. подробно, я думаю это интересно не только мне.

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

Wedal пишет: Поймите меня правильно, я бы и сам с удовольствием отказался от VM в пользу стандартных материалов J, но на данном этапе он умеет гораздо, гораздо больше.

Я и не призываю Вас отказываться от VM. Более того, я считаю, что для выполнения любой задачи есть свой оптимальный инструмент. Есть задачи, для которых оптимален даже не VM, а Битрикс (если интересно, расскажу подробнее)!

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

И с этим спорить не стану. У моего работодателя один из партнеров сделал сайт на Тильде, а сейчас ищет более подходящее решение (возможно это Битрикс).
Но, я бы не советовал строить сайт с учетом перспектив более чем на 5 лет. Это как выбирать смартфон по функциям, которые понадобятся лет через пять. Через несколько лет окажется, что функции нужны совершенно другие (которых на момент покупки еще не существовало), а через 4 года ты сменишь смартфон (если он раньше не сломается), потому что друзья смеются над твоим архаичным гаджетом...

Дмитрий,

У меня было несколько статей по настраиваемым полям и дочерним товарам. Использовать их приходится. Не всегда, но часто. Не отказываются от них сегодня, нет. Посмотрите те же Спортмастер или Алиэкспресс. Если у вас на каждый товар по 8 размеров, то вряд ли будет хорошим решением создавать 8 копий одного и того же товара, отличающихся только размером. Это банально будет плохо для SEO, т.к. страницы таких товаров будут практически идентичными и будут плохо индексироваться. Плюс будет полным бредом, если у вас в категории товаров будет выводиться 8 одинаковых футболок подряд, только разного размера. И там много таких тонкостей.

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

Поехали дальше. Что вы будете делать с материалами, если вам нужно, чтобы товары с нулевым остатком автоматически снимались с публикации? Допустим, остатки вы запишите в доп. поле материалов Joomla. А проверка количества и ее влияние на отображение товара? Будете писать плагин? Придется писать.

Идем дальше. Обработка склада. Бывает ситуация, при которой товар остается в единичном экземпляре. Кто-то добавляет его в корзину, но заказ еще не оформлен. И тут же кто-то другое добавляет этот же товар в корзину. Как вы научите материалы J не допускать такого поведения? Здесь уже должно сработать доп. расширение корзины. Но ведь ему ничего неизвестно про то, какое поле вы используете для хранения остатков?
Далее. Пользователь сделал заказ, но не оплатил. Чтобы остатки не списались, у вас должно быть еще одно поле "Резерв", в которое остаток переходит, когда товар заказан, но еще не оплачен. Отображение товаров на сайте должно основываться на расчете остаток минус резерв. Корзина должна также работать с обоими полями. Но мы помним, что ей про эти поля неизвестно вообще ничего.

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

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

Wedal пишет: У меня было несколько статей по настраиваемым полям и дочерним товарам. Использовать их приходится. Не всегда, но часто. Не отказываются от них сегодня, нет. Посмотрите те же Спортмастер или Алиэкспресс. Если у вас на каждый товар по 8 размеров, то вряд ли будет хорошим решением создавать 8 копий одного и того же товара, отличающихся только размером. Это банально будет плохо для SEO, т.к. страницы таких товаров будут практически идентичными и будут плохо индексироваться. Плюс будет полным бредом, если у вас в категории товаров будет выводиться 8 одинаковых футболок подряд, только разного размера. И там много таких тонкостей.

Посмотрел статью по дочерним товарам, возможно именно после не я решил отказаться от их использования. Точно не помню. Но специфика такова, что контроль остатков никогда не осуществлялся.

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

Поехали дальше. Что вы будете делать с материалами, если вам нужно, чтобы товары с нулевым остатком автоматически снимались с публикации? Допустим, остатки вы запишите в доп. поле материалов Joomla. А проверка количества и ее влияние на отображение товара? Будете писать плагин? Придется писать.

Идем дальше. Обработка склада. Бывает ситуация, при которой товар остается в единичном экземпляре. Кто-то добавляет его в корзину, но заказ еще не оформлен. И тут же кто-то другое добавляет этот же товар в корзину. Как вы научите материалы J не допускать такого поведения? Здесь уже должно сработать доп. расширение корзины. Но ведь ему ничего неизвестно про то, какое поле вы используете для хранения остатков?
Далее. Пользователь сделал заказ, но не оплатил. Чтобы остатки не списались, у вас должно быть еще одно поле "Резерв", в которое остаток переходит, когда товар заказан, но еще не оплачен. Отображение товаров на сайте должно основываться на расчете остаток минус резерв. Корзина должна также работать с обоими полями. Но мы помним, что ей про эти поля неизвестно вообще ничего.

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

Виталий, может быть Вы пропустили это:

Дмитрий пишет: используется компонент магазина оперирующий стандартными материалами JOOMLA.

Wedal пишет: Насчет аналогии интернет-магазина со смартфоном - не соглашусь. Всё-таки не очень корректно сравнивать ПО и железо. И то и другое устаревает, но ПО достаточно легко обновляется. В нашем случае, если не делать хаков, то с тем же VM можно жить очень долго, своевременно обновляя его до последних версий.

Жить можно, а вот эффективно продавать крайне сложено. Я не говорю, что необходимо менять движок, но посмотрите сколько изменилось (в VM) с версии 2.6 до версии 3.6. Проабгрейдится можно, но не очень просто! А шаблон менять все равно придется, ну и специфика (в которой я работал) подразумевает смену моделей. Но я не исключаю, что есть случаи когда не так то и просто сменить движок магазина.

Но вернемся к оставленной теме билдера Yootheme PRO и его места в создании интернет-магазина.
Как я уже писал, VM умеет размещать один товар в нескольких категориях а у стандартных материалов Joomla с этим проблемы. Возможно стоит отметить, что ситуация в которой один товар должен выводиться в нескольких категориях, встречается не редко. Например один фонарь может быть и кемпинговым и туристическим, а другой налобным, туристическим и карманным, третий же фонарь может оказаться налобным и тактическим. Логично, что первый мы поместим в категорию кемпинговых, а два других в налобные. Но как вывести первые два в категории туристических, а последний в категории тактических? Вот тут нам и приходит на помощь конструкт динамического контента билдера Yootheme PRO!
Он позволяет, в любом элементе Multiple Items выбрать источником заполнения поля материалов. Если Вы используете страницу содержащею несколько элементов (например страницу категории или тегов) можно вывести поля элементов заполняющих эту страницу. Но кроме возможности вывода элементов страницы, билдер Yootheme PRO умет выбирать элементы и сам (для этого следует выбрать источники с префиксом "Custom")!

На словах это выглядит сложным, но если посмотреть видео: многое станет понятно.

Важно понимать, что если нам нужно вывести элементы данной страницы, следует источником выбирать Article или Articles. А если мы хотим выбрать элементы из другой категории, следует источником выбрать Custom Article или Custom Articles. В примере с фонариками, я бы добавил в сетку с динамическим контентом второе и третье поля, сделав источником категорию кемпинговых и налобных фонарей. А в сортировках задал бы тег (метку), настраиваемое поле или просто слово.

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

Ну ладно. Допустим вы взяли билдер, сделали все вот эти страницы. А фильтр по параметрам как будете делать? С ним билдер тоже будет работать? А если вам понадобится добавить чуть более сложную логику на эту страницу? Например, вы захотите для элементов, у которых есть скидка, добавлять соответствующий лейбл? Рано или поздно, вам неизбежно потребуется влезть в код макета. И тут выясняется, что кода-то и нет. Ведь шаблоны страниц, построенные в билдере, хранятся в базе данных. Здесь я могу, конечно, ошибаться, т.к. не так хорошо знаю возможности Yootheme PRO. Может быть там что-то уже придумали.

Но всё-таки. Я привожу вам примеры чуть более сложных задач: дочерние товары, контроль остатков, отображение по условиям. Вы говорите - нам это не нужно. Уходите от решения таких задач. Да, в текущем проекте, возможно, оно вам не нужно. Но в следующем вполне может понадобиться. Да и в текущем: захочет заказчик вдруг внезапно что-то доработать. Попросит вас, добавить контроль остатков, например. И что будете делать?

Не обижайтесь, пожалуйста, если вдруг я местами резок. Просто это повальное увлечение билдерами - какой-то кошмар. Все хотят делать сайты, но никто не хочет учиться писать код. Меня это расстраивает.
Не так давно ко мне обратился заказчик, которому сделали сайт с Yootheme PRO и кастомным компонентом. Сайт интересный, со своей уникальной идеей. Делал сайт один наш известный Joomla-программист. Он отлично знает Joomla. Прекрасно пишет компоненты. Но его стихия - бэкенд. Для фронтенда использовался Yootheme PRO. Видимо на этапе создания сайта всё было хорошо. Но позже, когда сайт уже заработал, всё начало выходить из под контроля. Да так, что и не исправишь... Просто представьте: тысячи материалов на билдере, сотни пунктов меню - ужасный, просто ужасный фронтенд - все элементы размазаны по странице, ничего не понять, не прокрутив ее вверх-вниз несколько раз.
В итоге, я отказался от работы с этим заказчиком. Заказчик был хороший, адекватный. Горел своей идеей. Но здесь не было вариантов, кроме как переделать большую часть сайта. Это сложно объяснить заказчику, который уже заплатил большие деньги. Потому я и пишу всем и всегда - не используйте билдеры для сложных сайтов. Каталоги товаров уже будут относиться к таковым. Yootheme PRO годится для визитки или лендинга. Всё остальное - удел специализированных компонентов и кастомных шаблонов.

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

Я в курсе.

Wedal пишет: Ну ладно. Допустим вы взяли билдер, сделали все вот эти страницы. А фильтр по параметрам как будете делать? С ним билдер тоже будет работать?

Пока да, в текущем проекте этого достаточно.

Wedal пишет: А если вам понадобится добавить чуть более сложную логику на эту страницу? Например, вы захотите для элементов, у которых есть скидка, добавлять соответствующий лейбл? Рано или поздно, вам неизбежно потребуется влезть в код макета. И тут выясняется, что кода-то и нет. Ведь шаблоны страниц, построенные в билдере, хранятся в базе данных. Здесь я могу, конечно, ошибаться, т.к. не так хорошо знаю возможности Yootheme PRO. Может быть там что-то уже придумали.

А компонент интернет магазина думаете не справится?

Wedal пишет: Но всё-таки. Я привожу вам примеры чуть более сложных задач: дочерние товары, контроль остатков, отображение по условиям. Вы говорите - нам это не нужно. Уходите от решения таких задач. Да, в текущем проекте, возможно, оно вам не нужно. Но в следующем вполне может понадобиться. Да и в текущем: захочет заказчик вдруг внезапно что-то доработать. Попросит вас, добавить контроль остатков, например. И что будете делать?

Я же начал наш диалог с того, что для каждой задачи существует оптимальный инструмент. Будет задача, с которой не справляются текущие средства, найду другие оптимальные средства. Ведь существует, в конце концов, и решение интегрирующее Yootheme PRO в VM...

Wedal пишет: Не обижайтесь, пожалуйста, если вдруг я местами резок. Просто это повальное увлечение билдерами - какой-то кошмар. Все хотят делать сайты, но никто не хочет учиться писать код. Меня это расстраивает...
...Потому я и пишу всем и всегда - не используйте билдеры для сложных сайтов. Каталоги товаров уже будут относиться к таковым. Yootheme PRO годится для визитки или лендинга. Всё остальное - удел специализированных компонентов и кастомных шаблонов.

Как по мне, так для визитки или лендинга лучше чистый html.
C Yootheme PRO я познакомился менее года назад, а его возможности продолжаю открывать и по сей день. С Вашего позволения я продолжу рассказывать о них здесь.