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

Или в index.php 'msProductData' вместо массива строка

'msProductData' => "require_once 'msproductdata.map.inc.php'",

Какой то не правильный плагин в папке core/components/minishop2/plugins/. Там плагины для расширения полей базы данных минишопа в виде index.php например

<?php
return array(
    'map' => array(
        'msProductData' => require_once 'msproductdata.map.inc.php',
    ),
    'manager' => array(
        'msProductData' => MODX_ASSETS_URL . 'components/minishop2/plugins/myplugin/msproductdata.js',
    ),
);

и msproductdata.map.inc.php

<?php
return array(
    'fields' => array (
		'avaible' => 1,
		'europrice' => 0.0
	  ),
    'fieldMeta' => array (
		'avaible' => 
		array (
		  'dbtype' => 'varchar',
		  'precision' => '50',
		  'phptype' => 'integer',
		  'null' => true,
		),
		'europrice' => 
		array (
		  'dbtype' => 'decimal',
		  'precision' => '12,2',
		  'phptype' => 'float',
		  'null' => true,
		  'default' => 0.0,
		),
    )
    ,'indexes' => array(
.....

наверно index.php присутствует, а файл определенный в строке ниже отсутствует

'map' => array(
        'msProductData' => require_once 'msproductdata.map.inc.php',

то есть для msProductData отсутствует файл msproductdata.map.inc.php.

Возможно в этом причина. Код брал со страницы Плагин товара для miniShop2 MODx Revo

Это предупреждение наверно не из этого чанка галереи. Во первых стоит проверка {if $files?} во вторых если ругается на второй вызов {foreach $files as $file}, то должно ругаться и на первый вызов {foreach $files as $file}.
И, самое главное, в третьих ругается в файле /public_html/core/components/minishop2/model/minishop2/minishop2.class.php на строке 630. То есть чанк вообще не при чем. Посмотрите что есть там у вас в файле minishop2.class.php на строке 630

У меня бывает проблема кеш плагина pdoTools задваивается. Попробуй почистить кеш.

В курсах Василия по Vesp есть интересный движок https://github.com/k-samuel/faceted-search

Ок. Посмотрим на реализацию :-)

Интересно. Обычно вроде в mfilter2 у каждой категории товаров делают свои фильтры. Или если магазин простой, то для всех категорий один фильтр. Автоматическая сборка значений опций поможет сделать таблицу значений опций, но если таблица будет одна для опции и всех категорий, то в фильтр будут попадать значения опций из других категорий. А если для каждой категории и опции своя таблица, то это дофига раздует базу :-).
В фасетном поиске (фильтрации) самая проблема получить список значений опций. Чтоб не было не нужных значений и делалась агрегация(предварительный подсчет кол-ва товаров для значения опции). А сам то поиск штука не хитрая select join where значение опции = 'шина' например и это делается быстро и базу не особо грузит. Насколько я разбирался то, как сделано в мфильтер решение по моему оптимальное (за исключением кеширования) на php. Лучше только будут специализированные сервера Elasticsearch, Sphinx и т.д.
Ну у тебя может получиться что-то интересное, но мне вот сомнительно :-(. Я к тому что ты зря работу не делал. Но если и не получиться то будет опыт :-). Ну посмотрим. Вдруг ты придумаешь что-то сверхестественное ;-)

Привет. Тут немного не понятно. А сами фильтры как формируются? В mfilter2 назначаешь поле и тебе в фильтер вываливаются доступные параметры. А у тебя как? Параметры вручную прописываешь?
В mfilter2 как раз подбор доступных параметров и занимает основное время. Сама фильтрация поиск по запрошенным параметрам это не долго.

Потому что я о нем первый раз слышу :-). Блин… технологии быстро развиваются :-(. Теоритически перескочить на ноду нам возможно за года 3. В принципе сейчас рефракторинг кода нужен и заодно можно попробовать пересесть на другую технологию. Но вот вопрос? Передем мы на ноду, а за это время не появиться какой-нибудь новой технологии, что придется снова весь код переписывать??? Сейчас модно строить приложение как js фронт и апи-сервер. Мне кажется, что это на долго не устареет. И перетянув основную логику приложения на фронт потом можно будет просто менять апи сервер. Но вот не устареет ли эта концепция за 3 года? О_О

Я не угадал с поисковым движком. Ну еще пару ошибок. Но надо было не на опенсеарч делать. Вышло, что из-за сво амасон свои сервера закрыл из россии, а так как опенсеарч требуется как минимум 30гб на диске стоимость VPS в районе 8000р в год получилась. Кстати пробовали запускать поисковый движок на мощном сервере и фасетсеарч работал гораздо быстрее. Так что если бы удалось получить бесплатную лицензию Амазон, то и стоимость была бы гораздо ниже и скорость работы движка выше. Но не сложилось.
Сейчас другой фигней увлекся. В очередной раз изучаю Vue и NodeJs. Хочу на них перейти. Но у нас на модекс за 8 лет кучу всего понатворили и перейти на ноду не реально. Но вот перейти на Vue с jquery в принципе реально. Пытаюсь придумать какой-то микс Vue и MODX. Безумная идея перенести логику сайта с php на js и чтоб модекс выступал только в качестве апи сервера.

Проверь системные настройки 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.

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