Александр Мельник

наверное вы об этой странице
telq.org/question/6200fe05b2d5debe9ebb509c
но тут наоборот посоветовали изменить скобки у фенома.
Не знаю возможно ли это, но такое себе решение.

Да, это далеко не самый плохой вариант, спасибо.

100 процентов. Если добавить var_dump($apsettings) в сниппете после получения данных, то они распечатаются как положено.

я имел ввиду, что использование collections или же «настройки форм» позволяет назначать создаваемым ресурсам корректные шаблоны. Тоесть если создает менеджер ресурс. Кликнула правой кнопкой мыши по Услуги и выбирает — создать ресурс, то при создании ему автоматически будет добавлен шаблон — Услуга. А мой плагин уже ориентируется на этот шаблон и понимает из какого вспомогательного ресурса (те что на скрине внутри 48) ему нужно забрать содержимое blocklist и скопировать его в создаваемый ресурс.

У меня работает следующим образом.
Смотрим скриншот.

Есть тв поле blocklist которое содержит в себе перечень всех возможных на сайте блоков. Под блоком я понимаю — название, указание на чанк в котором вьюшка и прочая инфа.
В ресурсе «Настройки (2)» перед началом работы с сайтом я заполняю это поле, причем заполняю максимально, тоесть все все блоки которые есть на данный момент.
Чтобы менеджеру было проще, а система в целом была гибче, есть еще группа ресурсов, на скрине это ресурсы в родителе «Настройка шаблонов (48)». Эти ресурсы уже отвечают за какой-то определенный тип страниц. Здесь я тоже перед началом работы создаю все все блоки, НО ненужные деактивирую, сортирую блоки, так чтобы они соответствовали макету этой страницы. Ну к примеру если это услуга, то я деактивирую все, кроме блоков
— хлебные крошки
— h1
— баннер
— текстовое поле
— форма заказа
— ссылка назад
Что происходит далее. Я через инструмент «Настройка форм» и через компонент «Collections» стараюсь максимально автоматизировать правильное применение шаблонов, когда менеджер создает новый ресурс.
И вот уже при создании нового ресурса срабатывает плагин, который просто наполняет этот новый ресурс блоками (заполняет тв поле blocklist). Если плагин видит, что создается ресурс с шаблоном 8 (к примеру это услуги) то он скопирует этот список с ресурса 56, где уже настроены блоки для услуг. Если не можем понять, какую именно страницу создает менеджер, то будет скопирован список блоков со страницы «Настройки», тоесть полный список и менеджер сам потом деактивирвует ненужное, расставит блоки в нужной очередности.
В итоге получается, что менеджер может:
— быстро создать страницу с уже заранее продуманными блоками под нее
— после создания изменить страницу как угодно, ведь скопировались абсолютно все блоки, просто они деактивированы. Ничто не мешает конкретно эту страницы «услуги» сделать совершенно другой и активировать на ней блок «слайдер» и блок «дополнительная форма обратной связи».
— изменить в какой-то момент настройки (перечень активных блоков) для тех же услуг (если смотреть на скрин то изменить блоки в ресурсе 53) и все создаваемые после этого страницы тоже изменятся.
Сам плагин очень примитивен.

<?php
switch ($modx->event->name) { 
    case 'OnDocFormSave':
        $template = $resource->get('template');
        switch ($template) {
            case '3': // продукция
                $example = 49;
                break;
            case '8': // услуги
                $example = 53;
                break;
            case '7': //новость
                $example = 56;
                break;
                      
            case '9': // типовые решения
                $example = 55;
                break;
                
            case '4': // инфо страница
                $example = 57;
                break;
                 
            case '19': // акции
                $example = 62;
                break;
            case '21': // реализованные проекты
                $example = 54;
                break;
            default:
            $example = 2;
                break;
        }

        if ( $resource->get('id')!=2 and $mode == 'new') {
           
            $where = array(
                'contentid' => $example
              , 'tmplvarid' => 3
            );
        $tv = $modx->getObject('modTemplateVarResource', $where);
        $value=  $tv->get('value');
           
            $resource->setTVValue('blockList', $value);
        }
        
    break;
}

спасибо, что находите время и силы на улучшения. Это круто и заслуживает уважения.

Я опять немного пофилософствую. Мне кажется, что у компонентов, которые представлены на modx.pro есть одна практически общая проблема. И проблема эта звучит так — по описанию компонента практически невозможно догадаться для чего он и какую задачу можно с его помощью решить.

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

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

Может я один такой глупый, но прочитав 5 раз описание customExtra я так и не понял что он делает. И может это именно то, что я бы хотел, но из-за сжатых, странных формулировок в описании я пройду мимо и не куплю, просто потому что не пойму зачем этот компонент.

modstore.pro/packages/utilities/customextra
Под самым название компонента видим — Дополнительная табличка в админке MODX. Уже честно говоря сбивает с толку, потому что не понятное слово «табличка» еще и в уменьшительно ласкательном варианте. Это про таблицы в базе данных? Это про таблицы генерируемые extjs? Что за «табличка..»
Ниже по тексту читаем

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

Снова ступор. Ведь выше написано, что это для создания дополнительных (тоесть новых ) табличек, а это предложение говорит «кастомизировать» (то есть изменить существующую.)
И ниже идут скриншоты, простите но очень невнятные, на которых предлагается создать какой- то предмет. Что за предмет, не известно.

В итоге, дочитав описание до конца, я все еще остаюсь в состоянии полного непонимания, что же конкретно делает и какие задачи этот компонент решает.

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

По крайней мере для моего мозга справедливо все то, что я описал) Возможно другие люди прекрасно понимают такие вот краткие и сумбурные описания.

Можно я поразмышляю вслух? Это не вопрос к автору поста и речь не о конкретно minishop, а просто так — подискутировать с утра.
Что заставляет нас устанавливать обновления?
Мифическая вера в то, что каждая свежая версия программного обеспечения «лучше» предыдущей?
Но так ли это на самом деле? Справедливо ли это для любого программного обеспечения? Как оценить плюсы и минусы обновления? Что правильнее?
1) каждый раз все обновлять и тем самым сильно увеличивать риск возникновения сбоев в своем продукте (ведь по сути если наш код зависит от чьих-то сторонних компонентов, то мы обязаны просто «верить», что разработчик выпуская новую версию исправил в ней больше багов чем добавил).
2) Или же единожды собрав стабильную систему (пусть и из сторонних компонентов) и тестами и временем убедившись, что именно эти версии компонентов хорошо работают в связке друг с другом, оставить систему в таком стабильном состоянии и ничего не обновлять? Ведь «лучшее это враг хорошего», как говорит народная мудрость и попытке улучшить то что и так работает хорошо, скорее всего приведет к тому, что все станет работать плохо.

А теперь просто о моем личном опыте, хотя это совершенно не показатель что такой подход правильный.
Начну с операционной системы. Я на всех своих устройствах пользуюсь линуксом на базе debian. Это и сервера и мои копмьютеры. Эти дистрибутивы разрабатываются очень крутой компанией canonical, новые версии выходят каждые 6 месяцев. И даже при условии, что разработкой занимаются профи, есди скачать релиз в день его выхода — он будет полон глюков. У людей 6 месяцев на доработку и тесты, люди профи и все равно в релизе много багов. Только через пару месяцев его уже можно скачать и кайфовать.
Если говорить про modx. Из многих десятков сайтов, которые у нас есть, 80 процентов работает на modx 2.65 и прекрасно выполняет свои функции. Да, разрабатывая новый сайт, я беру самые последние версии компонентов. Но сделав один раз продукт, который показывает свою стабильность и полностью устраивает и меня и заказчика — я не вижу смысла что то в нем менять. Каждый раз, когда я пытаюсь что то обновить, возникают те или иные проблемы. И хорошо если этот баг сразу виден, например сайт полностью упал, но куда страшнее баги, которые не столь очевидны и вылазят спустя месяц после обновления. Да, я даже соглашусь, что такие баги при обновлении скорее всего говорят о моем невысоком уровне знаний (хотя исходники компонентов я никогда не правлю), но факт остается фактом, чем меньше я обновляю — тем стабильнее наши проекты. Такой вот парадокс.

просите Дмитрий, но я уже даже не помню, чем закончилась эта задача. Три долгих года прошло.

Может что то такое подойдет.

ваши страницы станут открываться в разы или десятки раз медленнее. Особенно если это какая то категория товаров и отображается 60 товаров и нужно в реальном времени «наложить» 60 водяных знаков. Обновили страницу — и все по новой, снова накладываем 60 водяных знаков.

Задача заключается в том, чтобы сделать так, чтобы при клике на корзинку в мобильной версии, выезжало это боковое меню сразу с развернутыми, добавленными товарами, а не пустым. Это ж не логично.

но зачем вы тогда используете подгрузку содержимого корзины по клику?
Я вижу несколько вариантов решения.
1) на странице не должно быть отдельно блоков для мобильного и отдельно для десктопа. [[HeaderDesktop]], [[HeaderMobile]] это плохая практика. Внешний вид должен адаптироваться под разные устройства за счет каскадных стилей и медиа запросов, а не за счет скрытия блоков для десктопа и отображения блоков для мобильных. В таком случае и корзина у вас всегда будет существовать на странице, потому что шапка остается всегда одной и той же.
2) Я вижу что у вас используется скорее всего какой то готовый шаблон интернет магазина, взятый с бескрайних просторов интернета, а значит переверстывать никто не будет. Тогда действительно придется иметь два разных чанка для шапки, в каждом полноценно вызывать [[!msMiniCart?&tpl=`miniCart`]], а не подгружать по клику, НО решать какой из чанков показать вам нужно еще на уровне обработки запроса на сервере. Помоему для modx даже была какой-то сниппет типа MobileDetect или как то так, который позволяет определить с какого устройства пришел запрос.

Юрий, вы всегда можете посмотреть, что содержит в себе та или иная переменная в феном, распечатав ее при помощи модификатора print {$delivery|print}
Наверняка там содержится и поле id и вы можете сделать как написал выше Артур.
Синтаксис шаблонизатора феном можно посмотреть тут github.com/fenom-template/fenom/tree/master/docs/ru

Вы хотите чтобы ваш сниппет оперировал информацией, которую получает с формы.
Формы могут отправлять данные используя два метода http запросов — POST и GET
Следовательно вам нужно разместить на одной странице и форму и ваш сниппет.
Далее псевдо код, который не рассматривает вопросы безопасности.

<form method=post action=this page>
<input name=id>
<button>
</form>

[[snippet]]
if $_POST[id] {
sql = SELECT * FROM table WHERE id=$_POST[id]
get data by sql;
}

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

по нескольким урлам надо открывать один и от же ресурс?

я лично уже запутался, о чем спрашивал автор статьи и на что мы ищем ответ.
Автор говорит

Ситуация — часть товаров выводятся в разных категориях.

насколько я понимаю, речь идет о том, что один товар minishop создан в одной категории, а в другие расставлен при помощи галочек. Но в таком случае, урл товара всегда одинаков ведь, разве нет? Не важно откуда мы на него перейдем, из основной категории или из виртуальной, урд товара будет один и тот же.

Я хочу создать простой отчет с фильтром в менеджере

Что это значит? Вы хотите внутри человека менеджера запихнуть фильтр и бумажный отчет? Это жестоко.
Но если без иронии, то тоже не понятно. Что в вашем понимании «отчет». Отчет чего или кого. Причем тут фильтр?

А ответ Артура следует понимать так — создать что либо в админ панели довольно сложно, вам нужно как минимум хорошо знать сам modx и фреймворк extjs который отвечает за отрисовку интерфейса. Поэтому гораздо проще создать в админке просто ресурс, но снять галочку — опубликован. Внутри этого ресурса, вставляйте какие угодно самописные (или нет) сниппеты, которые создадут нужную вам логику. Такую страницу можно открыть по урлу как любую другую, но изза того, что она неопубликована, видите ее только вы, предварительно авторизовавшись в админке.

мне кажется, раз вы предварительно уточняли у разработчика компонента seofilter и купили его — вам нужно ему и писать в техподдержку.
уверен, что тот код который у вас приведен выше, вам не пригодится больше для вывода товаров.
ну и в целом, фильтровать что то у вас будет или невозможно или очень сложно.
Ваши значения заполняются вручную, в одном поле храниться как величина (10) так и единица измерения (кг), менеджер может в одном месте написать 3.4, а в другом 3,4 и так далее.
Мой совет — переделайте сайт используя минишоп и избавьтесь от характеристик на migx/
Это будет быстрее и правильнее.

время ответа сервера не идеально, но не критично.
Я использую такую блочную систему только если руководство требует ручного управления блоками на странице. Это нужно далеко не везде, чаще всего макеты страниц статичны.

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