Дима Касаткин

Хорошая шутка :) Ну то, что Tisckets поддерживается сообществом прямо сейчас, не значит, что и в будущем не будет! Там есть и несложные правки по адаптации к обновившемуся 10 раз серверному софту. Думаю если уж не глобальное, то такое обновление мы вполне осилим!

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

@Антон ты как, скинешься на Tickets когда время придет?

Ну так предлагайте сделать сбор на что-то популярное! Вон же @Николай Савин предложил выше всем кому тема интересна, высказаться!

На моих проектах нужен FileAttach, я нашел несколько человек которые сходу готовы были скинуться, создал сбор и мы двигаемся к цели, вместо того чтобы ныть какие все неповоротливые и безучастные (что вовсе не так) или оставлять язвительные комментарии с диванной аналитикой по поводу привычек местной аудитории. Давайте смотреть на вещи конструктивно, хоть сумму собрали пока не всю, но она уже заметная.

P.S. При всей любви к минишопу, цель этого сбора (и теперь уже не только моя, но и других участников) — получить готовое решение именно по работе с файлами, поудобнее в настройке и работе чем универсальный MIGX, под MODX3.

Так что либо мы будем договариваться с подрядчиком, либо искать другие варианты, ну в общем по мнению тех кто скидывался, пополнение копилки миниoшопа именно в этом случае всё-таки самый запасной вариант. Сожалению, что не обрадовал вас. Но раз вы не участвовали (похоже) в сборе, то во-первых, есть ещё такой шанс! А во-вторых, кто спонсирует, тот и заказывает музыку :) Так что давайте, подлейте масла в огонь и ждем пожелания на счет следующего трека!

Если это вы так пообещали спонсорство в течение 5 лет на указанную сумму, то спасибо, пригодится! Этот сбор скоро закончится и уйдет в работу, но будут и другие! А сколько вы уже скинули если не секрет? Там на бекенде «купюроприемник» почти всегда не показывает имя участника сбора…

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

Так что, друзья, хоть вы и превзошли все ожидания, но давайте [ПОДНАЖМЁМ] ещё немного!

Класс, спасибо что делитесь!

Что будет, если мы не наберем нужную сумму? (в адекватный срок)
Собранные средства тогда пойдут либо на разаботку похожего компонента или подготовку адаптации какого-то другого компонента под схожие задачи, либо отправятся в фонд развития Minishop3 (который для MODX3).

Скидываясь здесь, вы в любом случае поддерживаете сообщество!

Не готовы скинуться?
Выразите свою поддержку в ободряющем комментарии!

А вот это уже интересно! Проверьте, возможно у вас не установлено PHP-расширение imagick и картинки обрабатываются через GD, а он очень медленный. Настолько, что у нас на проектах по 1-1,5 минуты на 1 товар уходит (4-6 превью+ватермарки).

Судя по грубому расчету 50к товаров / 3600 (секунд в часе) ~= 14ч должны быть, а вы пишете что у вас 12ч, ну это близко, так что очень вероятно, что причина в этом!

Если у кого-то есть что дополнить (особенно копилку :) ) по существу, пожалуйста, самое время откомментировать!

Друзья, поскольку сбор идёт полным ходом, даже лучше чем я ожидал, и в телеграм-чате вызвал некий резонанс и вопросы, думаю настало время опубликовать (ну в смысле, сформулировать, и тогда уж) рекий Roadmap того, на что мы тут так активно скидываемся :)

В общем, ТЗ aka roadmap следующее:
• Сделать, чтобы работало на MODX3 без потери функционала (что крайне желательно)
• Чтобы работало от php 7.4 (или ниже, по желанию исполнителя) до 8.2, и желательно без legacy
• Рассмотреть issues и принять PRы (поддержка fenom уж точно)
• Обновить доку (ну или как-то передать мне существенные моменты, если при адаптации не получится 1в1 реализовать функционал как раньше, чтобы была фактура сделать PR в документацию, а кто его сделает, уже не суть, могу и сам)

А можно поподробнее, какого именно функционала новых моделей не хватает. Если всё действительно так, это же повод в MODX3 функционала добавить!

Версии 3.1 ещё не было, только патч-релизы.

Самое время набирать фактуры для новых фич ведь!

Всё понимаю, но ничего из этого не признаю) Так и знайте, что альфа пойдет в продакшен)
А как ещё внедрять edge-технологии, если не огнем и мечом?))

Отличные! нет, ОТЛИЧНЫЕ новости!

Спасибо всем кто участвует, с нетерпением ждем релиза, для новых клиентов с магазинами, затягиваем этапы прототипов и подготовки данных, рисования макетов… короче делаем все, чтобы новые проекты стартовать уже на MODX3 и Minishop3!

А ещё, с релизом будет весомый повод напомнить старым проектам о модернизации, ведь это же прекрасно, улучшать свои достижения, сколько уже можно костыли вставлять…

Донатим срочно! И потираем ладошки потестить альфу!

Привет, спасибо за релиз, большое УРА, и маленькая поправочка к:

Более подробная информация уже доступна в документации

docs.modx.pro/components/minishop2/interface/utilities/ (прям открытой ссылкой, не зря же мы за ЧПУ бились:) )

Классный хак с повторным вызовом FormIT и пробросом туда параметров из задания через $_POST, очень элегантно!

Мне вот на подобие этого нужно было как-то вызывать хук для формита с API-вызовами к внешнему сервису но без отправки формы, так пришлось его код копировать и в сниппет выносить, а стоило сделать вот так как в заметке сделан сниппет send_email, чтобы не дублировать код и не поддерживать потом 2 версии…

К стати дополню список — в AjaxFormitLogin этот метод тоже будет работать

Хм, cтранно, что поиск на github не находиn bootstrap.php

Ну теперь очевидно, что даже приведенный список пакетов означает актуальность уровня «уже» а не «скоро», как в начале показалось. И со временем будет расти…

Тогда получается, что одним best practice by Василий не обойтись, ведь родной менеджер пакетов всё ещё работает, и надо всё равно во встроенный механизм автозагрузки как-то добавлять проверку.

Беглый гуглинг показал, что не только с MODX 3 так бывает ¯\_(ツ)_/¯ например у движка Википедии похоже было подобное (ссылка ниже)

Но существуют решения (которые прямо сейчас в MODX конечно не поддерживаются):
• как встроенными средствами composer-а через специальный формат записи конфигурации ( stackoverflow )
• так и инструменты, помогающие это автоматизировать, например wikimedia/composer-merge-plugin

Наверное с эти уже пора отправляться с issue к MODX Core team, чтобы уточнить возможность прикрутить это, или нечто подобное к существующему механизму, если не для автоматизированного решения проблемы, то хотя бы для вывода предупреждений о конфликтах версий зависимостей при установке пакета… Или уже обсуждается, и я опять не осилил поиск на гитхабе?)))

В любом случае, ещё раз спасибо @Василий Наумкин и @Николай Савин за пояснения!

Так эти пакеты аффектятся описанной особенностью работы MODX 3 с композером или нет?

Если я правильно понял, самого факта того, что где-то в подпапках лежит конфиг composer.json и разработчик для обновления вендорных исходников вручную запускает composer, не достаточно, чтобы возникла возможность коллизии.

А чтобы эффект проявился, нужно чтобы пакет специально использовал в новом стиле composer:

система проходит по всем зарегистрированным namespaces и пытается подключить из них файл bootstrap.php

Такие пакеты кто-нибудь встречал? Дайте ссылку плиз, я не могу найти

Западные мейнтейнеры и правда не особо отжигают) Тут сложно спорить :) Но релиз выпустили, работы идут, и фиксы и фичи есть, то что работает — не ломают (тоже не плохо, так не везде удаётся :)))

Да и на 2ке новые проекты делать уже такое себе занятие, конечно можно, так как уже все проверенно временем и стабильно работает.

А «такое себе занятие», в смысле что мало развлечения, «слишком» проверено и стабильно? Ну такой себе недостаток :)

На самом деле есть что улучшать и в двойке, и возможно некоторые фичи, которые попали в 3й релиз, вышли бы лучше для двойки (имхо), но так или иначе релизу 3 уже больше года, смысл говорить о 4 есть только в разрезе решения каких-то глобальных проблем, а даже описанные в статье косяки с composer возможно при исправлении потянут всё-таки на релиз минорной версии, т.к. в ряд ли обратная совместимость сломается от реализации проверки версий подключаемых пакетов…

Смотри какой issue нашел по теме: github.com/modxcms/revolution/issues/16396 — есть предложение в ядро MODX внести поддержку. Если всё равно будешь копать PHPmailer для совей задачи, может за одно запилишь PR в MODX? Прославишься отважным :) !

UPD. Так оказывается уже и PR сделали: github.com/modxcms/revolution/pull/16421 ставь лайк, подписывайся (чтобы разрабы видели что важная тема), оставляй коммент (чтобы уж точно) и забирай код в свою задачу! (пока не выпустили в следующем патч-релизе MODX, там они почти доделали уже, с переводами встряли что-то)

Вы специально зарегистрировались, чтобы это написать? Попробуйте лучше MODX 3 в деле! Это быстрый и удобный движок, на котором легко запускать простые и сложные сайты. А техническое несовершенство и постоянные новые и суровые вызовы для программистов найдутся и в любом другом движке. Разного рода запахи короче говоря, есть абсолютно у них у всех)

Спасибо, перечитал несколько раз, и если на этот раз правильно понял :), то всё что я написал выше, верно, но только для пакетов, собранных «по-старинке» без автозагрузки через bootsrap.php, так?

Сейчас для MODX3 большинство дополнений как раз такие (т.к. адаптированы, но сделаны были для MODX2) поэтому проблема и не проявляется массово?

Я ещё перед тем как первый коммент написать, я проверил исходные коды популярных дополнений: FormIt, Minishop2, MIGX, pdoTools, ImageCropper, Formalicious, CKEditor Resizer и некоторых других и нигде нет bootstrap.php которые по 10 раз должны (или могли) бы загружаться, как описано в статье.

Может кто-нибудь привести примеры хотя бы 1 или лучше 2 дополнений, где есть автозагрузка через bootstrap.php, которые потенциально могут сломать друг друга? Мне тема показалась довольно серьезной, хочу проверить!

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

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

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

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