Wassi Wassinen

Wassi Wassinen

С нами с 25 января 2013; Место в рейтинге пользователей: #39
06 января 2022, 16:18
0
Согласен со всем, кроме этого:
… MODx не простой, т.к. для того чтобы собрать сайтец нужно как минимум уметь писать сниппеты, хотя бы самые простые на modParser.
Есть несколько «сложных проектов» (структурно и функционально) собранных без написания сниппетов и без знания программирования. Использовали только готовые компоненты из modstore.
В остальном — полностью согласен.
06 января 2022, 11:49
+2
modx.pro/components/22537#comment-131710

Инструмент потрясающий. Ощущение, что пишешь на Laravel. Теперь вся жизнь в файлах и коде. Я уж забывать начинаю как админка выглядит.
Не воспринимайте как критику. Просто мысли вслух. Автору дополнения — искреннее уважение.

ZoomX — штука, безусловно, интересная :)
Но, на мой взгляд, уводит MODx от концепции более-менее простой и универсальной CMF к сложному «недофреймворку». Вместо того, чтобы менять сам MODx и делать его более быстрым, удобным и понятным большинству, я вижу тенденцию к уходу в доработку надстройками. Такие надстройки (так как их делают программисты для себя и других программистов) делают MODx более сложным.
Уникальность MODx как раз в простой и удобной админке, в простом создании ресурсов, отображении их в виде понятного дерева с понятным редактированием этих ресурсов из админки. Доступ к шаблону из самого ресурса. Система сама заботится о создании ссылок, их формировании и т.д. Простые дополнения, позволяют вывести меню, ресурсы, добавить форму, создать простой магазин и проч. Все это просто понять и применять новичкам.

С приходом таких дополнений, как ZoomX, нужно прописывать роуты, а создание ресурса превращается в написание кода. Это вряд ли привлечёт большое количество новичков в MODx (именно эта категория пользователей даёт популярность таким проектам, как Wordpress).
Если же есть задача привлечения опытных программистов — всё ещё не понятно, зачем пользоваться этим в связке с MODx, а не Laravel, Flask и другими адекватными «тру» фреймворками, в которых всё для опытного разработчика уже есть из коробки.

В любом случае — автор молодец, что посвящает этому время.
15 декабря 2021, 04:18
0
Сергей, спасибо за ответ.

Самая главная беда — мы видим ошибки в общем логе MODx, но не знаем на какой странице сайта они вылезли. :) Поэтому, чаще всего, выявление ошибок происходит с помощью визуального осмотра сайта. Мы включаем дебаг и ползаем по страницам в поисках этой ошибки.

Приведу один из примеров: есть сложная страница с несколькими «вкладками». Вкладки не разбиты на отдельные страницы, а свёрстаны как вкладки с помощью css-фреймворка. На каждую вкладку выводятся ресурсы с помощью pdoPage со своими отборами для каждой вкладки.
Например, мы видим что страница «поехала» — что-то отображается не правильно.
Как это работало в предыдущих версиях — мы видим дебаг под каждым сниппетом и понимаем, какой из них отрабатывает с ошибкой. Например, я добавил showLog=1 для всех сниппетов и на каждой вкладке (или под каждым местом, где должен быть вывод сниппета) вижу свой дебаг. Сразу понимаю, какой из сниппетов отработал неправильно.

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

Возможно, я ошибаюсь и все привыкли действовать по-другому. Можно добавить возможность указать плейсхолдер для вывода дебага, а если он не указан — выводить единым плейсхолдером. Если через пару версий выяснится, что этим никто не пользуется — значит я был не прав и эту возможность можно будет исключить.

Еще раз спасибо, что откликнулись на предложение с позитивом.
13 декабря 2021, 20:04
+4
@Сергей Шлоков, прежде всего, хочется сказать, что вы и другие разработчики — молодцы.

Небольшое пожелание.
Если есть такая возможность — сделайте вариативным плейсхолдер для лога. На многих проектах на одной странице может быть, например, несколько pdoMenu. Как я понимаю, в таком варианте все логи сольются в единую портянку и это будет крайне не удобно. Добавьте возможность указать имя плейсхолдера, в который будем выгружать лог.

Заранее благодарен.
12 февраля 2021, 03:06
0
Спам дизлайками решается простым отображением при наведении на лайк\дизлайк тех, кто лайкал и тех, кто дизлайкал. Такой накруткой часто страдают, если есть ощущение анонимности.
12 февраля 2021, 03:04
0
Интересная идея. А раздел «Вопросы» спамить в отдельный канал. Чтобы основной не забивался. Как вариант.
09 декабря 2020, 10:35
0
Владимир, приветствую.
Удалось написать сниппет для вывода данных VersionX на фронтенд?
12 апреля 2020, 16:20
0
Я первым делом попробовал вариант «a»:{«title»:"#text",«href»:"#text"}. Но не помогло. И в логах стали сыпаться ошибки парсера Fenom.
Помог вариант с произвольным значением фильтра.
11 апреля 2020, 21:24
0
Для тех, кто будет искать решение проблемы: тикетс вырезает из контента ссылки с тегами MODx вида [[~88]] (даже при активной «галке» «Выполнять теги MODx»).

Решение такое:
В «Наборах параметров» ( joxi.ru/Q2KYEYPILob0Lr ) для Тикетов заменить в cfgAllowTagParams:
Это
"a":["title","href"]
заменить на
"a":{"title":"#text","href":"#skip"}
Спасибо @tolanych за подсказку.
10 апреля 2020, 21:36
0
Спасибо, Сергей. Пробую общаться. :)

Я тебе за прошлый раз «спасибо» не отправил. Куда удобнее?
10 апреля 2020, 20:11
0
Ты как проверял? Я создал тестовый сайт на модхост — там такая же проблема.

s22021.h10.modhost.pro
login: s22021
pass: rPzsAiaKbm7F
10 апреля 2020, 19:58
0
Нет, готовая выводится нормально.
10 апреля 2020, 19:49
0
На новом тестовом сайте та же история.
10 апреля 2020, 19:49
0
Проверял. Отключал этот и другие параметры. Даже стал баловаться вот такими вещами:

Ставлю галку «Выполнять теги MODx». Если отключаю Jevix — всё выводит без проблем. Но не хотелось бы совсем отключать Jevix. Пробую добавить исключение для содержимого href. Делаю это таким образом:
Вставляю это в наборе параметров Tickets (cfgAllowTagParams)
"a":{"title","href":["#text"]}
Но Jevix начинает ругаться в логах таким образом:
[2020-04-10 15:21:31] (ERROR @ /core/components/jevix/model/jevix.class.php : 118) PHP warning: Invalid argument supplied for foreach()
10 апреля 2020, 17:11
0
Ещё один вопрос, Василий. Я пытаюсь разрешить в Jevix вывод тегов MODx из контента Тикета. Если конкретнее, то в админке в контенте Тикета проставляю плейсхолдеры вида [[~88]] в ссылку.

Ставлю галку «Выполнять теги MODx». Если отключаю Jevix — всё выводит без проблем. Но не хотелось бы совсем отключать Jevix. Пробую добавить исключение для содержимого href. Делаю это таким образом:
Вставляю это в наборе параметров Tickets (cfgAllowTagParams)
"a":{"title","href":["#text"]}
.
Но Jevix начинает ругаться в логах таким образом:
[2020-04-10 15:21:31] (ERROR @ /core/components/jevix/model/jevix.class.php : 118) PHP warning: Invalid argument supplied for foreach()
Что я неправильно делаю?
10 апреля 2020, 17:04
0
Да, если отключить — всё работает.
10 апреля 2020, 13:22
0
Сергей, привет.
Если есть возможность, помоги разобраться с ещё одной проблемой. Почему-то Jevix вырезает из контента тикета ссылки, в которые я проставляю плейсхолдеры Modx вида [[~88]]. Хотя в самом тикете ставлю галку «Выполнять теги MODx».
01 апреля 2020, 16:58
0
Спасибо за ответ. На самом деле, как только я меняю значение набора параметров и вызываю контент через сниппет Jevix — на старых и новых тикетах всё сбрасывается.
01 апреля 2020, 16:57
0
Сергей, благодарю!
31 марта 2020, 16:39
0
В моём случае не решает проблему.
Спасибо, что ответили.