{set $content = ($_modx->resource.content | replace : '<table':'<div class="table-responsive"><table') | replace : '</table>':'</table></div>'}
{$content}

Здравствуйте, про редакторы не подскажу, но можно же сайте отлавливать table и их через js обертывать в div (как я понял, это для адаптивации таблиц).

Спасибо, не догадался

Используй параметр ajaxTplMore. Перепиши его так, чтобы внутри был nav-wrapper

Дима, ты всё перепутал.

В MODX 3 старый «стабильный» менеджер пакетов приводит к возможности добавить в систему конфликтующие дополнения. Как с самой системой, так и друг с другом.

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

Перечитай еще раз, если не понял, о чём я пишу.

Установил — проверил. Прекрасно работает.

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

У Formit такой возможности кажется нет, но уточнить можно, вычитав его код, который отвечает за отправку. Там используется modPHPmailer, который основан на PHPmailer, который в свою учередь почти наверняка умеет подписывать письма с помощью DKIM!

Если этот путь никуда не приведет, придется тебе отказаться от стандартного способа отправки и написать свой небольшой хук (это не сложно, просто сниппет создаешь в котором уже будут заполненны в переменных данные из твоей формы вот документация с примерами), для отправки почты. Тогда, возможно, тебе пригодится знать, что существует modSwiftMailer и возможность отправлять письма с помощью modHelpers. Ну или в своём хуке подключи библиотеку, отправляющую код из PHP с поддержкой DKIM.

Пожалуйста, @Валерий если сможешь подписать письмо без внешнего SMTP, поделись решением! А то недавно Яндекс.Почта, которую последние лет 10 многие использовали как внешний SMTP для отправки писем, отключила бесплатный тариф, и вопрос с почтой стал очень актуальным :))

Если будут вопросы по ходу — задавай!

Я на всякий случай уточню, что оригинальный менеджер пакетов, который был и есть в MODX2, в MODX3 никуда не делся и он работает ровно также, как и 10 лет назад. Для кого-то в этом и проблема (типа старый уже, надо менять), а кто-то видит в этом стабильность)))

Предложенное автором поста решение актуально при использовании новой, альтернативной возможности подключать внешний код в MODX-проекты. Эта возможность встроена в движок с версии MODX3, но как следует из поста, имеет проблемы, которые к нашей всеобщей полагаю радости, при прямых руках и светлой голове, решаемые :)

А получившийся метод реализации как мне кажется, имеет больший потенциал т.к. вылился в некий альтернативный способ установки дополнений, основанный на развитом и популярном менеджере пакетов composer, который ещё даже не существовал или был в зародыше (судя по wiki), когда в MODX появился в текущем виде свой пакетный менеджер с установкой дополнений через админку.

Может и должно, но не происходит)

Потому что на MODX и в том виде, как сейчас есть, довольно комфортно работается… может не всем, как всегда :)

Да и новая версия недавно вышла, сейчас есть смысл развивать и адаптировать дополнения, чем и занимается в основном местное сообщество! И здесь с ocstore можно провести аналогию в том, что для minishop (который сам является дополнением к MODX) есть и появляются новые свои дополнения. И не только он, есть и другие компоненты, которые образуют свою экосистему, работая дополняя друг друга.

Насколько я понимаю, должно произойти нечто подобное, что произошло с opencart.
Есть opencart, разрабатываемый американским разработчиком, есть отдельный (форк? не люблю я этот жаргон, скоро совсем уже нормальных слов не останется) — ocstore, который хоть и базируется на opencart но делается отдельными разработчиками, со своими модулями и дополнениями.

Тогда будет задержка в несколько секунд, во время отправки. Иногда до 5 секунд доходит.
Было интересно, возможно ли в FormIt такое привязать. Странно, что это не реализовано.

Проще настроить SMTP и тогда таких проблем не будет.

Дим, лично для тебя разрешаю Console. Сам не пользуюсь ей давно.

Спасибо большое, Николай, за решение! О нем мечтали, его ждали, про него спрашивали, потом его просили, и вот оно здесь!

P.S Столько обновлений здесь в последнее время, аж глаза разбегаются и такую ценную заметку банально не заметил… А может, потому что картинки в анонсе нет!? Но это не в укор, а просто попытка самоанализа.

P.S.2 А просто Console не подойдет? Просто он почти везде уже есть…

Я к тому, что до текущего момента, можно было комфортно на хорошем уровне делать проекты с MODX, применяя ряд инструментов: тот же PHPstorm, git GUI «fork», WinSCP и админку MODX, с приятными интерфейсами, не являясь при этом консольным гиком, которому достаточно созерцания прекрасного в мигающем курсоре на черном фоне.

Все-таки composer это совсем не про программирование, а тоже инструмент, который в рамках MODX, мог бы, условно, мало чем отличаться от текущего менеджера пакетов с функционалом зависимостей.

Вон сделали же GUI modxminify чтобы не собирать вручную в коде бандлы как в minifyx. Я вот не пользуюсь им, но много где видел, и соглашусь что это блин удобно для проектов где не обязательно весь код держать под git-ом (А такие бывают? — бывают)))

Идея контролировать git-ом через composer.jsom даже версии установленных пакетов в систем мне лично очень нравится, но полностью отказываться от удобного GUI-менеджера пакетов навсегда, все-таки больше похоже на шаг назад. MODX не конкурирует с Laravel, в котором куча консольных инструментов и даже веб-сервер вроде как есть свой вместо nginx/apache, это давно ясно и ничего плохого в этом нет. А вот проигрывать в удобстве админки ещё и Wordpress было бы вообще печально.

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

Иван, ну не стоит преувеличивать. Конечно, программисты с личным развитием всё время хотят усложнять свои проекты, и одновременно упрощать свои инструменты. Поэтому да, конечно для тех, кто развивает платформу, в т.ч. MODX, желание привнести крутых навороченных штук, не обращая внимания на порог вхождения, естественно) Однако если посмотреть с другой стороны: для вас, крутых разработчиков, и для некоторых других (например, с очень большой натяжкой, для меня, еле догоняющего) это «проект», а для очень многих — инструмент!

Ничего плохого в том, чтобы инструмент оставался простым, до определенного, конечно, предела, вовсе нет!

Баха, никак. Я раньше подобное предлагал, когда ездил на тусовки. Ответ был такой, что это сложно, это ж программирование изучать нужно, команды какие-то запускать, а мы привыкли кнопочки клац-клац и красиво.

Это будущее давно уже настоящее везде, где есть Composer. А для платных (ну или просто приватных) репозиториев есть даже такая тула — github.com/composer/satis.
Ну или можно заплатить денег пакаджисту и публиковать там packagist.com/pricing
Вопрос в том, что аудитория MODX всячески сопротивляется подобным нововведениям, потому что это ж программированию учиться нужно, а они привыкли на коленке все собирать, чтобы хоть как-то работало, особо не вдаваясь в нюансы.

Мне интересно, если они в курсе, то как объясняют сложившуюся ситуацию