Я делаю уже третий плагин, который перехватывает функционал корзины, и хотел бы внести одно предложение, которое открыло бы безграничные возможности для создания новых плагинов.
Что мы имеем сейчас:
CREATE TABLE `shop_cart_items` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`code` VARCHAR(32) NULL DEFAULT NULL,
`contact_id` INT(11) NULL DEFAULT NULL,
`product_id` INT(11) NOT NULL,
`sku_id` INT(11) NOT NULL,
`create_datetime` DATETIME NOT NULL,
`quantity` INT(11) NOT NULL DEFAULT '1',
`type` ENUM('product','service') NOT NULL DEFAULT 'product',
`service_id` INT(11) NULL DEFAULT NULL,
`service_variant_id` INT(11) NULL DEFAULT NULL,
`parent_id` INT(11) NULL DEFAULT NULL,
PRIMARY KEY (`id`),
INDEX `code` (`code`)
)
COLLATE='utf8_general_ci'
ENGINE=MyISAM
AUTO_INCREMENT=6
;
Исходя из этой таблицы, понятно, что каждый раз, при обработке корзины мы имеем 100500 запросов в базу данных, чтобы загрузить продукт, его sku, сервисы и цены. И это мешает нам работать с корзиной, делать скидки, назначать оптовые цены, конструировать свои товары итд. Если посмотреть на экшены корзины и ордера, там сразу бросается в глаза тонны повторяющегося кода, который методом бесконечных запросов в базу данных собирает массив корзины. Все это было бы не нужно, есди бы таблица shop_cart_items содержала бы в себе данные о ценах. В этом случае мы могли бы менять цены в корзине, они бы ушли в ордер и все было бы нормально буз всяких костылей и изменений шаблонов.
Предлагаю изменить эту таблицу и добавить цену айтема. И чтобы эта цена передавалась в ордер. Тогда появится возможность написать кучу полезных плагинов со скидками и оптовыми ценами без вмешательства в шаблоны.
61 комментарий
То есть при каждом обновлении товара, вы предлагает находить все записи этого товара в корзине shop_cart_items и обновлять там кучу записей?
Лучше объясните чего вам не хватает.
Есть же класс shopCart, который умеет возвращать всю информацию с ценами и названиями товаров.
Чем он вас не устраивает?
Давайте конкретики побольше.
Для скидок есть отдельный хук и только через него и нужно назначать скидки, он прекрасно работает и используется во многих плагинах.
Класс shopCart не работает со стороны плагинов. Вы сами всегда критикуете плагины, которые делают 100500 запросов в базу, а у вас работа корзины и ордера децентрализованы. Если бы вы все это прописали в модели, и каждый раз, при вызове корзины, мы бы имели все параметры, которые нам нужны, я бы вас не критиковал.
Дайте возможность менять цены в корзине. Зачем каждый раз запрашивать их из базы? Передавайте массив айтемов со всеми сервисами и артикулами. Тогда появится возможность их изменять.
Что значит не работает со стороны плагинов?
Менять цены в корзине?
Для этого есть механизм скидок и соотвествующий хук.
Какая у вас задача, что вам этого не достаточно?
Напишите подробнее, можно даже не публично, если вы боитесь раскрыть идею, но главное максимально подробно, чтобы у разработчиков не возникло новых вопросов.
Тогда можно будет и подумать над решением.
По поводу разницы в корзине и заказе.
Если клиент добавил в корзину товар, а потом цена поменялась, а он пришёл через неделю и оформил заказ, то владельцы магазинов ожидают, что товар будет куплен уже по новой цене, а не той, которой он добавил неделю назад. Обновлять записи в корзине при обновлении товаров - это, конечно, выход, но намного лучше получать просто актуальную информацию, как сейчас и реализовано.
То есть ключевая разница в том, что когда товар в корзине, то цена на него еще может измениться, а когда он уже в заказе, то цена зафиксирована и потому там она уже сохраняется в БД.
Объясняю.
У нас есть хук cart_add
В этом хуке мы получаем айтем, который добавлен в корзину. Если бы у нас была возможность изменить цену этого айтема, нам бы не пришлось делать кучу врезок в шаблонах, чтобы задать оптовые цены или скидки или что-то еще.
А что будет в ситуации, которую я описал, когда клиент добавил товар по цене 100 руб., ушёл, пришёл через неделю, товар уже стоит 150 руб.
Если всё в БД хранить, то в какой момент будет эта цена в корзине меняться, тем более когда она еще и изменена плагином?
Вы думаете, что это большая проблема?
Ну можете спросить у владельцев магазинов, нормально ли будет, если они поднимут цены на товары, а часть новых заказов через неделю вдруг окажется со старыми ценами.
Это будет восприниматься как очень эпичный и критичный баг.
Если я меняю цену, то значит я ожидаю, что с этого момента, товар продаётся именно по этой цене.
А давайте вы не будете думать за тех, кто делает оптовые цены или конструируент свои товары?
Создайте отдельную тему опрос на эту тему и узнаем мнение владельцев магазинов.
Те владельцы, с которыми я лично знаком, придерживаются мнения, что это неправильно и так быть не должно.
я тебе Опять В Мессенджер написал, почему так делать не надо :-)
@Александр, нехватает скидок на товары. Сейчас, по факту, есть только скидка на заказ целиком и плагины пытаются эмулировать скидки на товар. Но это плохо соотносится с политикой выбора наибольшей скидки, например. Плюс приснопамятные скидки-наценки на способ оплаты. В общем у меня нет цельной идеи, потому и не выступаю :-) нужна какая-то система, чтобы указывать какие скидки суммируются, какие "наибольшая возможная". Как-то так. скидки на товар позволили бы сделать плагин для нескольких колонок цен, это иногда спрашивают.
Просто нужно расширить сущность корзины. Чтобы она несла в себе цену, а не только айдишники товаров и сервисов.
нет. Цена должна вычисляться в момент оформления, а не храниться в корзине.
Спасибо! Это вот уже по существу.
По поводу скидок на товары подумаем.
Скорее всего расширим существующий хук, как в своё время расширили его, чтобы плагины могли делать расшифровку скидок.
Ну а по поводу какие суммировать, а какие максимум, тут надо бы, конечно, побольше примеров из реальной жизни, чтобы понять как это лучше реализовывать.
Прошу посмотреть плагин "своя цена". /developer/product/1739
Так же в эту тему идут плагины опт и мультиконструктор. Все эти плагины перехватывают корзину. Если бы была возможность задавать свою цену, можно было бы обойтись без изменений шаблонов.
Ну я вам написал про проблемы вашего решения.
Как решать эти проблемы?
Я лично адекватного решения этих проблем не вижу.
Задача ваша теперь понятна, но вот как сделать это правильно, чтобы новых проблем не появилось, надо подумать.
Но я всё же проясню один момент:
Shop-Script официально не поддерживает и в обозримом будущем не будет поддерживать несколько цен для одного товара.
Но он поддерживает скидки (и именно его и надо использовать), и существующий механизм скидок действительно есть куда развивать.
Предложение Сергея хорошее и скорее всего именно так мы и сделаем, то есть просто скидки на конкретные товары и в корзине тогда цена уже будет со скидкой и в заказ цена тоже уйдёт уже со скидкой.
Александр, спасибо, что прислушиваетесь к мнению разработчиков, неглядя на личности.
Я в последнее время пришел к выводу о том, что для крупных/солидных магазинов(а те, что продают товар с несколькими ценами таковыми обычно и являются) можно/нужно забить на апдейты и херачить в исходном. Всё равно другого адекватного решения пока нет.
Детали я уже не помню, т.к. давно этот код копал. И предложить решения не могу. Но вебасисту посоветовал бы поставить этой цели приоритет повыше. В каждом третьем поступающем заказе есть несколько цен. И это всегда наценка. Скидками можно добиться лишь примерного совпадения с задуманным, да и то не всегда. В результате такие проекты идут к другим CMS. Сами знаете каким(-ой). Там они конечно платят больше, но получают свое. А проекты то эти неплохие. Известные бренды или официальные и единственные в стране поставщики... И наличие таковых положительно влияет на популяризацию фреймворка в целом. Тот же фрилансер уже может обосновать заказчику выбор CMS. Из личного опыта помню, как заказчики требовали Джумлу, т.к. "это тебе не то, на ней сайт евровидения сделан".
Пока SS5 стоит на уровне с каким-нибудь ImageCMS в этом плане.
Если не сложно, расскажите подробнее про то, что просят.
И как используются эти разные цены? В смысле как настраивается разная цена для разных покупателей.
Нам поступали запросы (но не много) на тему: хочется продавать оптом некоторым покупателям и для них нужна своя цена, скидки по категории контактов не подходят, потому что для разных товаров разная наценка.
(шёпотом) Это, несколько цен и/или цена в зависимости от количества, из коробки есть в presta. Надо оттуда дёрнуть. :)
поставлю в вскр, посмотрю, как там чего
Ну Евгений вот говорит про наценки, а не просто про разные цены.
Я пытаюсь понять, что хотят наши потенциальные клиенты.
Варианты задания цен:
"честная" отдельная цена
наценка
Варианты использования цен:
цена в зависимости от количества
цена для разных категорий контактов
Думаю не надо объяснять, что всё вместе это сделать почти нереально, нужно выбрать какой-то вариант, который более востребован.
Вы писали рассказать что нужно, приведу на конкретных примерах
Это в престе, виртуемарт, хостцмс и многих других движках(не стал приводить все подряд) думаю не просто так:
<img alt="" src="https://support.webasyst.ru/wa-data/public/hub/upload/images/presta_opt-1.png">
<img alt="" src="https://support.webasyst.ru/wa-data/public/hub/upload/images/virtuemart.png">
<img alt="" src="https://support.webasyst.ru/wa-data/public/hub/upload/images/hostcms.png">
Для предыдущей версии движка был такой замечательный плагин от siberian:
как выглядит в админке:витрина:
пример реализации: http://goo.gl/ouvAYuЕсли сделаете упор на цену от количества, то вместе с этим думаю будет и % от количества, а там может после и фантазия еще разыграется на что интересное.
Замечу что у всех приведенных мной вариантов есть цена от количества.
Интересно ваше мнение, что скажете?
Это скидочным плагином решается.
Увы не решается,
Уже писал разработчику скидочного плагина, где цена от количества, плагин не выполняет элементарного требования.
Я изучил повнимательнее ситацию с плагинами. Не могу придумать ситуации, при которой существующего функционала недостаточно.
Все решаемо. Можно не напрягаться.
Возможно, стоит подумать об обработке купонов, но здесь рабочих идей нет пока.
К тому же многоколоночность из коробки сразу вызовет требование загрузки/выгрузки из csv. В нынешней ситуации csv и так излишне функционален.
Хорошо, приведите пожалуйста плагин который решает задачи старого плагина для предыдущей версии, который я привел в сообщении выше, заранее спасибо
Персонаж №1 - официальный импортер:
Все крутится вокруг базовый цены. Проще говоря это себестоимость + импорт. То есть если рояль стоит 100к, в контейнер поместилось только 3шт., а контейнер обошелся в 30к, то базовая стоимость - 110к. Не у всех конечно именно так, но суть ясна. Если этот импортер не занимается розничной продажей, а работает только с диллерами, то диллеры должны видеть только свою цену. От категории контакта. Наценка обычно в процентах. А зависеть может от чего угодно. И от условий договора и даже от региона диллера. Если в Москве всего валом и там повсюду демпинг, то для них цена низка, а вот для диллеров с Омска цены будут гораздо выше. А для какого-нибудь Владивостока наоборот ниже московских, т.к. товар из Японии.
Скидками подстроить не получится. Будет погрешность, на которую заказчики не согласны.
Персонаж №2 - оптово-розничный магазин:
Тут всё просто. Иногда оптовая цена отличается от розничной на 50%, а иногда и вовсе не отличается. На один и тот же товар. Например товар вышел из моды, или не сезон, или размерные остатки. У таких контор в прайсах сразу стоит несколько цен.
ПС Да, в базе поддерживать несколько цен не нужно. Но нужна возможность давать наценку плагинами.
Надо пока со скидками вопрос проработать. А то опять скажут, что сами не знаем, чего хотим ;)
Ну тут проблема в том, что пишут пользователи, например, "Shop-Script плохой, там нет вот этого, сделайте срочно, без этого невозможно работать", но никто не пишет нормально деталей того, что нужно.
В итоге мы изучаем, делаем, выпускаем, а в итоге кто-то молча начинает это использовать, а остальные продолжают кричать какой плохой Shop-Script...
Вот и хочется перед тем как делать понять всё же все детали того, что нужно большинству, а потом уже реализовывать.
При разработке универсальных программных продуктов всегда так, но мало кто это понимает, к сожалению.
А поиск компромисса задача очень непростая.
Скрипт все-таки в первую очередь розничный. Если кто-то пытается запилить на нем оптовую торговлю металлопрокатом, то это, скорее неверный выбор скрипта, а не ограничение. Сегмент B2B труднее формализуется, там много разных уникальных схем типа персональной цены отдельного покупателя и прочего.
Я речь о рознице веду. Сейчас трудно реализуются вещи типа:
Есть плагины, но иногда многофункциональный комбайн не нужен :)
купи X единиц товара и получи еще одну
купи любые X из (набор товаров) и получи скидку на (набор товаров)
Это довольно просто реализуется уже сейчас, через механизм общей скидки на весь заказ.
Какие там сложности-то?
В обработчике хука посмотреть содержимое корзины и если оно удовлетворяет заданным условиям, то назначить нужную скидку.
Общая скидка на заказ должна вычисляться после расчета скидок на товары. То есть исходя из суммы товаров с уже посчитанными скидками. И общая скидка вычисляется по стратегии наибольшая возможная.
Сейчас не получится использовать несколько скидочных плагинов — должен быть только один, который будет в себя вмещать все — и скидки на товар, и скидки на заказ (и, видимо, еще и купоны).
При этом получается одна, общая скидка. При частичном возврате/отказе уже не поймешь, где что учлось. ( ← это самый сложный момент, который не пойму никак, как правильно хранить и отображать. )
Еще одно соображение:
Чтобы реализовать скидку на товар в плагине, в нынешней ситуации мне придется реализовать все остальные скидки тоже, иначе при политике наибольшей возможной скидка от категории пользователя может перебить скидку на товар. То есть в большинстве случаев вообще приходится замещать всю скидочную систему. Это увеличивает стоимость доработки (или разработки плагина скидки) и стоимость поддержки. Плюс в каждом плагине дублируется код.
Гибкие скидки всем хорош, но там с купонами засада, приходится перерабатывать. Да и многим пользователям вот эти вот правила писать...
Посмотрите, скидочных плагинов не так уж много — высокая стоимость разработки → высокая стоимость для конечного пользователя.
Если заменить цену в корзине, то все скидки пройдут автоматически. В ордере же у нас есть цена, почему бы в корзине ее не сделать? Все в разы упростится.
Еще раз. Цену в корзине хранить нельзя. Пока заказ оформляется, цена может измениться.
Уже несколько раз объяснил почему так делать нельзя.
Заметьте не только я такого мнения, но и уважаемый Сергей Родовниченко.
Все это левые отмазки. Можно взять таймстамп последнего измения товара и писать его в корзину. Если товар изменился, то производим какое-то действие. Можно даже хук на это сделать, чтобы перебрать все товары с изменившейся ценой и выставить новые цены.
Пусть для вас это будет левыми отмазками, для остальных причины понятны и очевидны.
Примите это как факт: цены в корзине в БД храниться никогда не будут.
Надо думать над другими решениями проблемы и я этим уже занимаюсь, но чтобы понять, что не появится новых проблем нужно время, чтобы рассмотреть большинство возможных сценариев.
Это слишком важная часть магазина, чтобы тут сходу начинать и переделывать что-то.
Это хорошо что занимаетесь. Будем надеяться, что все получится.
Еще один момент. У нас корзины хранятся в бд. У каждого айтема привязка к продукту. Можно в момент обновления продукта, менять все цены айтемов, связанных с этим продуктом.
А так же при изменении настроек скидок плагина?
Вы представляете что будет происходить при импорте товаров из CSV при такой реализации?
Нельзя так делать. Это приведёт гарантированно к куче проблем.
Хорошо. Давайте тогда по другому. Сделайте в таблице айтемов поле, на которое можно будет влиять из хука cart_add. И поставьте условие. Если это поле не пусто, то цена берется оттуда.
как минимум можно расширить таблицу категорий юзеров и добавить туда поле с понижающим процентом относительно цены.
В базовой версии есть скидка по категории контакта:
Магазин - настройки - скидки - по категории контакта.
Не совсем понял проблему про политику наибольшей возможной скидки и плагины.
Я придумал только вот такой кейс:
В заказе 2 товара, на 1-ый скидка 30%, на второй скидки нет, но еще у пользователя есть скидка по категории контакта скажем 20%.
Я так понимаю, вы говорите о том, что в этом случае скидка рассчитана должна быть так:
На первый товар 30%
На второй 20%
А сейчас рассчитается либо только 30% на первый, либо 20% на оба, в зависимости от того, что больше.
Вы об этой проблеме или о чём-то другом?
Если да, то это можно исправить.
Тут только одна проблема возникает: непонятно что в этом случае делать со скидками типа бесплатной доставки или просто при заказе на 2000 руб. - скидка 300 руб.
"Размазывать" по товарам в корзине? Или как к таким скидкам относиться?
сначала считаются скидки уровня товара. Получается сумма заказа. Потом считаются скидки уровня заказа. с тлф неудобно. Вечер ом раскрою тему ;-)
Ок. Очень инетересно услышать ваш вариант.
Один из проблемных случаев, который я вижу.
Есть две скидки:
1. От суммы заказа, например, скидка 500 руб при заказе выше 3000 руб. (это получается общая скидка уровня заказа)
2. Вторая по категории контакта, скажем 10% (эта скидка уровня товара)
В настройках стоит использовать максимальную скидку.
Сейчас применится гарантированно только одна из этих скидок.
А если 1-ую считать как скидку уровня заказа, а 2-ую уровня товара, то применятся обе (или как?)...
Чтобы этого не происходило, я и написал про "размазывание" общей скидки по товарам.
А для гостей (не авторизованных пользователей) какую цену показывать тогда? Явно ведь не базовую...
С персонажем 1 всё как-то сложно получается.
А вот персонаж 2 уже ближе к тому, что теоретически можно сделать в базовой версии.
Но так и непонятно, лучше пусть задаётся наценка или просто указывается явно оптовая цена (для импорта явно удобнее второй вариант).
Ну и по поводу назначения тоже нет определеённости как делать: по категории контактов или по количеству товара в корзине.
И в итоге получается, что даже если мы как-то это и сделаем, то всё равно будет куча недовольных, которым нужно было по другому...
Пока будем мониторить запросы на эту тему, попробуем понять как всё же хочет большинство.
Если у кого-то из разработчиков есть более явная картина по этому вопросу, то буду рад услышать,
Ну и постараемся дать свободу плагинам в модификации цен товаров с некоторыми ограничениями, чтобы те варианты, которые не покроются базовой реализацией можно было нормально реализовать с помощью частных плагинов, а то уж слишком много моделей использования оптовых/разных цен.
Некоторые еще хотят разные наценки на разных витринах...
ИМХО, в этом направлении изобретать велосипед - не очень правильная задумка. Почему бы не подсмотреть как это сделано в других движках, о которых тут уже писали ;)) Там механизмы отработаны годами и уже допилены под массовые пожелания пользователей =)
Замечательно, раз всё обработано годами и допилено, то напишите детально как нужно сделать.
Я вижу кучу различных вариантов даже в этой ветке, а если весь форум перечитать, то количество вариантов будет еще больше.
Что касается других движков, то там тоже по разному реализовано, в престашоп, например, сделаны только оптовые цены от количества и всё.
У меня есть большие сомнения, что именно это нужно большинству наших клиентов.
В каких то движках сделаны разные цены для разных групп покупателей...
Если есть какой-то движок, в котором реализовано и то и другое и максимально гибко настраивается, напишите, помотрим, изучим.
Я, если честно, вообще не любитель комбайнов, т.е. мухи отдельно, котлеты отдельно. Другими словами, я бы сделал вообще отдельное приложение под опт. По большому счету, оптовикам совершенно не обязательно все эти красивые витрины с описаниями и рюшечками, все это он может посмотреть на розничной витрине. Оптовику главное видеть прайс и иметь возможность ввести необходимое кол-во товара в заказ.
Далее, у каждого товара в магазине есть возможность задать закупочную стоимость, а через доп. параметры - можно/нельзя его заказать оптом и еще какие-нибудь доп. данные. Ну и в отдельном приложении уже отталкиваемся от этих данных и даем оптовику актуальную информацию. Соответственно доступ к этому приложению (витрине) имеют только определенные группы покупателей (ну или по запросу дается доступ).
Как-то так. Все это на вскидку и, вполне возможно, нереализуемо =))
Персонаж №1 является импортером. Его клиенты - диллеры. Диллером абы кто не становится. Проще говоря... в таких случаях гостям вместо цены отображают сообщение о необходимости авторизации.
>>>Но так и непонятно, лучше пусть задаётся наценка или просто указывается явно оптовая цена (для импорта явно удобнее второй вариант).
Второй вариант явно лучше. Кому нужно делать фиксированную наценку, тот либо на стороне импорта это сделает, либо через плагины. Второй вариант устроит всех "персонажей".
>>>Ну и по поводу назначения тоже нет определеённости как делать: по категории контактов или по количеству товара в корзине.
Ну среди тех проектов, что я знаю, всегда требовалось по категории контакта. За всех говорить не могу, но если подумать логически, то "от количества товара" является какой-то "примерной условностью". А значит для таких магазинов вполне сгодятся и обычные скидки.
Но выше я уже сказал, что такое требование предъявляют крупные магазины. Для них не грех и ядро поломать. Для массовости же... Только если получится это реализовать, не перегружая интерфейс. SS система хорошая. И один из главных козырей - простота и удобство.
Давно жду плагин который не пытается: "эмулировать скидку на товар" как общую скидку в корзине. Хотел купить плагин в итоге выяснилось по отзывам и у самого разработчика что скидка на общую сумму и в заказе потом цены не меняются для каждой позиции.
Нужны оптовые цены настоящие, цена от количества, а не процентная скидка вокруг до около. Даже в престе и виртумарте есть. Этот функционал охватывает большую аудиторию, а так же бывает ключевым в выборе движка.
Будет это встроенный функционал, будет бум.
Будет плагин, будет тоже бум только не с таким размахом.
Ждем, надеемся, молимся!
Если и будет, то не завтра. :(
Но рано или поздно мы авторов уговорим. Спасибо за поддержку :)
Если хотите, через пару недель, я такой плагин сделаю. Почти готово.
Посмотрите пост: https://support.webasyst.ru/forum/6124/funktsional...
Будет такой функционал? Особенно интересует функционал как в плагине от siberian для прошлой версии движка.
Кстати, если разработчики все таки решатся и реализуют оптовые цены, то что тогда вы потом будете делать? или у вас расширенный функционал будет?
Как минимум хотелось бы увидеть небольшую галочку "Стоп цена" чтоб на эти товары скидка не распространялась (не персональная, не благодаря фильтрам).
Или же если указывается "Зачеркнутая цена" то автоматом на данный товар не какие скидки не распространяются
Я сейчас пишу плагин для нормальных оптовых цен. Мне придется использовать костыль с перехватом корзины на себя. Но, если бы массив корзины содержал в себе цены, а не запрашивал их из базы данных, то я мог бы определить категорию юзера, и выставить цену для него. Далее эта цена ушла бы сразу в ордер. И никаких танцев с бубнами и перехватов классов. Вы же сами потом при модерации зарубите. Скажите как так корзину себе забрал и чекаут тоже. А если мы какие-то измениния в код корзины и чекаута внесем, а в перехваченных классах старое останется?
У нас оптово розничный магазин, давно уже поглядываем в сторону вебасиста и следим за обновлениями, ребята молодцы, движок суперский, развивается, но отсутствие инструментов работы с оптовыми покупателями из коробки и некоторые мелочи пока что нас останавливает, видимо нужно ещё подождать немного, хорошо когда спешить некуда)
Я доделал плагин оптовых цен. Перед отправко на публикацию, могу предложить бесплатную лицензию тому, кто согласится на тестирование.
Админка теперь выглядит вот так:
Категории пользователей берутся из приложения "Контакты". Хотя могу сделать чтобы брались и из приложения "Магазин", но это уже предмет обсуждения.
На фронтенде. Ничего особенного, кроме того, что каждая категория пользователей видит свою цену. Цена попадает в корзину, чекаут и ордер. Все как положено. При этом плагин никак не мешает родным ценам магазина. Если юзер не залогинен или не входит ни в одну из категорий, то будет показана родная цена. Так же в настройках можно исключить одну из категорий, чтобы она не выводилась в этом списке и работала по обычным ценам. На будущее можно сделать в настройках groupbox для того, чтобы определить какие категории использовать, а какие нет.
Одного тестера нашел. Сейчас отправлю ему плагин.