Іван Клімчук

А какая версия PHP у вас? Насколько я помню, уже описывали такую проблему, что в коде компонента использован короткий синтаксис массисов из PHP 5.4, который не работает на более низких версиях. Возможно что-то еще.

Видимо какой-то особый недоброжелатель. Однажды мне такой прошелся прям по всем постам и комментам и минусов наставил (не поленился же). Вася тогда исправил и починил рейтинги, но как факт — такое возможно.

Вероятно да, не получится, если система полностью изолирована.

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

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

Да. Какая разница, где выдавать пароль? Достаточно иметь некую базу, где хранить сигнатуру или любой другой параметр, который будет однозначно идентифицировать пакет + данные для авторизации и выдавать на такой запрос пароль. В modstore.pro это сделано в одном месте, но ничего не мешает сделать внешний свой сервис, и держать пароли там, если нет доверия к репозиторию.

Пока писал, пришла идея, что таким способом можно распространять платные дополнения даже через официальный репозиторий. Не решенным остается только вопрос с одобрением таких пакетов со стороны MODX LLC.

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

Самое любопытное, что развели холивар, а по теме поста и тому, как работают пакеты в MODX никто ничего не спрашиват. Неужели все всё знают? Если почитать в чатах, так только такие статьи и просят, с пояснениями как что в MODX устроено и работает.

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

Василий, вы и MODx сейчас находятся в самом начале своего развития, я верю в вас.

Хоть бы википедию для приличия открыли бы. MODX, включая обе ветки, уже почти 15 лет на рынке. Платные дополнения для него — около 5. И все прекрасно развивается. И где вы увидели у MS бесплатность? Windows всю жизнь продается за деньги, и там, где у MS дотягиваются руки (а не потому что нет желания), за пиратство она нещадно наказывает.

Лечить симптомы, но не болезнь?

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

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

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

$itplace= count($item['places']);

А вообще php.net/manual/ru/

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

Нет, не стоит. Вернее какие-то моменты не мешало бы, да, вроде того же обновления. Но AutoTemplate — частный случай, что делать, если мне нужно наоборот? Ставить AntiAutoTemplate? filetranslit вероятно, хотя тоже спорно.
minifyHTML, minifyx — однозначно мимо, потому что это не ворпрес, где все уже сделали за тебя, сиди пиши свои мнения на весь мир. Кто-то может вообще все собирать с помощью gulp/grunt/webpack, зачем ему тянуть вместе с системой подделие, которое уже пару лет как не поддерживается нормально (движок минификации на php в minifyx).
Установка пакетов за раз вероятно будет когда-то, но там есть свои ньюансы. Но уже сейчас это можно делать с помощью gitify.
В будущих версиях MODX планируется удалить еще больше вещей, которые не являются остро необходимыми для ядра. Сейчас кодовая база самого MODX слишком большая и поддерживать ее в рабочем состоянии довольно затратная задача, при том, что энтузиастов помогать в этом как-то нет. Если все эти хотелки внедрять в ядро, это увеличивает энтропию, а как следствие больше ошибок, больше граничных случаев, запросов от пользователей и прочее, что делает разработку самой системы очень медленно, да и мелкую фичу можно ждать полгода, потому что кроме нее еще десяток крупных, а релизить MODX только ради мелочи — очень затратно. Все же я придерживаюсь принципов бережливого производства, так как они самые адекватные и понятные всем.
Вынесение пользовательких функций в отдельные дополнения выгодно по многим пунктам: даст возможность более плотно работать над ядром системы и быстрее выпускать по настоящему стоящие релизы, не отвлекаясь на поддержку пользовательских функций; отдельные дополнения можно релизить независимо и выпускать патчи и новые возможности намного быстрее, чем релизы ядра; легче привлечь людей в качестве мейнтейнеров на отдельные дополнения, которые будут заниматься только ими и активно их развивать (т.е. делегация полномочий). Надеюсь моих доводов достаточно для понимания текущей ситуации.

Пользуйтесь, зачем мечтать? www.modmore.com/redactor/

Так а вы инструкцию внимательно читали? Сам то он работает, но чтобы автоматически работал, нужно в настройках сервера добавить запуск скрипта «сайт/..../cron.php» непосредственно в cron-обработчик сервера. На каждом хотсинге это может делаться по своему, нужно у своего уже уточнять.

И раз уже fenom, то лучше не мешать синтаксис и вместо [[$Page-parent-content]] использовать {'Page-parent-content' | chunk} или {include 'Page-parent-content'}