Александр Туниеков

А вот эти строки

$modx = new modX();
$modx->initialize('mgr');
$modx->getService('error','error.modError');

точно нужны? Я делал другой плагин копируя этот и у меня из-за них возникала проблема что не находит xpdo классы компонентов. Не понятно зачем нужна вообще здесь инициализация нового объекта $modx

В файле схемы были не правильно заданы типы полей phptype. Вместо text поставил string и все заработало. На рабочем сайте обновите компонент и проверяйте как там работает.
В emailqueue.mysql.schema.xml вместо этого

<field key="body" dbtype="text" phptype="text" null="true" default=""/>
<field key="attachments" dbtype="text" phptype="text" null="true" default=""/>

сделал это

<field key="body" dbtype="text" phptype="string" null="true" default=""/>
<field key="attachments" dbtype="text" phptype="string" null="true" default=""/>

Я эти поля как в modExtra сделано так и делал.

Сделайте плиз если не трудно. у меня на php 7.2 ничего тестового нет

Здравствуйте! Вот чтоб именно пустое поле получилось вообще странно :(. Пока скачиваю Опенсервер новый. Попробую поставить PHP 7.2.00 и посмотреть.
Хм. Он 3 часа обещает скачиваться. Может все таки дадите доступ к вашему MODX?

А нашел. просто раньше не пролистал вниз вкладку :(

Это к чему вообще? :) Каюсь по ссылке не досмотрел, но ругань все равно не понятная :)
Кстати а как через менеджер MIGX inputTV проставить? я только через правку JSON конфига сделал.

Ищи в поиске migx внутри migx
например https://www.youtube.com/watch?v=_CFCr_embNw
Я недавно делал migx внутри migxdb :)

Правила приема приложений в App Store

Редакция МОЖЕТ отклонить приложения, которые:
2.11 повторяют приложения которые уже есть в App Store, особенно если их там уже много, например: фонарики, Кама Сутры, пукающие приложения.

Хорошее правило, но явно не запрет прямых аналогов.

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

Прямо реклама монополии :). Всю жизнь учили, что конкуренция лучше, а тут прямым текстом монополия лучше :). Я отстал от жизни? Монополия в ИТ лучше?
Мне кажется, что монополия провоцирует не совершенствовать продукт, а просто сидеть и стричь денежки :).
Если вдруг на мой компонент появиться конкурент и продажи упадут вдвое, то я, скорее всего, увеличу стоимость компонента вдвое. В расчете на то, что конкуренту тоже надо отбивать вложения, и так как, сложный компонент дорого делать, то конкурент тоже подымет стоимость.

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

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

А я вот не уверен. В правилах четко написано никаких прямых аналогов. Значит никаких. А то что за произвол? Это понравилось одобрим, а это не одобрим. И вдруг стоящий и сложный компонент чуть чуть не дотянет и его не одобрят, а время то на сложный надо много :(.

Владельцы MODSTORE обычно сначала интересуются мнением авторов аналогичных платных дополнений. И если автор против нового компонента (обоснованно), то магазин отказывает в публикации. Это уже много раз обсуждалось.

Можно ссылки где это обсуждалось. Что-то я не верные слова в поиск забиваю.

Очень заинтересован, как можно ознакомиться с демо компонента?

Мой компонент UserTest. По крайней мере требовалось сделать статистику тестов. Сколько на что сдали и т.д. с диаграммами. Сейчас заказчик в отпуске и говорит не знает требуется ли еще статистика.
Вы в разработке этого компонента заинтересованы? Или в чем заинтересовались? :)

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

автор отвечает на вопросы по своему функционалу, а вы по своему

2 плюс если клиенту не нужна статистика он ее просто может не покупать.

В целом мне было бы интересней и клиентам удобней в одном компоненте. Только админам Modstore под группы разработчиков переделывать магазин — это много работы. Наверно они на это не пойдут :(.

Понятие прямого аналога все таки нечеткое. Допустим компонент msImportExport. Например я сделаю просто кнопку в админке для импорта товаров через стандартный скрипт минишопа http://webcandy.ru/manuals/import-csv-minishop2/. Плюс доработаю на долгую обработку, чтоб не обрывало при импорте многих товаров. Это будет считаться прямым аналогом?
Здесь в

в упрощенном режиме

а в msImportExport

бОльший функционал

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

Ну мне главное не продавать компонент, а разнообразие доступных компонентов. Доступных в смысле посмотрел в магазине, что есть и выбрал, что более подходит. Я не все топики читаю неудобно по ним рыться. Да и компонент в модсторе гарантия, что перечислил кому-то левому деньги и не фига не получил. И для разраба удобнее через магазин. Гарантирует, что деньги получишь.

Кажется это сделано для того, чтобы разработчики не воровали код у друг друга. Код то открытый и в компоненте, при желании, можно восстановить билд, переименовать компонент и продавать как свой.
Но лучше с воровством бороться как-нибудь другим методом :(. Разнообразие компонентов нужно.
Пишите комментарии. 2 отзыва маловато, чтоб на администраторов modstore повлиять.

у phpThumbOn качество по умолчанию стоит 0.9 и я его не менял. А вот OptiPic этот же файл сжал на 67%

У меня при загрузке в ms2Gallery картинки не загружались. Поправил следующим образом.
В файле core/components/tinycompressor/model/tinycompressor/tinycompressor.class.php
это

function createTinyPNG() {

        require_once $this->config['modelPath'] . '/tinycompressor/lib/tinify/init_tinify.php';
        $this->tinyPNGClient = (empty(trim($this->config['tinyPNGApiKey'])) ) ? false : new Tinify\Client($this->config['tinyPNGApiKey']);
        $this->tinyPNGCrazyClient = new Tinify\CrazyClient();
        return true;
    }

    function createILovePDF()
    {
        require_once $this->config['modelPath'] . '/tinycompressor/lib/ilovepdf/init_ilovepdf.php';
        $this->iLovePDF = (empty(trim($this->config['iLovePDFProjectID'])) || empty(trim($this->config['iLovePDFProjectKey'])) ) ? false : new Ilovepdf\Ilovepdf($this->config['iLovePDFProjectID'], $this->config['iLovePDFProjectKey']);

        return true;

    }

заменил на это

function createTinyPNG() {

        require_once $this->config['modelPath'] . '/tinycompressor/lib/tinify/init_tinify.php';
        $t = trim($this->config['tinyPNGApiKey']);
        $this->tinyPNGClient = (empty($t) ) ? false : new Tinify\Client($this->config['tinyPNGApiKey']);
        $this->tinyPNGCrazyClient = new Tinify\CrazyClient();
        return true;
    }

    function createILovePDF()
    {
        require_once $this->config['modelPath'] . '/tinycompressor/lib/ilovepdf/init_ilovepdf.php';
        $t1 = trim($this->config['iLovePDFProjectID']);
        $t2 = trim($this->config['iLovePDFProjectKey']);
        $this->iLovePDF = (empty($t1) || empty($t2) ) ? false : new Ilovepdf\Ilovepdf($this->config['iLovePDFProjectID'], $this->config['iLovePDFProjectKey']);

        return true;

    }

Теперь работает, но сервис после phpTrumbOn картинки меньше не делает.


PageSpeed Insights ругается, что картинки можно сжать еще. В итоге компонент мне не подходит. Буду пробовать OptiPic

Т.е. я не знаю зачем это нужно, поэтому удалю нафиг?

Да :). Там где это точно не на что не повлияет. Просто имя кеша будет другое и все. А в сам $scriptProperties не трогаю. Я ведь верно понимаю, что удаление из переменной $options внутри функции на $scriptProperties не влияет? И в остальном коде setTotal присутствует?
Не знаю в каких. Наверно не в каких, но если вдруг где-то еще кеш используется, то очистка зависимости имени файла кеша от request не помешает.
И вообще включите на гитхабе issue и я бы вообще в этот код не лез.

Ну я хотел сначала issue, но не разобрался где оно там на гитхабе, а с пулл-регвест разобрался. На pdoTools issue кажется вообще заблокированы. Это во первых. Во вторых setTotal мне вообще не понятно зачем нужно и зачем оно именно в том месте. А request лучше в ядре удалить. Из-за него у всех сниппетов pdoTools проблемы с кешированием.