iWatchYouFromAfar

Мои клиенты нынче это тир1 финтех компании чей капитал больше бюджета твоего города. Лохи? Может быть, я так не считаю.

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

то есть по твоей логике в современных ресурсах...

Окей, допустим я представил как твои мега-богатые клиенты, заказывают корпоративные сайты с очень динамичной, но люто багованной и что самое важное тяжелой и неудобной админкой.

Но представить что эти же клиенты получают на выходе проект, который не запускается в dev и stagging режимах. Над которым невероятно сложно работать в команде и который крайне сложно передать другим разработчикам на хотя бы лет 5 стабильной работы/доработки без рефакторинга. И уж тем более не версионируется… Нуу… Не, не могу представить. Хотя нет, вру, могу — если клиенты лохи.

Проблема тройки — овощи у которых на гитхабе права на репозиторий, при чем тут вообще сторонние инструменты?

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

P.S.
И все таки я не понимаю в чем был не прав… В том что ZoomX будут пользоваться единицы или в том, что это шаблонизатор или про выбор MODx как инструмента для создания сайтов?

Когда ты последний раз писал апи? Обычный роутинг обычного проекта, при чем тут апи вообще?

Каждый день занимаюсь этим на протяжении последних полутора лет. И вот такие вещи

$router->get('uri', function() {

Очень похожи на

app.get('/', function(req, res) {

В каком-нибудь Express.

Если у меня средне-высоко бюджетный проект где нужно накидать сайтец для корпоратов я пойду брать фреймворк? Да?

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

Проблема MODX в том, что разработчики в нем не растут...

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

Ты сам знаешь думаю, в IT стоит перестать интересоваться новым на пару лет, как ты уже начинаешь выплывать из сферы.

В остальном хз как на такие высеры отвечать. Не буду ничего писать про легендарную тройку. Посмотри сколько скачиваний у ZoomX, а это уже версия 3.4. Так что, мне рассказывать то не особо будет нужно. Сам увидишь по востребованности.

P.S.
Людям дали инструмент. Но любой человек который перешагнул по навыкам и знаниям MODx, уйдет в более современный и востребованный на рынке инструмент. Вон тут уже упомянули Laravel.

Тут лишь остается рассматреть вариант сборки сайтов на MODx в кач-ве фриланса. Вариант конечно имеет место быть, но крайне спорный… Лучше уж взять хороший фриланс заказ и создавать его на микросервисной архитектуре, используя современные инструменты.

Объясни конечно, почему я должен гадать?

Ты если не согласен с чем-то, напиши с чем, возможно я не прав и ты меня переубедишь, если не хочешь писать, то нахера высрался? )

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

Интересные проекты… У меня ни один проект не обходился без какого-нибудь pdoMenu или pdoResources. Я не про написание самих сниппетов с нуля, а составление уже готовых сниппетов.

Сергей написал просто более менее актуальный шаблонизатор. MODx не простой, т.к. для того чтобы собрать сайтец нужно как минимум уметь писать сниппеты, хотя бы самые простые на modParser. В то же самое время, достаточно функциональные сайты на WP создаются исключительно мышкой.

То что я вижу в примерах выше, очень похоже на то, как пишется сегодня какой-нибудь REST API. Но в MODx это почти нахер никому не нужно. Если у тебя будет средне или высоко бюджетный проект на котором потребуется хороший бек, ты уж точно не выберешь MODx с ZoomX или Fenom и пойдешь писать свой бек на каком-либо фреймворке.

Так что, ZoomX это заранее мертворожденный продукт, которым кмк будут пользоваться единицы. Все задачи для создания низкобюджетных сайтов на MODx — покрывает pdoTools с феномом.

P.S.
Собственно, наблюдая за тем как развивается MODx, у меня складывается впечатление что очень многое из того над чем сейчас работают люди, это либо мало кому будет нужно, либо уже совсем неактуально в свете последних тенденций рынка web-разработки.

submitVar надо вообще убрать при использовании ajaxForm.

Посмотри эту тему — modx.pro/help/4765#comment-34635

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

А зачем вам для этого migx? Вот пример добавление в раздел пользователя таба, внутри которой можете рендерить что угодно и работать с этими полями штатно, как с другими полями пользователя.

Не буду тратить время, пытаясь вслепую понять, почему ваш сайт попал в 00.01% сайтов, на котором сниппет не работает.

Главное что вы решили вашу проблему. А как, и чем это аукнеться, это уже вопрос для более глубоких тем и обсуждений.

В моем варианте все прекрасно работает, использовал этот сниппет на более чем дватцати сайтах:

{'pdoCrumbs' | snippet : [
'outputSeparator' => '',
'showHome' => 1,
'showCurrent' => 0,
'hideSingle' => 1,
'tplWrapper' => '@INLINE <ul itemscope itemtype="http://schema.org/BreadcrumbList" class="breadcrumbs">{$output}</ul>',
'tpl' => '@INLINE
        <li itemprop="itemListElement" itemscope itemtype="http://schema.org/ListItem">
             <a title="{$menutitle}" itemprop="item" href="{$link}"><span itemprop="name">{$pagetitle}</span></a>
             <meta itemprop="position" content="{$idx}">
        </li>'
]}

Я в комментариях и на своем сайте привел аж два варианта генерации ХК сниппетом pdoCrumbs. Просто кто-то читает не внимательно.

Вы заменили генерацию урла для первого элемента ХК, это не костыль даже, это просто бесполезное действие, оно ни на что не влияет. Разве что в один чудный день, главная страница вашего сайта вдруг сменит идентификатор и вот тут костыль ваш всплывет. Костыли со скрипом но решают задачи, а вы просто заменили геренацию урла для первого элемента ХК. Это вообще не относится к itemprop=«item…

Если уж хочется говнокостылить, то делайте это хоть чуть-чуть правильно:

href="{$_modx->makeUrl($_modx->config['site_start'])}"

Рекомендую вам вернуть все как было и еще раз прогнать разметку через валидатор schema.org. После внимательно посмотреть, где ошибка.

Ошибка «Отсутствует поле „item“» возникает на элементе текущей страницы ХК при генерации ХК этим вариантом сниппета, но на всех нормальных сайтах в ХК просто напросто нет текущего элемента.

Именно по этой причине я и написал на своем сайте:

"Наиболее правильный вариант, который устраивает поисковых роботов и Google и Yandex:"

1. В MODx уже как несколько месяцев 5-ая версия TinyMCE RTE, в моем посте в заголовке написано — "для TinyMCE 4". Значит нужно немного переписать плагин для актуальной версии.
2. Твоя задача по открытию нужной директории решается с помощью MODx плагина.
3. Автору глубоко плевать на совместимость и твои проблемы.
4. Делаешь форк моего репозитория с плагином, запиливаешь крутые фичи, выкладываешь в опенсурс.
5. Удосуживаешься описать совместимость.

Я полностью согласен с каждым пунктом. Я по сути и начал писать про «такую уж необходимость MODx 3» — потому что большинству моих клиентов (малого и среднего бизнеса), MODx 3 по сути и не нужен. И я лично не могу пока что найти серьезных причин в необходимости развития системы, которая во многих аспектах устарела, не успев еще выйти. Я вышел на эту дискуссию, чтобы найти истину. А истина пока что в том, что

* «работы проведено очень много...».
* «Она априори лучше, так как это по сути развитие Revo...»

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

Искренне скажу, что буду рад ошибиться. Я люблю MODx и уважаю сообщество. Именно по этой причине я уже не первый год пытаюсь понять, в чем смысл жизни MODx 3.

P.S.
MODx я пишу — потому что это красивее нежели MODX.

Как-то абсурдно звучит, что клиенты стерка это клиенты, которые думают о будущем и выбирают MODx как фундамент для своих веб-приложений. Я работал в европе физически, у меня не было клиентов из «Большого бизнеса», в основном это нишевая текучка малого и среднего бизнеса (новый бизнес, рефакторинг сайтов существующих фирм, которые не выполняют своей задачи, веб-приложения под продукты, CRM и т.д.). Так вот подавляющее большинство европейских клиентов, прям четко приходят с хотелкой чтобы их сайт реализовали на WP и никаких убеждений слышать не хотят.

Я понимаю что можно работать на европейский рынок. Но я думаю, что на этом ресурсе, все таки рационально говорить про российский сегмент. А на российским сегменте, очень мало работы с MODx. И я не про фриланс, а про спрос специалистов, готовых обслуживать сайты на MODx. Их почти нет. Фриланс это как раз те самые нишевые малые бизнесы.

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

P.S.
И да, бизнес очень часто требует свой продукт здесь и сейчас, потому что нет денег на долгострой. Но это проблема бизнеса в нашей стране или конкретно того, у которого нет денег.

Это вопрос на самом деле не к RU-коммьюнити. @Иван Климчук ездил в Нидерланды на митап с докладом, где как раз затронул речь про MODx 3 и его «обратную совместимость» и там такой холивар в зале начался…

Нет, я не застал переезд с evo на revo. Знаю лишь что и тогда были проблемы, оттуда вроде и вырос Evolution CMS.

Время покажет, насколько правильными были те или иные действия. Лично я надеюсь, что релиз MODx 3 даст толчок на создание фундаментально новой версии MODx.

Я не согласен насчет экосистемы, ее обновление не будет проблемой если все коммьюнити начнет миграцию на новую версию. В этом случае да, вторая версия с каждым днем начнет реально устаревать в пользу новой. В реальности же авторов которые способны писать компоненты (особенно бесплатные) не так много. Есть два вопроса:

1) Когда текущая экосистема будет полностью адаптирована под MODx 3?
2) Сколько времени должно пройти после релиза, прежде чем MODx 3 станет энтерпрайз инструментом?

Бизнесу не выгодно тратить деньги на переезд со второй версии на третью. Они с этого не получат никакой прибыли, скорее всего.

Кмк, на спрос MODx 3 будет влиять несколько вещей, главные из которых, частота его обновления в плане новых фич и стабильности и активность сообщества в плане его применения. Иначе, MODx 3 будет лежать и пылиться на полочке.

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

Исходя из того что описан Иван, я могу сделать только один вывод. С точки зрения развития сайтов на MODx 2 как бизнес-продуктов, менять версию системы нет абсолютно никакого смысла, т.к.

1. Вторая версия себя успешно зарекомендовала как стабильную.
2. Для второй версии есть тонна готовых решений, как платных, так и бесплатных.
3. Для второй версии есть тонна готовых скриптов в публичном доступе.
4. Для второй версии адаптированы оба репозитория (modstore и modx.com)
5. Сайты на второй версии будут еще годами решать все те же задачи, что и сайты на MODx 3.

Соответственно критерием смены версии MODx с 2 на 3 для бизнеса, будет являться естественное устаревание второй версии, при очень активном развитии экосистемы для третьей версии.

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

Хотелось бы услышать мнение разработчиков MODx 3 по этой теме.

А что в MODx 3 нового? Зачем человеку, который уже не первый год успешно решает задачи используя MODx 2, менять уже стабильный билд на 3?

Хочу отметить, что для бизнеса фраза «работы проведено очень много» это пустое место. Они разработчикам деньги платят за работу. И для проведения работ по смене версии MODx с 2 на 3, должны быть очень значительные причины, в первую очередь для бизнеса.

Что касается разработчиков. То подавляющее большинство из них, решают свои задачи благодаря готовым компонентам и готовым кусочкам различных кодов, которые разбросаны по всему интернету. Многие из этих компонентов и кусочков кодов, придется наверное переписывать под MODx 3. Я думаю вывод ты сделаешь сам.