Станислав

Добрый день. Тоже столкнулся с этой проблемой и решил ее так. С сайта ckeditor, в разделе плагины (addon) скачал плагин «justify»: ckeditor.com/cke4/addon/justify. Далее распаковал и и скопировал в /manager/assets/components/ckeditor/ckeditor/plugins (чтобы получилась там папка justify). Далее: Системные настройки, раздел ckeditor.extra_plugins, надо добавить justify. И все появится.

Добавлю сюда из ветки отсюда modx.pro/help/22916, так как часто сюда заглядываю
Чтобы по умолчанию открывался исходный код (а то у меня часто ломались некоторые страницы), нужно
в секции

CKEDITOR.editorConfig = function (config) {

добавить строчку

config.startupMode = 'source';

в файле config.js

Добавлю, что у меня в modx3 с phthump эта функция (точнее в логах ошибка связанная с этой функцией) была в файле /core/vendor/james-heinrich/phpthumb/phpthumb.class.php также на 317 строке

Hybrid Auth хороший компонент, тоже давно не обновлялся, в ручную некоторые вещи приходилось исправлять, типа авторизации через Яндекс с получением фотографии профиля

Только сейчас увидел, что у англ документации написано

Note: modRest is deprecated.
It's strongly encouraged to use the PSR HTTP Services provided since MODX 3.0.0-beta1.

и ссылка на https://docs.modx.com/3.x/en/extending-modx/services/http
а в ру документации вообще нет раздела про HTTP клиента и этого замечания, что метод устарел.
Вообщем, как я понимаю, что надо переписывать

$client = $modx->getService('rest', 'rest.modRest');

на

$client = $modx->services->get(\Psr\Http\Client\ClientInterface::class);

в modx3

Подскажите, я правильно понимаю, что если я раньше использовал

$client = $modx->getService('rest', 'rest.modRest');

то теперь

$client = $modx->services->get('rest');

А то на прошлый вариант пишет deprecated и не могу найти доки как в 3 версии rest клиентом пользоваться
В целом код был такой у меня раньше

$client = $modx->getService('rest', 'rest.modRest');
$client->setOption('timeout', 15);
$client->setOption('header', true);
$client->setOption('connectTimeout',10);
$response = $client->get($url, $params);
$data = $response->process();
$arr = $modx->sanitize($data, $modx->sanitizePatterns);

и по сути только меняется getService?

Да, помогло. Спасибо огромное.

[[+image:is=``:then=``:else=`<div class="col-md-3"><img src="[[!pthumb? &input=`[[+image]]` &options=`w=320&zc=1`]]"></div>`]]

Правда у меня теперь 3 пакета установлено по миниатюрам

спасибо

ООП нужно кому-то учить.

согласен, спасибо

Если я внутри функции не объявляю modx ($modx = new modX()...), то при вызове функции даже внутри снипета будет ошибка «Undefined variable: modx in...»

Понял. Значит мы оба нашли разные рабочие решения вопроса.

Замечу, что и в самой БД эти поля должны быть tinyint(1), к слову ваше решение у меня не показывает галочки, а без него — показывает :-) Это как бы странно, но если у вас работает и вам помогло — то хорошо.
Специально создал новый xcheckbox, при даже просто типе поля int в map.class и в БД — значение 1 отправляет, но галочки нет. Tinyint в map и в самой БД — отправляет и открывает с галочкой.
Я прошу прощения, что отвечаю спустя практически 2 недели. Забыл про оповещение с форума

Итак, вернусь. Проблема была в следующем: задания в крон ставились, выполнялись, но при выключении или удалении возникала эта ошибка:

[Crontab] $jobSpec must be crontab compatibile entry

(к слову сказать в слове compatibile ошибка (compatible)). Ввиду того, что дискуссия ни с кем так и не началась, а писать автору мне было стыдно и неловко (т.к. компонент бесплатен и пока что мне нечего предложить взамен), я начал делать диагностику всего. В первую очередь права — как известно многие ПУ, в частности PLESK для крона выдают bash (chroot) или как-то так, только внутри области пользователя. Точнее когда системный пользователь «видит» только в тех пределах, где расположен сайт. Ок, тут расширил права в настройках, чтобы работал путь до php. Но это не повлияло. Я поискал где вообще возникает ошибка и за проверку переменной jobSpec выступают два файла, один из них — CronEntry.php. Вот тут и прятался ответ на задачу.
Добавив в лог ошибок значение переменной

if (!preg_match($regex, $jobSpec, $match)) {
            throw new \InvalidArgumentException($jobSpec.' -> -> -> '.'$jobSpec must be crontab compatible entry');
        }

я обнаружил, что переменная $jobSpec принимает значение MAILTO="" и дальше уже текст ошибки. Я проверяю «список заданий» и вижу, что те задачи, которые я ставил с панели управления сервера напрямую приобретают вид:

MAILTO=""
SHELL="/bin/sh"
*/1 * * * * /-----/php/7.3/bin/php -f 'httpdocs/path/file1.php'
* */2 * * * /-----/php/7.3/bin/php -f 'httpdocs/path/file2.php'

Когда же ставится задача с компонента, то он не прописывает все параметры, а просто

*/4 * * * * /------/php/7.3/bin/php /var/---/---/---.ru/httpdocs/core/scheduler/ControllersLinks/file1.php > /var/---/---/---.ru/httpdocs/core/scheduler/logs/task_id_14_File1.log 2>&1 # 6ounu4

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

$regex = '/^\s*(([^\s\#]+)\s+([^\s\#]+)\s+([^\s\#]+)\s+([^\s\#]+)\s+([^\s\#]+))\s+([^\#]+)(?:#(.*))?$/';

Чисто в теории если добавить\поменять\переписать добавив ^[/*0-9a-z] где-то вначале, то он пропустит лишние строчки и считает именно запись задачи. Но к сожалению я не селен в регулярки и изучение примеров ни к чему меня не привели. (а упростив проверку я вовсе «убил» все свои задания (обидно было)). Каюсь, регулярные приложения знать надо. Виню себя и ругаю.
Ну так вот, когда я «зачистил» все свои задачи поставленные напрямую с панели управления vds и добавил их только с панели управления компонента, то все стало работать. И удаление, и выключение, и включение (правда иногда через раз не включается) да и при нажатии на кнопку «список заданий» выводится список без дополнительных параметров.
Поэтому, если автор вдруг это прочитает, то по идее нужно поправить в условии $JobSpec регулярное выражение, чтобы оно пропускало что-то не типичное для себя и забирала исключительно формат классической задачи. Если нет, придется изучать регулярки :-( Так как я боюсь, что возможно нужно будет что-то добавить с панели управления сервера (какие-нибудь ротации или чистки куша) да и не проверил компонент полностью, если прописать в настройках все параметры уведомлений.
Еще раз — компонент классный, одной только проверкой на количество неудачных запусков. Еще раз простите за беспокойство.

Вновь прошу прощения, оказывается у меня все работает при выставлении параметра crontabmanager_handler_class в значение CrontabManagerHandler в настройках. Примеры запускаются и становятся активными, правда не выключаются, если выключить demo задание, то будет

[Crontab] $jobSpec must be crontab compatibile entry

а если создать свое с одной строчкой записи в лог, как в демо, то

PHP warning: preg_match(): Unknown modifier 'n'

и такое же

[Crontab] $jobSpec must be crontab compatibile entry

Я так понимаю, что ошибки могут быть из-за ограничений безопасности modsecurity, а какие могут быть влиять, чтобы я их отключил?

Я, видимо, буду первый :-)
В первую очередь огромное спасибо, компонент в идее очень полезный, например у меня много данных пишутся в базу в кроне из под ПУ VDS и управлять заданиями сразу из modx очень удобно. А у вас еще и расширенный функционал. И я в это дополнение по описанию практически влюбился. Но куда ж без ошибок:
при попытках включить даже демо
components/crontabmanager/lib/crontab/CrontabManagerManualFile.class.php 16
PHP warning: file_put_contents(/var/----/scheduler/crontabs/): failed to open stream: ��� �������
[Crontab] Не удалось записать
*/1 * * * * /usr/bin/php7.0 /var/ -...- /scheduler/ControllersLinks/demo.php > /var/------/scheduler/logs/task_id_1_demo.log 2>&1 # t0kc9y

Я так понимаю, что нужно где-то копать в права, осталось только понять — где :-) в github у вас «Для работы необходимо чтобы на хостинге был доступ к функциями: system и passthru для запуска из под php» хотя в кроне ПУ plesk все работает

Далее не совсем понятно структура и принцип вызова) например в обычном режиме я подгружаю класс modx, далее $modx = new modX(); и впоследствии оперирую уже $modx? как пример

if(!$q = $modx->prepare($s)){
                $modx->log(MODX_LOG_LEVEL_ERROR, 'Ошибка выполнения запроса '.$s.' : '.$q->errorInfo()[0].'->'.$q->errorInfo()[1].'->'.$q->errorInfo()[2]);
            }

Я это делаю, потому что когда крон сервера запускает php файл, он не знает про modx ничего.
У вас в demo.php, тот же лог, вызывается как

$this->modx->log(modX::LOG_LEVEL_ERROR, "Задание завершено");

получается основной класс загружен я и должен заменить все свои $modx на $this->modx? Но как крон узнает, что такое modx? не замедлит ли это работу?

Потом не совсем понятна структура, основные файлы для крона должны лежать в schelduer\controllers
ControllersLinks — он сам создает, как я понял, при запуске
а вот папка tests и в ней demotests.php и frontend — это зачем и мне нужно создавать свои при создании своих задач?

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

Правда twigletriger так и не смог настроить, все время выводит тэг img, даже конфигурация не меняется на лету. Однако, когда реализовывал через 'trigger', обнаружил, что забавно, — все работает по умолчанию без лишних классов и триггеров при выставление типа поля. Вот так:

xtype: 'numberfield',
type: 'number',
inputType: 'number',
name: 'orderby',
width: 100,

сами «стрелочки» появились у поля. Правда мне идея с триггерами понравилась, может где и когда применю.

Спасибо большое, буду разбираться

Забыли, все что я тут написал — это не совсем верно. Точнее этот код галочку то будет ставить, но вот 0 уже не отправит. Ошибка, оказалась, в моей бестолковости и невнимательности. Посмотрев в console.log(this.menu.record); я обнаружил, что то, что должен показывать xcheckbox (1 или 0) передается в кавычка. И тут меня осенило — в файле class.map.inc.php те поля, которые для галочки прописаны как текстовые. Как только я поменял на

'view_index' =>
                array(
                    'dbtype' => 'tinyint',
                    'precision' => '1',
                    'phptype' => 'integer',
                    'null' => false,
                ),

все стало работать как нужно. Такие вот дела. Надеюсь, кому-то поможет.

Долго выбирал на какой комментарий ответить, так как не смогу промолчать. Я очень долго время увлекался joomlой, где есть много плюсов, в частности можно легко «под себя» переписать компоненты, не трогая оригинал, с привязкой к шаблону. Да и шаблоны пишутся очень легко и по сути визитку можно за неделю поднять.
Но как-то познакомился с MODx revo и мне он очень сильно зашел (кстати, натыкался на то сообщение, что Revo развивается, а Evo уже нет). И мои этапы были такие — первое, что меня влюбило — возможность писания своих php дополнений с разделением (снипеты и чанки) чистого кода для себя и простого для дизайна\верстки. Это круто. Потом я узнал про pdotools, расширяемость пакетов. Далее перешел на стадию написания своих, сложных и не очень, компонентов (с возможностью лексиконов в мультияз), а в настоящий момент уже постигаю написание страниц админки с extjs. Я далеко не супер разработчик (я вообще считаю себя бездарем), но при выборе платформы для нового проекта modx, wp, joomla и т.д. (tilda вообще зерокодинг) — я бы выбрал Modx. И именно за счет перспективности развития будущего проекта — границ по сути нет и любое желание можно исполнить своими силами. Но что не нравится — сложная структура для понимания -или это уж очень сильная попытка все раскладывать по полочкам, ну или я тупой ) но легко можно запутаться при написании, где какой класс, класс в классе, процессор, модель, схема и т.д. Второе это тот же extjs. я здесь уже задавал вопрос, задавал и на stackowerflow — очень тяжелый фреймворк(?), для написания (надеюсь только мне). А свои странички иногда очень нужно создавать. Ну и то, что из коробки modx нужно расширять, казалось бы функционалом, который должен был бы идти базово — например тот же collections, да я думаю у каждого разработчика уже свой мастхев пакет. Ну и, конечно же. третье — сложность работы в IDE, например в phpshtorm, т.к. сниппеты и чанки это в основном запись в sql базе, которые потом кэшируются в файлы.

Я к чему это написал все — прослеживается тут в комментариях грустная мысль, что modx держится на тех, кто тут активен. Но на самом деле я уверен, что Modx будет привлекать разработчиков разного уровня знаний и я вижу в ней большой потенциал. И потому желаю всем, кто помогает развиваться cms сил, терпения, везения и огромная вам благодарность.