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

Проверь системные настройки disk.yandex.ru/i/Wz4WVyqZH9OLag
disk.yandex.ru/i/ALApVYnvmNWeFw

https://modx.pro/help/24026#comment-139589 посмотрите переписку по ссылке

Ссылки на документацию слетели. Домен не прилинкован. Не хорошо. Компонент продаете так документацию не теряйте плиз.
Нашел документацию. docs.modx.pro/components/googlesheets/ поправте ссылки в описании компонента на модсторе

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

А кто bigint то ставит? Для обычных магазинов int 10 как обычно хватит. А на несколько миллионов товаров с учетом что при импорте обычно опции будут удаляться и заного забиваться то int 10 может не хватить. И магаз внезапно новые опции не принимает. Но за подсказку спасибо. Как gtsShop выберется в продажи bigInt на праметры расчета поставлю. А то только на тестах на 2 заказах инкремент параметров уже за 2000 перевалил.
Не буду говорить что знаю зачем @Василий Наумкин primary key на опции не поставил. Инкремент мне кажется правдоподобной догадкой.

Кто не знает, в miniShop2 опции у продуктов реализованы достаточно странным образом. При каждом сохранении ВСЕ значения опций товара первым делом удаляются из таблицы, затем на их место записываются обновленные (или старые) значения. Такая механика работы не позволяет их индексировать, корректно перезаписывать через API, расширять таблицу и т.д.

Тут проблема. Если опций окажется больше 10 000 000, то они работать перестанут. То есть новые не создашь когда инкрементный ключ закончиться. На это и было расчитанно. Но 10 000 000 опций редкость и с объектами да удобнее работать :-)

Вообще идея новой CMS меня стала преследовать с появлением MODX3. Например мой getTables в нем сейчас работает, но используемые функции объявлены деприкейтед. То есть в любой момент getTables может перестать работать. И на модели MODX3 не перейдешь. Нет там нужного функционала. То есть фактически MODX3 убивает 2 года моей работы :-(.

Вообще 150 мс инициализация ядра? У меня инициализация на шаредах обычно 20....40мс. Поэтому, думаю что все это зависит от хостинга.

Где-то прочитал что 150мс :-(. Чет сам не проверял :-(. Я делал при старте сервера закидывать сниппеты и чанки в объект js. То есть закидывал прямо в память. Доступ тогда к ним быстрее чем брать из базы или диска. Только парсер время съедает. Так бы наверно и в 1мс можно было уложиться :-).

Мне например хватает того что есть, а если не хватает, я беру Vue и делаю modx+vue — это и дешевле и быстрее во много раз лично для меня.

vue относительно прост, но по сравнению с возьми готовый сниппет и вставь его в html шаблон vue капец как сложный :-). На модекс делают сайты и не совсем програмисты. Просто так сказать менеджеры с пониманием html.

Я вот например тоже иногда делаю не популярные в MODX вещи, и думаете они стреляют? фиг. )))) так что серьезно подумайте с холодным расчётом надо оно вам или нет.

Ну 99% не стреляет. Стреляет если вдруг удалось попасть в нужный момент в нужное место :-)

Если нельзя сделать платную установку, значит надо делать проверку «лицензии» после установки, если её нет — блокировать работу компонента.

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

Поскольку речь идёт о движке, пользователь захочет иметь возможность быстро реализовать какой-то функционал, типа магазина, блога, лэндинга. Возьмём, например, MODX3, я делал на нём сайт визитку, как бы самый простой вариант сайта, для реализации мне понадобились: визуальный редактор, Migx, FormIt, AjaxForm, pdoTools.

Эти пакеты в минимальной конфигурации можно сделать на уровне ядра. Я думаю для допмодулей надо компоненты посложнее делать. А аналоги этих включить в стандартную поставку. Работы много конечно и один я наверно не справлюсь, но это не так уж и много работы. Модулей ноде много и много чего уже реализованно. Все с нуля писать не надо.

Второй момент, если ты делаешь CMS похожую на Modx, то, вероятно, рассчитываешь, что те, кто используют Modx, заинтересуются твоей разработкой, НО у тебя Node.JS, что совсем не то же самое, что PHP, для многих это будет проблемой. Чем твоя CMS будет похожа на Modx?

Я не планирую прям перетягивать с модекс. Я подсел на модекс из-за низкого порога входа. Просто вставляешь в html сниппеты прописываешь им параметры и получаешь нужный функционал. Вот чем охота повторить модекс. Чтобы для того чтобы сделать достаточно функциональный сайт нужно минимум знаний и делается сайт очень быстро. С минишоп2 простой магазин можно развернуть за день. И что еще важно его можно в каких-то пределах легко кастомизировать с минимальными знаниями и можно допиливать функционал постепенно разбираясь что в нем как устроенно изнутри.
То есть, я хочу CMS с более-мение современной начинкой, но чтоб в ней было начать работать также просто как и в модекс. Я хочу привлекать новичков и так же чтоб CMS была удобна для профессионалов.
Правда чтоб вставлять сниппеты в код надо парсить html и чанки, а это медленней чем компоненты реакт или vue. Но в это легче вникнуть чем в vue. То есть, основа CMS html шаблоны и чанки, js сниппеты и модель вариэбле — аналог tv.

А как это может быть монеторизовано. За эксклюзивные блоки и темы оплата?

Сталкивались, но редкость и не понятно откуда ноги растут. Вроде конфиг компонента из сесии не подгружает. Проследите за сесиями. Может они меняются как-то при прогрузке странице одна а при ajax другая. Или что-то другое.

Хм… я как-то ожидал конструктор сайтов как тильда. Установил и блоки натыкал на сайте. Но задача конечно сложная… Вообще даже не тестировал. А привязка конкретно к блогу, интернет-магазину жесткая? Произвольный сайт из блоков можно собрать? Например сообщество MODX или сообщество майнкрафт?

в migx при попытке содать таблицы в базе вылетает ошибка
Fatal error: Class 'xPDOGenerator_mysql' not found in C:\OSPanel\domains\modx3.loc\core\components\migx\model\migx\migxpackagemanager.class.php on line 3

Ага. А вот как мне быть? Мне нужно чтоб класс таблицы я мог указать прямо в параметрах сниппета. То есть имя класса в сниппете есть только в виде переменной строки.

$class = 'ModExtra\Model\ModExtraItem';
$class::class;

Так не работает. Конечно можно использовать eval

$class = 'ModExtra\Model\ModExtraItem';
eval('$class1 ='. $class.'::class;');
if($item = $modx->getObject($class1,1)){
    print_r($item->toArray());
}

Но eval как известно зло. Или Использовать $xpdo->loadClass Но его не изветно когда отрубят.
Так как быть?

Так а что ты проверял? (в обществе вроде по правилам использовать ты)
Я проверяю

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);

$class = 'ModExtra\Model\ModExtraItem';
$class::class;

ошибка: Fatal error: Dynamic class names are not allowed in compile-time ::class fetch in

Работает такой код:

{'!pdoResources' | snippet : [
   'class'=>'ModExtra\Model\ModExtraItem',
   'sortby'=>[
       'ModExtraItem.id'=>'ASC'
   ]
]}

Это работает только не понятно будет ли дальше работать.
\core\components\pdotools\src\Fetch.php вызывает
\core\vendor\xpdo\xpdo\src\xPDO\Om\xPDOQuery.php

public function __construct(& $xpdo, $class, $criteria= null) {
        parent :: __construct($xpdo);
        if ($class= $this->xpdo->loadClass($class)) {
            $this->_class= $class;
            $this->_alias= $this->xpdo->getAlias($this->_class);
            $this->_tableClass = $this->xpdo->getTableClass($this->_class);
            $this->query['from']['tables'][0]= array (
                'table' => $this->xpdo->getTableName($this->_class),
                'alias' => & $this->_alias
            );
            if ($criteria !== null) {
                if (is_object($criteria)) {
                    $this->wrap($criteria);
                }
                else {
                    $this->where($criteria);
                }
            }
        }
    }

\core\vendor\xpdo\xpdo\src\xPDO\xPDO.php

/**
     * Load a class by fully qualified name.
     *
     * The $fqn should in the format:
     *
     *    dir_a.dir_b.dir_c.classname
     *
     * which will translate to:
     *
     *    XPDO_CORE_PATH/om/dir_a/dir_b/dir_c/dbtype/classname.class.php
     *
     * As of xPDO 3.0, the use of loadClass is only necessary to support BC
     * with older xPDO models. Auto-loading in models built with xPDO 3.0 or
     * later makes the use of this method obsolete.
     *
     * @param string $fqn The fully-qualified name of the class to load.
     * @param string $path An optional path to start the search from.
     * @param bool $ignorePkg True if currently loaded packages should be ignored.
     * @param bool $transient True if the class is not a persistent table class.
     *
     * @return string|boolean The actual classname if successful, or false if
     * not.
     * @deprecated since 3.0
     */
    public function loadClass($fqn, $path= '', $ignorePkg= false, $transient= false) {

loadClass вроде deprecated а закомментировал весь блок с if ($class= $this->xpdo->loadClass($class)) { сайт ушел в аут. Чет похоже разработчики MODX3 недодумали :-)

Полчаса проверю все

Черт. Ввязался в обсуждение. Скорее всего не сработает. неймспейс это конструкция языка php а не текстовая переменная. Но чтоб точно сказать придется сейчас модекс 3 ставить пдотулс и модеекстра и пробовать :-(

Возможно. Но тут 1 вопрос имя класса текстовая переменная например

$class = 'MODX\Revolution\modResource'

Как текстовую переменную преобразовать в неймспайс? Просто не нашел этот момент в инете.

use $class

Насколько я понял точно нельзя. А

$class:class

можно?

Я сказал часть функционала не работает и не будет работать. Например попробуйте через новый migx создать пакет и таблицу в базе данных. Когда я тестировал не работало.
А в pdoTools код типа

{'!pdoResource' | snippet : [
   'loadModels'=>'modextra',
   'class'=>'modextraItem',
]}

Работать наверно не будет. У меня сейчас modx3 не установлен и точно сказать не могу работает или нет. Но скорей всего в modx 3.3 такой код не будет работать.

Скорей всего migxdb, pdotools и getTables никогда не смогут нормально работать в MODX3. В MODX3 внесли изменение Перед тем как работать с объектами их необходимо подключить в скрипте через use. Например

use MODX\Revolution\modResource;

Но в MODX REVO можно использовать конструкцию вида

{'!pdoResource' | snippet : [
   'loadModels'=>'modextra',
   'class'=>'modextraItem',
]}

И работать с любой таблицей базы данных. Просто указываешь класс таблицы в настройках сниппета.
Так вот, по идее, чтоб работать с какой-то таблицей в модекс 3 надо прописать вызов ее класса use в начале сниппета. Но это не возможно. Сниппеты и код pdoTools, migx и getTables при запуске кода не знают какой класс им надо подключать. Класс прописан в настройках в виде текста. А в php запустить use какая-то переменная нельзя. Сейсас в MODX 3.0.3 это еще работает, но в MODX 3.3 обещают отключить метод modx->loadClass через который сейчас вызов произвольного класса через текстовую переменную его названия еще работает.

Вообщем существенная для меня часть возможностей migx и pdoTools в MODX3 накроется. Я разбирался в этой теме полгода назад когда хотел перевести getTables на MODX3 и возможно еще что-то не понял. Не судите строго если ошибся. Но по моему для меня переход на MODX3 не имеет смысла. Вроде как часть нужного фуункционала в будущем просто не будет работать.