Алексей Соин

попробуй так

foreach ($items as $key => $item) {
    $id         = $item['Id'];
    $name       = htmlspecialchars($item['Name']);
    $parent     = $item['ParentId'];

    $response = $modx->runProcessor('resource/create', array(
        'class_key' => 'msCategory',
        'pagetitle' => $name,
        'parent' => 3,
        'template' => 3,
        'show_in_tree' => 1,
    ));
    
    if($response->isError()){
        echo 'Ошибка';
    }else{
        echo 'Создал';
    }
}

и ты уверен, что тебе нужно все ресурсы из массива создавать как категории?

А какой технологии которая отвечает требованиям рынка в 2020 году не хватает в modx именно вам?

Что не хватает в modx чтобы она для вас стала настоящей modx 3?

Почему именно киллер-фичи должны быть причиной смены мажорной версии? Если посмотреть например тут, то можем увидеть, что смена мажорной версии является также изменение структуры/api приложения которые ломают совместимость с предыдущей версии, и мы видим, что в данной альфа версии для работы привычных дополнений нужно сделать некоторые обновления кода, следовательно в modx были сделаны изменения которые ломают обратную совместимость.

Так что троечка в версии на своём месте)))

Ты имеешь ввиду этот?)

Если имеется ввиду, как использовать композер на modx 2.x, то я уже давно пользуюсь инструкцией Сергея Шлокова на его сайте.

А в modx 3.x вроде как композер из коробки уже есть.

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

Возможно есть какие то методы это исправить

Нашел вот такую cli node утилиту https://github.com/ddopson/underscore-cli она не только форматирует вывод, а ещё и подсветку синтаксиса делает. Вдруг кому интересно будет =)

ну если ты считаешь, что данный подход лучше чем использовать методы modx, ок.

я в этом ничего полезного к сожалению не увидел

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

а не проще сделать выполняемый с периодичностью по крону php скрипт который парсит данные и записывает результат в контент ресурса или допустим в тв поле?

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

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

Интересная статья, спасибо?

кстати, вдруг кому будет нужно, чтобы в wsl открыть папку расположенную на локальном диске нужно перейти в /mnt/ и там будут примонтированы соответствующие локальные диски C D и т.д.

еще можно в командной строке windows написать команду

bash

и запустится баш консоль от wsl

Read (он же Select) в базе данных будет эквивалентен HttpGet в REST

Самое важное это гарантировать что если вы шлете запрос типа READ, на сервере действительно произойдет HttpPut.

Чёт я немного запутался))) HttpPut или всётаки HttpGet?)

Отличная статья?! Спасибо! Теперь ждем статью по REST?

и что мешает вывод данных полей отключить и не видеть их, если они так тебе мешают?

Два раза пишут одно и тоже в поле pagetitle / longtitile

Зачем? можно написать чтото типо такого:

{$_modx->resource.longtitle ?: $_modx->resource.pagetitle~' | '~$_modx->config.site_name}

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

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

это уже на совести их авторов

тут бы придусмотреть такой вариант, чтобы не только автору можно было адаптировать дополнение под API, а и самому разработчику сайта, например, я не думаю, что тотже автор MIGX сразу обновит дополнение, а своими силами почему бы и не адаптировать)))

Недавно тоже задумывался сделать простенькую админку для менеджеров, в результате задумался о проблеме кастомных тв, и страниц администрирования созданных дополнениями. Возникла такая идея, возможно она мегакостыльно звучит, но всёже, vuejs хорошо работает в связке с другими js библиотеками, с темже jquery например, что если не отказываться от extjs, а оставить возможным работу с дополнениями написанными на нем, а уже для новых дополнений делать некую поддержку выноса на фронт, как предложил Сергей. В таком случае можно и развивать дополнения и оставить поддержку на первых началах стандартной админки.

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