Pavel Zarubin

Спасибо, Илья, как всегда очень полезно!

Параметры вывода->разделитель и поставьте там запятую

Англоговорящие страны в плане modx вообще отстали от СНГ, там и getResources встретить можно

, было бы не плохо предусмотреть, если я использую статичные файлы, то из базы они удаляются

В случае с феномом статичные файлы туда и не добавляются, чтобы удалятся

В случае с феномом запускать сниппеты можно так:

{'@FILE snippets/snippet.php' | snippet}

где «snippets/snippet.php» путь до файла относительно корневой папки pdoTools

А чанки вот так:

{include 'file:chunks/chunk.tpl'}

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

Я предпочту вариативность его отсутствию например

Чтобы хранить чанки и сниппеты в файлах достаточно использовать феном. А так, насколько я знаю — данный выбор был сделан потому, что хранить в базе раньше было быстрее чем в файловой системе

Для этого достаточно использовать контексты, когда то они создавались именно для такого функционала и это было главной фишкой modx revo. Соответственно статей описывающих мультисайтовость на modx тьма

Если надо множественный выбор — выбирайте его

А более подробнее? Какой коммент? вы про тикетс? Это никак на мысль не наводит?

Можно gist.github.com/pavel-one/9ec3d57cf539e5841afee7aee7724e8f

@EVAL return $modx->runSnippet('getDepartament');

поместить в поле «возможные значения»
тип тв «список с автодополнением»
Сниппет подогнать под свои нужды

Как в моем случае, нельзя просто дополнение выпустить. Надо еще и сам функционал компонента под статистику доработать.

У нас в студии строго настрого запрещено переписывать исходники используемых продуктов, а т.к. мы в каждом проекте пользуемся дополнениями с modstore и расширением их функционала занимаюсь конкретно я, я еще не натыкался на компоненты, которые нельзя было бы расширить не затрагивая исходники, все таки все делают по MVC модели. Но тут утверждать на 100% не могу, возможно вы и правда в тупиковом положении и стоит обговорить с автором дополнения, было бы желание

Клиентам 2 дополнения придется ставить.

А в чем минус? В том что будет одна лишняя строчка в установщике?

Функционал компонента может измениться и дополнение станет не совместимым. Если в одном компоненте, то там это отслеживаешь, чтоб компонент был полностью рабочим. А в дополнении хата не моя и не знаю что там твориться :).

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

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

MSPRE — массовое редактирование и фильтрация, опции он не добавляет
msOptionsPrice2 — модификация цены товаров и галлереи на основе опций, а также остатки
msOptionsColor — делает удобной работу со свойствами цвета
msExtraFields — не использовал, судя по описанию похож на msOptionPrice, но видимо есть достаточно отличий, чтобы не назвать их прямыми аналогами
msFieldsManager — отличный инструмент который позволяет создавать свойства, с опциями никак не связан, скорее продвинутый редактор extjs гриды minishop2

Если вы не видите разницы между этими дополнениями, мне грустно.

В любом случае этот спор все равно риторический и от него мало что зависит, я думаю если бы авторы зарабатывали миллионы или хотя бы сотни тысяч на своих дополнениях ежемесячно можно было бы подумать о том, что с монополией на идею надо что-то делать, но пока что в лучшем случае авторы зарабатывают десятки тысяч в месяц и лучше пусть один автор получает денюжку но делает безупречный продукт и имеет стимул его совершенствовать и отвечать в поддержке, чем по 1000р но десятки разных авторов.
Живой пример реализации обеих схем — Apple Store и Play Market, попробуйте поискать человек паук в плей маркете и тоже самое в эпл сторе, все минусы предлагаемой вами схемы будут налицо. Как потребитель я за схему эпл стора

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

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

Нет не один.

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

Можно разъяснить что это значит на русском языке, без юридических терминов

Я тоже не Юрист и не работник modstore, но я это так понимаю: под прямыми аналогами подразумевается полное повторение функционала уже существующего дополнения, если непонятно, то вот реальный пример не прямого аналога:
msOrderDiscount и msDiscount суть у обоих этих компонентов одна — они делают скидку на заказ, но реализация разная, в первом случае скидка задается в упрощенном режиме в самом заказе в виде ввода одного числа и реакцией на одно событие, во втором варианте это сложный агрегат, который позволяет реализовать бОльший функционал с отдельной таблицей и со своими контроллерами

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

Разве мало компонентов которые добавляют дополнительные опции?

А разве не один единственный msOptionPrice2 это делает?

Я же написал про смену формулировку не так ли?

Не так, вы написали что с текущей формулировкой надо выкинуть половину компонентов, вот я и прошу привести пример хотя бы двух одинаковых компонентов

P.s. да и сама формулировка предельно понятна

Наши правила не допускают размещение прямых аналогов дополнений.

Можно пример того, что необходимо выкинуть?

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

А, сорян, я не знал что компонент был настолько раньше в магазине