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

Спасибо, буду экспериментировать)

Если я создаю просто html страницу (вне modx, но на том же сервере, с теми же настройками кеширования, сжатия и прочего) и в ней подключу файл js через script
И буду изменять имя этого файла или же изменять его версию 97.1 — 97.2

<script src="assets/a7/js/park.js?v=97.1"></script>

То браузер получит в html всегда корректную версию, поймет что такого файла нет в его кеше и отправит запрос на получение нового скрипта. Все как и ожидается. Нет необходимости ctl+f5 нажимать.
Но если точно такая же страница создается в modx, то html страницы не изменяется, и соответственно браузер и не знает, что версия js файла изменилась и берет из кеша. Мне кажется причина все же в кешировании самого modx. Тот статичный чанк

{include 'scripts.tpl'}

как то кешируется. И я не знаю способа предотвратить это.

Сами делали сайт или приобрели готовый?
Я сталкивался с тем, что приобретаю готовый сайт, устанавливаю его и потом нужно написать разработчику, дать доступы в админку, чтобы он отключил свою «защиту».
Уверен ее можно взломать, но лениво, тем более что сайты покупаются официально.
Думаю и вам достался такой вариант.

На всякий случай скрин системных настроек кеширования.

Выглядит хорошо и вам спасибо за такое детальное видео да еще и со звуком (очень не люблю видео где в тишине автор что то делает и считает что раз ему понятно то и всем остальным тоже).
Насколько я понял это не есть логирование ошибок? Раз нужно самим вызывать функцию ray и ей передавать данные то в этот лог не попадут ошибки php, mysql сервера, nginx? Тоесть это просто красивый и удобный var_dump?
Плюс, насколько я понимаю, воспользоваться можно только при локальной разработке ну или же если сайт находится на выделенном сервере и вы уверенный администратор линукса (разрешить работу нестандартного порта в firewall, настроить nginx на проксирование и прочее). Потому что если modx работает на каком то обычном виртуальном хостинге то там нет докера, установить его нельзя, да и плюс хостер не позволит открывать нестандартные порты.

ничего удивительного, поверьте. Я бы свои знания в modx оценил бы в 20 процентов из 100 возможных)

Спасибо. торможу.

Спасибо большое. Нужная вещь. Когда вы только время находите.

Не знаю почему, Василий, но у меня не работает тег {ignore} почти никогда.
Часто в шаблон нужно добавить какой то сторонний скрипт, например от яндекс метрики, который тоже конфликтует. И никогда оборачивание в {ignore} не помогало, только вручную проставить пробелы.
И в случае с vue тоже не помогло.

Пока решил пользоваться глобальными компонентами vue, описывая их все в одном файле, а в шаблон вставлять только

<park-list v-for="item in park" v-bind:car="item" v-bind:key="item.id"></park-list>

признаюсь, не знал что существует метод setPlaceholderS, всегда пользовался setPlaceholder, но конкретно в моем случае это проблему не решает.
Если я выставляю (неважно как) плейсхолдеры внутри сниппета, то ниже по коду я никак не могу получить их используя феном, только через [[+placeholder_name]]
Если же я в шаблоне выставлю плейсхолдер не внутри сниппета а вот так

{$_modx->setPlaceholder('name','value')}

то такой плейсхолдер легко ловится на феноме

{set $my_placeholder = $_modx->getPlaceholder('name')}

спасибо. Мне как дилетанту очень многое в вашем тексте не знакомо. Про то что во vue есть какие то виджеты — слышу впервые.

наверное вы об этой странице
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 и прекрасно выполняет свои функции. Да, разрабатывая новый сайт, я беру самые последние версии компонентов. Но сделав один раз продукт, который показывает свою стабильность и полностью устраивает и меня и заказчика — я не вижу смысла что то в нем менять. Каждый раз, когда я пытаюсь что то обновить, возникают те или иные проблемы. И хорошо если этот баг сразу виден, например сайт полностью упал, но куда страшнее баги, которые не столь очевидны и вылазят спустя месяц после обновления. Да, я даже соглашусь, что такие баги при обновлении скорее всего говорят о моем невысоком уровне знаний (хотя исходники компонентов я никогда не правлю), но факт остается фактом, чем меньше я обновляю — тем стабильнее наши проекты. Такой вот парадокс.

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