Іван Клімчук

Я против подобного парсинга и решания за других.

Пока сложно сказать.
Пока в планах слить ветку 2 в ветку 3 (начал это делать, но там конфликты в 500+ файлах, задача не из простых), чтобы можно было уже спокойно переключиться на 3 версию. Следом перевести те PR, чтобы были сделаны для 2 версии, на 3, обновить и поправить конфликты в существующих PR. После этого в принципе можно пробовать делать новую тестовую версию.
Работы, учитывая количество активных участников, примерно на месяц, но так как впереди праздники, скорее всего что-то рабочее будет уже после нового года. Но может и раньше, если найдутся свободные руки с непреодолимым желанием помочь кодом.

Я так понимаю, это только в случае с русским языком (возможно и еще с каким-то с длинными строками)?

То, что в самом MODX — исправлено частично, но большинство ошибок в допах, где используется устаревший способ задания меню через указание action id. Помечать их как deprecated следовало сильно раньше, конечно. Но MODX 3 клюет в задницу. Ну и я не знаю, кого ты имеешь ввиду под «они».

Ну и подробно обо всем Марк уже написал — www.markhamstra.com/modx/2018/deprecated-notices-in-modx-2.7/

В родной теме все ок, глянул сейчас, так что стоит проверить кастомные стили.

Какие у вас есть вопросы? Я один из тех немногих, кому не лень этим заниматься.

Потому что иначе никто не будет шевелиться, и когда эти функции реально будут удалены, воплей и поломаных сайтов будет больше. Цель — заставить авторов дополнений исправить свой код. Ну и предупредить разработчиков сайтов, если они использовали что-то старое. Вообще так делается всегда, даже в самом PHP если вызвать депрекейтед функцию, будет валиться warning.
Т.е. это не для тестов, а для реальной жизни. Вася вон ms2 уже исправил.

Нет, это можно отключить в настройке log_deprecated

Там есть нюансы в зависимости от браузера. Или даже проблема в реализации Javascript. По неведомой причине событие onclick не содержит нужной информации, чтобы правильно обработать клик средней кнопкой. Саму логику улучшили, но не польностью. Там в самом PR есть детали, ссыку на него выше Вася запостил.

Добавить еще один Join с той же таблицей, только использовать другое имя в запросах (2 параметр метода innerJoin)

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

Меня всегда в таких сиутация выручает golang (https://golang.org/project/). Требует некоторого времени на изучение (хотя он простой как топор для таких задач), но с легкостью переваривает файлы и по 6 гигов.

@EVAL уже выпилен в 3.x, к слову, но совет «включать голову» актуален всегда.

Что мешает сделать так?
dev.site.ru — основной тестовый сайт.
dev.i.site.ru — сайт первого разработчика.
dev.a.site.ru — сайт второго разработчика.

В разделе Помощь modstore все же понятно написано

Также мы поддерживаем работу дополнений на поддомене dev. Сбрасывать ключ для такого домена не нужно — дополнения просто работают сразу на обоих доменах: site.ru и dev.site.ru.

Касательно моего подхода, у меня код сайта упаковывается в пакет (или несколько пакетов) и ставится через репозиторий. Вся работа локально, потом сборка, отправка в репозиторий, установка на продакшене.

Вероятно проблема в порядке вызова парсера. Стоит, в таком случае, посмотреть в сторону своего снипета, где вызвать $modx->lexicon() с необходимыми параметрами.

Ну так сразу так и писали бы, а то «как в конструкцию [[%key? &namespace=`sitename`]] вставить TV-параметр» звучит совсем не так, как ваш теперешний комментарий.

В таком случае

[[%[[*tv-name]]? &namespace=`sitename`]]

должно работать. Но, стоит проверить, действительно ли [[*tv-name]] что-то выводит на страницу или нет. Второй момент, лексиконы имеют свойство «очень сильно» кешироваться, поэтому стоит убедиться, что кеш сброшен после изменений в лексиконах. В третьих, стоит убедиться что выбран правильный язык и значение лексикона для языка существует.

Не быстрее, а проще. В том плане, что все элементы, включая куски кода, были реализованы через xPDO, где элементы пол умолчанию хранятся в БД. Удобство было в том, что рядом с кодом можно было хранить и все его метаданные, т.е. название, описание, всякие связанные property sets и прочее. В том же October это вынесли в мета-заголовки в сами файлы, что выглядит просто ужасно, когда в одном файле мешанина из yaml, html и php.

На деле уже мало кому интересно. Хорошие технические статьи никто не читает, сразу бегут в вопросы спрашивать, а как вот тут кнопку из синей красной сделать. Или вот украл пакет с modstore, помогите его настроить, а то доку читать влом, за поддержку платить жаба душит всю жизни и прочее подобное :)

[[%key? &placeholder=`[[*tv-name]]`]]

при условии, что в самом строке лексикона есть плейсхолдер вида

[[+placeholder]]

т.е.

'Тут будет выведено вот это значение TV [[+placeholder]]'