Іван Клімчук

Зол на что? Что случайно попал под каток глобальных чисток аккаунтов, а сделал неправильные выводы, что слили именно тебя и специально? Это и называется детский сад. Кричать и злиться тогда, когда следует сначала спросить, а за что и выяснить, что собственно случилось?
Ты конечно же больше в чатик не пойдешь и будешь доказывать, что никто перед тобой не извинился. Смею тебя заверить, что это не так, этой картинкой.

Ну давай разбираться.
Jako пишет: «The last message from Vasily here was from May 2018.»
Ryan отвечает: «We are cleanup of a lot of things that have been gathering dust in general: mail accounts, domains/subdomains, servers, services (including Slack), etc. Have already freed up thousands per year and there is a lot more to go. I’ll look into what happened in this case Monday. Have been out of town last two weekends and am going to spend time with Liz this one!»
Jason пишет после всего: «Sorry about the confusion folks… was just trying to cleanup inactive accounts. My mistake.»

Ты пишешь: Владельцы MODX, удалили меня из чата не спросив, который я читал, но в который не писал больше 2 лет (что тогда блин активность в твоем понимании?), пойду плакаться.

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

И да, я не про саму ситуацию в целом, а скорее про реакцию на нее. Бежать жаловаться на все сообщество, что тебя удалили из чатика, не разобравшись сначала в причинах, ни разу не лучшее поведение, чем того же Джейсона, удалившего из чатика без предупреждения. Обе стороны «хороши», как говорится.

Вставлю свои 5 копеек. Это похоже на обиду в детском саду, когда машинку отобрали.
Когда я написал, что ухожу, меня тоже либо сознательно, либо из-за неактивности кикали из того чата, потом вернули, когда попросил. Это нормальная здравая политика безопасности, иногда чистить неактивные аккаунты. Никто не будет за каждым бегать и уточнять, работаешь ли ты еще с MODX или нет? Тем более достаточно на GitHub посмотреть активность по VESP и сделать выводы, что фокус сейчас не на MODX.
А еще говорим о том, что взрослые люди.

Поменяй minimum-stability в composer.json на dev, modx-то тут причем?

Можно сделать форк кода, лицензия это позволяет, но называть это MODX нельзя, имя защищено торговой маркой.

Так вам помощь нужна или вы здесь поогрызаться?

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

<?php
    
if (!$object->xpdo) {
    return false;
}

$version_data = $object->xpdo->getVersionData();
$version = implode('.', [$version_data['version'], $version_data['major_version'], $version_data['minor_version']]);

if (!version_compare($version, '2.6.5', '>=')) {
    $object->xpdo->log(modX::LOG_LEVEL_ERROR, 'Invalid MODX version. Minimal supported version is 2.6.5.');

    return false;
}

return true;

Кстати, тут еще вспомнил, что когда колупал различные скелеты и мануалы по Slim 4, встретил интересный паттерн ADR (Action, Domain, Responder). Это из теорий о гексагональной архитектуре, паттерн сам по себе достаточно спорный и многословный, хотя архитектурно хорош и сделан специально для backend сервисов.
Хотел узнать твое мнение на этот счет.

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

Первое, что меня смутило, это метод process, который нужно явно определять в тех же роутах, вместо `__invoke()`, при использовании которого можно передать просто имя класса.

Второй пункт просто вопрос. Классика миграций — это up/down, но пробовал ли change у phinx? Пишут, что он умеет сам определять, что нужно откатить. И тут в довесок брюзжание на тему, что в одной миграции две таблицы описаны, а лучше бы разделять сущности (имхо).

По толстым контроллерам и нарушением правил по service layer в целом понятно и принято, сделать близко к логике MODX, хоть и не канонично :) Но главное работает.

По github.com/bezumkin/vesp-example кстати, можно поставить в настройках репозитория галочку Шаблон, будет удобно сразу себе в репу утащить и потом просто клонировать уже готовый код, чтобы не возиться с созданием, клонированием, прописыванием remote и тд.

В остальном неплохой инструмент получился, лайк!

Ты можешь воспринимать это как придирку, твое право. И это твоя система, ты за нее в ответе. В то же время ты сам упоминал, что у вас есть окружения, которые настраивали матерые devops, на k8s и прочем непотребстве и там все намного серьезнее и аккуратнее и ведь неспроста это так, согласись?
Я по стечению обстоятельств тимлидствую ещё и над несколькими девопсами и мои рекомендации и замечания основаны на определенном практическом опыте этих людей.

Зная, что у тебя везде доступы одинаковы, ничего не мешает, утилизируя уязвимость код на php (а они в общем-то могут быть), узнать креды подключения БД и получить полный доступ над системой, а то и всеми твоими проектами сразу. А ты эту информацию уже публично раскрыл. Технически да, они изолированы внутри, но если это продакшен, то лучше так не делать.

Глянул в код, вынужден ругаться.

docker system prune -a и прочее — это ж если какие другие окружения на докер подняты, грохнет все к херам. Нельзя так, даже если очень хочется. Я б за нож взялся, случись у меня такое. Хоть это и makefile для удобства, но я бы ограничивал бы его областью конкретного окружения, то есть управлять только тем, что описано в docker-compose.

Делать дампы БД, когда в docker есть data-volumes, которые в случае с mysql работают просто как часики (чего не скажешь о postgress) — выглядит крайне крипово. Они сторят файлы БД на локальной машине, сам сервер — в контейнере. При перезапуске данные всегда на месте. Тем более, что конфиги ты через них уже пробрасываешь.

Остальное уже придирки. Инструмент задачу решает — уже хорошо.

Хехе. Те же детские болезни, что у меня в начале. Возня с hosts и nginx-proxy.
Я решил эту проблему, подняв вместо nginx-прокси Traefik, который отвечает за резолвинг локальных доменов, причем он умеет в нормальный https и позволяет декларативно прописывать домены прямо в docker-compose.yml. А чтобы не возиться с хостами, я сделал локальную доменную зону через dnsmasq.
В ближайшее время выкрою время и допишу парочку своих заметок на эту тему.
А вот насчет того, что креды у БД везде одинаковы, это все же небезопасно, даже если крутится в контейнерах.

А можно посмотреть в сторону traefik.io/ и забыть про nginx-proxy и секс с портами навсегда ;)

Пока нет, но планируются. Не скажу, что без них совсем сложно. Местами, конечно, было бы удобнее, но задачи успешно решаются и без них.

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

Это ты на golang не писал, там тебе даже дуло в ногу направить не позволят, не то, что выстрелить :)

За белорусский язык спасибо!