Сергей Шлоков

Эх, молодежь. Это называется хакеры всех стран, заходите! Значение from откуда прилетает? С сайта?

Используйте подготовленные запросы.

Кстати, для отладки есть удобный метод toSql(), который выдает подготовленный распарсенный sql запрос.

О том же, да не о том. Хоть внутри ключ храни, хоть снаружи. От копирования файлов он не поможет. Вся эта защита от простых пользователей типа администраторов, которые просто ставят нужные пакеты, да от ленивых разработчиков, которым хочется марочиться.
Они точно не будут лазить и искать алгоритмы.
А алгоритмы можно придумать разные — удалить файл, или испортить исходник класса, и ещё много чего можно придумать. Т.е. и не подумаешь, что проблема в ключе. Баг какой-то. Даже если разработчик пишет тебе в техподдержку для сайта, для которого куплен компонент, просишь его выслать код класса и всё становиться ясно. Тут уж как фантазия работает.

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

Вань, ты прикалываешься что-ли? Да нахрена его взламывать, лазить по файлам, искать где шифруется, если можно просто скопировать код? В этом случае на каком уровне твой плинтус? У меня 2 минуты заняло поставить Office на локалку — скачать с сайта (без архивирования!), выполнить ряд манипуляций (не буду говорить какие) и поставить ещё один зависимый пакет (а может не один).

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

И я про тоже. Только без внешних источников.

П.С. Кстати, а пользователь не знает, есть запрос на внешний источник или нет. Может и искать нет смысла.

Вот и я про то же. Раз насоздавал пакетов для разных разработчиков, то придётся и сайт создать для их защиты.

Кстати, пока писал, пришла идея :) — наверно можно использовать динамический ключ для таких пакетов, чтобы не лазить в репо? При сборке пакета по заданным условиям его формировать, а при распаковке проверять. Теоретически возможно.

И куда этот пакет будет обращаться за паролем? На твой сайт?

Статья познавательная! В своё время вникал в механизм пакетов, когда баловался с modTerminal. Но статью написать не сообразил.
А флудить начали именно потому, что нет ясности. Вот и возник спор.

Функция members принимает только один аргумент.

всё это давно прописано.

Ткни пальцем, просвяти нас немытых.

Ну я прям несказанно за тебя рад. Теперь напиши инструкцию по обходу — и я начну использовать ionCube, всем будет только веселее, правда?

Ты вообще что-ль нормально разучился разговаривать? Ничего мне не нужно уточнять, успокойся.

Согласен! Но вопрос с техподдержкой всё-таки нужно как-то уточнить в положениях магазина.

П.С. Только что ради эксперимента поставил Office на локалку. Потратил 2 минуты.

Как продавали поддержку, так и продаём

В положении магазина дополнений modStore по этому поводу ничего не сказано. А в «Вопросах» отвечают, что продаётся дополнение.
А если продается техподдержка, а не лицензия, то почему нельзя использовать дополнение без техподдержки. В чём непорядочность разработчиков-неплатильщиков в юридическом смысле? Нигде же не сказано про обязательность техподдержки. И получается, что ты усложняешь жизнь разработчикам, которые формально ничего не нарушили. Они за техподдержку не платили — они её не получают.

Это вопрос скорее к ребятам из MODSTORE. Я как автор платных дополнений заинтересован в четких правилах, повышающих мои права и продажи.

До сих пор нет ясности, что же всё-таки мы продаём — компонент или техподдержку. В предыдущих обсуждениях остановились на том, что продаётся техподдержка на год.

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

Данные по запросам к БД вызывают сомнение. Почему они разные?

Сравнивать тысячные доли? Это даже не погрешность, это погрешность погрешности. Пять раз обнови страницу, и пять раз цифры будут разные даже не меняя код.

Я когда переходил не феном тоже сравнивал. Разницы в скорости при вызове сниппетов через стандартный синтаксис и через феном никакой.

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

Не путай человека.
Парсер MODX запускается перед феномом только для обработки кэшируемых тегов. Вообще парсинг выглядит так:
1. Запускается парсер MODX и обрабатывает кэшируемые теги. Феном теги остаются необработанные.
2. Запускается парсер фенома, если есть теги Fenom.
3. Запускается парсер MODX и обрабатывает некэшируемые теги пока они есть. Нераспарсенные не удаляются.
Пункты 2 и 3 могут выполняться в цикле до 10 раз, если есть нераспарсенные теги.

// В сниппет попадёт распарсенный тег феном
[[!snippet? param=`{$value}`]]

4. Запускается парсер фенома, если есть теги Fenom.
5. Запускается парсер MODX и обрабатывает некэшируемые теги пока они есть. Нераспарсенные теги удаляются.
Пункты 4 и 5 пункт могут выполняться в цикле до 10 раз, если есть нераспарсенные теги.
Многие, наверно, обращали внимание на тормоза, если указан несуществующий плейсхолдер.

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

Я бы посоветовал использовать оба парсера так:
— юзать только кэшируемые теги MODX ([[*tag]], [[$chunk]], [[++system]], [[snippet]]). Хорошо для оптимизации.
— для остального использовать феном.
В этих режимах парсеры не пересекаются.

Переделаешь под новый минишоп, отвалится текущий работающий функционал. Выход — делать oneBooking2 чисто под новый минишоп и получить проблему с апгрейдом. На всё это нужно время. Его пока нет. Тем более, что минишоп нужен только для привязки плагинов оплаты. А старый справляется с этим без проблем.

Ну в самом первом примере есть же select().

Добавил пример в описание метода select.

так будет работать?

А попробовать?

Читайте документацию.

Не должно быть. Это баг. Завтра поправлю.

П.С. Я бы ещё посоветовал ограничить список полей через select(). Не зачем ненужные поля выводить.

Ну никто же не знает на чём ты тренируешься. Хорошо, что иначе. Возможно и без кэша можно обойтись. А сейчас грустно смотреть на прелоудер. )

Сейчас вкладка «Комментарии» загружается 1.1-1.3 сек. В dev версии грузится в 10 раз быстрее? Турбину поставил? :) Неплохо.

Конечно, это пост оптимизация.

Я бы посоветовал кэшировать виджет «Прямой эфир». Хотя бы на минуту. При добавлении нового комментария или поста кэш сбрасывать. Уверен, время загрузки виджета снизиться драматически, а минуту мало кто заметит.

П.С. У меня работает отлично. Феном в помощь.