Дима Касаткин
С нами с 09 июля 2022; Место в рейтинге пользователей: #8228 минут назад
Денис, напиши пожалуйста, что не использовать на файлы js, а то будет как у меня, 4 часа времени восстанавливать построчно, а так работает без нарекан...
Добавляем функцию HTML Beautify/Prettify в Ace! 10
2 часа назад
Не только цена может измениться, но и товара уже может не быть в наличии.
MiniShop3 - чего ждать в Beta версии. 10
Вчера в 23:10
по моему путь не верный у вас в «snippet.sendcode.php», должен быть такой наверное?
require_once MODX_CORE_PATH . 'components/sendit/services/identi...
[СДЕЛАЙ САМ] Авторизация и регистрация по SMS с помощью SendIt 8
Вчера в 21:49
Блин курсор прям чума :-).
Написал промт
Теперь выбери специфичные для организации ВК24 данные. Запиши их в фай импорта системных настроек для MODX...
Испытание ИИ Cursor 3
Вчера в 21:07
Можно сделать самому по этой инструкции
msOneClick Чекбокс Согласия на обработку данных 1
Вчера в 20:49
Во-первых, radio это переключатель, это означает, что он должен иметь какое-то значение изначально, соответственно и валидация не нужна. Во-вторых, ес...
Как кастомизировать сообщения после Регистрации на сайте? 5
Вчера в 12:05
Нужно проверять метод save в файле assets/components/tickets/js/web/default.js
Там лаг с label id и input id и как раз если убрать из label id, то и ...
Указан неверный код защиты от спама. Tickets, как исправить? 2
Вчера в 11:30
Павел, скрипт у вас просто замечательный! Только одно но, или 2, смотря как считать… Сниппет требует от браузеров пользователей очень много ресурсов и...
[xLike] Идеальная система лайков с оптимистичным интерфейсом и правильной формулой 112
03 декабря 2024, 23:11
Ну планируется что расчеты будут делать клиенты на сайте. А чтоб они не могли приписать себе любую цену товара считать цену надо на стороне сервера. Т...
Плюсы и минусы Vue и gtsAPI 20
Хотел уточнить:
Есть предложение поддерживать Fork, а не плодить компоненты!
У меня даже есть концепт, как отличать компоненты, у нас есть постфикс версии, как правило это -beta или -pl (и даже -pl2 и т.п.). Я анализировал код установщика и не нашел никаких опасных привязок к этим постфиксам.
А значит, мы можем использовать постфикс в стиле:
Scheduler 1.4.1-pl → Scheduler 1.4.1-modx-pro, где modx-pro — github-логин автора форка. Довольно системно получается, и ничего не сломает. Можно использовать и в других компонентах аналогично!
После этого спокойно выпускать новые версии, не оглядываясь на оригинальный пакет. Раз уж там не понятно почему, не принимают PR-ы (вроде этого), из-за чего, полагаю @Николай Савин и не рассматриваешь изначально затащить туда поддержку MODX3 (хоть она и заявлена у оригинального автора).
Что скажете, коллеги?
Есть есть желание работать в таком режиме, посмотри на FrankenPHP worker mode → вроде то, что то описал по поводу переиспользования настроек без похода в базу и т.п… Но по-моему это перебор. Потому что приличные SSD/NVME диски уже давно кладут в память часто используемые данные (это будут файлы кэша), а файловое кэширование в MODX есть по умолчанию — просто используй кэш, когда тебе нужна эта магия :) Какое еще ещё нафиг NodeJS?! Я не говорю, что он плохой, просто говорю что незачем лезть в другую вселенную, чтобы получить хорошие показатели скорости!
P.S. А вот сервер на windows (подсмотрел твоё соседнее собщение) очень даже может быть причиной проблем со скоростью. Там нужен особый тюнинг, для которого не так уж много рецептов. Я встречался с таким, победить не получалось, переезжали.
У меня на проектах по 20-30мс на полный ответ сервера, без какого-то рокет-турбо-тюнинга (а с ним — быстрее, но сейчас не об этом).
Мне пока удаётся в большинстве проектов убегать от этих адских фроентенд-фреймворков. Надеюсь удастся полностью пережить их рассвет, встретить закат, и классно-здорово работать на набирающем популярность (снова) серверном рендеринге технологии HTMX, которая отлично ложится в концепцию того, как работает MODX, с чанками, крутыми шаблонизаторами и т.п.
P.S. Тоже интересно, для чего реально используешь @Александр Туниеков gtsAPI. Задумка интересная. Не переписываешь ли потихоньку всю админку на формы VUE? ))
Спасибо что делишься!
P.S. Поправь плиз отступы в форматировании кода во 3 и 4 блоках, а то я shift+tab чуть не нажал машинально, когда читал :)
Тоже решаю такие квесты регулярно, поэтому позволю себе задать вопрос)
Просто интересно, а ты не пробовал стандартные для Revo планируемые даты публикации прикрутить для этих целей как-то?
Имею в виду перед тем, как решение выработал. Сниппет конечно круче, т.к. он универсальный, один раз поставил, и будет срабатывать каждый год))
Тоже горожу сниппеты, но сейчас подумал, что по-простому кажется можно было типа такого
выводить в шаблоне страницы, а в стандартных полях ресурса (с id=8 из моего примера) ставить планируемую дату публикации, и снятия с публикации, вот эти:
Как думаешь, @Денис Усманов, рабочая это схема для одноразовых событий?
Я же правильно понимаю, что можно не делать одноразовый сниппет, а просто запустить его код через компонент Console или подобный?
И ещё есть вопрос по SEOSuite, пользуясь случаем. Они там решили вопрос с тем, что компонент создаёт большую секцию своих настроек в админке для каждого ресурса? Там эта секция была выше, чем секция с основным контентом (и соответственно с секцией TV-шек, если их системной настройкой `tvs_below_content` перенести тоже на первую вкладку в админке где страницы редактируешь) и из-за этого осложнялось редактирование контента на мой взгляд (SEO-настройки маячили и лишний раз мешались). Помню из-за этого даже кто-то ставил старые версии, SEOtab вроде… и ждали фикса, сообщив разрабам на github. Это пофикшено в свежих SEOsuite?
Возможно у тебя тормозит что-то другое, попробуй поставить debugParser и открыть страницу с параметром &debug=1 из-под админа и кидай сюда таблицу.
P.S. Нормальный такой некропост спустя 10 лет, но в целом почему бы и нет))
UPD: Так на сайте и страницы каталога переключаются по 20секунд. Это надо дебажить уже сам mSearch2 (mFilter2 вернее). Как правило, где-то там в чанке лежит нечто очень медленное…
Проверь плиз заголовок, что-то с ним не так)
Предлагаю допилить вот так: «[ruAgo] Дорабатываем output filter ":ago" на склонения по-русски»
Есть ряд вопросов перед стартом:
Планировщик встроенный, или интеграция с компонентом scheduler? Нужен cron или на хитах? Если второе (без cron-а), то настройки увеличения количества хитов в промежутках между запусками для сайтов с большой посещаемостью есть?))
А картинки-видео из TV нестандартных типов (image+ например) поддерживаются? А галереи на MIGX?
Можно привести текст из этого файла readme.txt здесь хотя бы?
Не всегда под рукой есть тестовый сайт ведь!
НО! Если у тебя и правда из двух установленных MODX в разных папках, у которых в core/config/config.inc.php указана одна и та же база с одинаковым значением $table_prefix — то я не знаю что тебе посоветовать, кроме как не пользоваться одной из папок, а настроить работу поддоменов через контексты, как указал выше.
Дело в том, что в MODX используется файловый кэш, в т.ч. системных настроек и т.п. В момент, когда ты очищаешь кэш, он удаляется и папки core/cache/* и как раз из-за этого могут быть проблемы. Наверное, если отключить вообще весь кэш, то всё будет работать, а почему бы и нет (в познавательных-то целях). Данные все в БД. Отключай короче все кэши, чтобы ничего не записывалось на диск, а всё было в Базе Данных… Но опять же, всякие фотографии, скрипты и стили для фронтенда, они же лежат на диске. При установке любого компонента, его файлы кладутся в папку с установленным MODX, а информация записывается в БД. Из другой папки будет видно инфу, а файлов нет — скорее всего будут ошибки.
Предполагаю, что комфортная работа не возможна в таких случаях. Но не уверен, возможно в кейсах, когда выносится core из корневой папки, можно использовать его в нескольких установках, но так я ни разу не делал, а в MODX3 такую возможность убрали, так что уже и не представится возможности.
Короче, используй 1 установленный движок, и контексты :)
У каждого контекста свои настройки, их можно использовать в шаблоне (те же контакты в шапке и т.п.).
Бонусом получишь обновление движка и пакетов на оба сайта, 1 раз вместо двух создашь любимые TV (обложка для страницы или галерея), 1 раз купишь платный компонент и так далее. На мой взгляд например, совсем не дичь, для этого (в числе прочего) контексты и придуманы в MODX!..
Создай второй контекст, создай плагин (в элементах в админке) назови например ContextSwitch и подключи его на OnHandleRequest вот код:
Далее в новом контексте укажи настройку (правый клик в админке → редактировать контекст) и добавь туда 2 системные настройки:
1. site_start (укажи id страницы в новом контексте, её нужно там создать и опубликовать) и это будет главная страница!
2. http_host (полный адрес url без https и слешей, например sub.example.com)
И всё должно заработать!
Обновляйте на крайнюю версию в пределах своей мажорной ветки (ну и с большой аккуратностью и обязательным бекапом — с 2.х на 3.х), несовместимость обработчика изображений с PHP7 исправили в MODX 2.8.7 и в 3.0.5!
Вот я форкнул один из пакетов, хочу подправить код и собрать новую версию для теста. Предполагается что я всё это заливаю в корень установленного MODX. Папка _build сразу содержит установочные скрипты, из-за чего я не могу использовать готовую установку MODX, где поддерживаю другие пакеты.
Вот этот путь /Extras/ModxExtraName/ откуда берется? Корень / перед /Extras/ где смонтирован? У меня это примерно так на хостинге /home/user/data/www/modx.test.ru/ и вот отсюда уже идут ...modx.test.ru/_build/ и так далее.
Давайте в билдерах в папку ./_build/ вкладывать ещё подпапку с названием пакета
Сейчас структура папок:
./_build/build.config.php
./_build/…
./core/components/ModxExtraName/…
./assets/components/ModxExtraName/…
Предлагаю делать так:
./_build/ModxExtraName/build.config.php
./_build/ModxExtraName/…
./core/components/ModxExtraName/…
./assets/components/ModxExtraName/…
Это позволит не вычищать каждый раз _build перезаливкой другого пакета. Ведь организовать подпапку — это логично и красиво.
И даже не обязательно использовать modx-build-environment-gui, он просто сканирует папку _build, парсит версии для сборки и даёт список ссылок (гордо именуемый тем самым GUI), чтобы поменьше клавиатуру пальцами полировать :) но сам ничего больше и не делает. Даже ссылку на скачивание собранного транспортника уже выдаёт билдер самого пакета, если поддерживает согласно инструкции…
В общем так или иначе, круто что наконец мы добрались улучшать Developer Expierence! Чем проще создавать и поддерживать компоненты, тем лучше для экосистемы, и для сайтов, которые на поддержке, и для наших нервов ;)
P.S. Может перенести в заметки и раскрыть тему, есть желающие? Ставьте лайк, если интересно :)
Ну это к слову… А теперь к твоей теме: я сам на windows работаю, и докер локально не использую, но изучаю тему и поюзываю на серверах (как минимум потому что иногда другого не предлагается...). И вот читаю конфиги твои и есть вопрос: а почему ты не монтируешь в локальную папку директорию _build? Тебе же не только правки в код вносить, но и собрать надо пакет, или другой у тебя workflow?