Николай Савин

Так и я не против (Как будто это кого-то волнует). Лишь бы не распылить внимание аудитории, ожидающей (прежде всего) статей хотя бы отдаленно связанных с MODX.

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

Увеличение кругозора это оптимальное вложение денег, времени и сил. Согласен на 100%. Главное делать это последовательно и применять на практике. Я вот кстати даже не знал о существовании подобных инструментов. За что спасибо.
Дальше сарказм.
Теперь у меня будет больше ненужной информации в голове )) Пока не представляю где это применить.

Не в коем случае не хочу задеть автора статьи. Я скорее хочу написать свое мнение о желании писать здесь статьи не связанные с MODX.

Ох боюсь я что если отойти от темы сообщества — то сайт может превратиться в информационную помойку. Авторский материал то может и полезный, и актуальный для web в целом. Но сильно разный, не понятно по какому признаку относящийся к проекту и зачем здесь нужный.

Предлагаю фильтровать материал все таки как то по отношению к MODX. К примеру статьи про фронтэнд, который взаимодействует с бэкэндом на MODX — это наверное уместно, если описана технология и методика связи фреймворков.

Вот и поговорили (

Почему это нет. Я к примеру — впервые слышу о твоем желании. Ну как впервые, учитывая что один компонент у тебя уже забрал несколько месяцев назад. Других ты не предлагал. Готов и другие забрать поэтапно на поддержку и развитие, где оно возможно. В том числе бесплатные. Даже в первую очередь бесплатные. Обсудим?

Эван тоже уже не один

А зачем нужно блокировать Яндекс советник?

Кстати рерайт — отличная идея. С разрешения Артема конечно и указания ссылки на канал.
Тот же код, который пишет Артем в прямом эфире — полезно будет воспроизвести для лентяев.

Плюс за разбавление информационной тишины.

Не критика — делюсь мнением.
Не разу не пользовался ни одним из этих пакетов. Даже не могу представить ситуации, когда бы мне это пригодилось. За глаза хватает чаще всего использования файловых элементов феном + работа на phpStorm (где всегда включено версионирование естессно). В тех редких случаях когда требуется управлять и записями в базу — использую App, и то что уже поднакопил на базе App.
С App можно и ресурсы и шаблоны и TV и системные настройки версионировать. Ну и прочие атрибуты, вроде списка компонентов, конфигураций MIGX можно все в резолверы положить. При этом не нужно править сорцы и переживать потом за обновление.

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

Вспоминали многострадальный снег. Но это не Баха вспоминал.

Смотрите — здесь две стороны медали. Да безусловно — стандарты, есть стандарты и поисковые боты скорее всего все таки заметят несоответствие стандартом. Но само по себе это не является фактом ранжирования. Это может лишь служить сигналом об общем качестве сайта и проверке на другие HTML ошибки.

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

Итого скорость загрузки и вес страницы кладут на обе лопатки отсутствие обязательных атрибутов.

Не делай так. Забанят.

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

Просто и без лишних слов (дабы администрация не ругалась) ставлю большой однозначный плюс!

Когда мне надо, я делаю несколько джоинов, на каждую картинку отдельно с псевдонимами image1, image2, image3 и так далее. А в чанке уже проверяю на существование каждую картинку, сколько их там надо. Хоть 10 штук. Такой вариант будет быстрее и правильнее, чем в каждом чанке вызывать ms2Gallery, но код вызова существенно сложнее получается. Могу дать пример вызова если надо.

Может Яна не в курсе? @yani сделаешь обновление?

Ну сегодня все очень быстро, да.

Демо загружается секунд 30-40.

Убирает предупреждение для серверов на apache, а вот для серверов на ngnix, которых большинство — фокус не удастся, там только текстовый файл физически удалять