Можно сделать свою собственную сборку на основе siteExtra. Я сейчас сайты на modx делаю именно так, сделал свою базовую сборку и в ней пишу всю основу для создания чистого сайта. Сайт на такой сборке можно легко пустить в работу, а все фундаментальные изменения делать именно в установщике. Это позволит нам избежать правок в админке и все наши изменения будут жить в скрипте. Ну и плюс это опыт по работе с modx/компонентами программно.
Так же я интегрировал в свою сборку gulp (для внесения изменений в верстку на лету). Ну это мне просто так удобно, когда верстка рядом с кодом лежит.
В будущем планирую этот билдер выложить в открытый доступ, но сейчас есть 2 небольшие проблемы, вернее одна небольшая, с ней сам справлюсь — а вот вторая большая. Мне нужна помощь в написании ресолвера, который будет устанавливать пакеты из папки. В идеале принцип работы такой, в резолвере прописать логику установки компонентов, в файле конфигурации указать название пакета и его версию, если резолвер такой пакет находит — производим установку, если нет — пропускаем и работаем дальше.
Возможно @Илья Уткин подскажет или поможет с реализацией этой идеи. Это нужно для установки собственных пакетов, которых нет в репозиториях. Свой репозиторий делать ради этого, такая себе идея. Конечно можно установить ручками — но идея как раз избежать этого! :)
Возможно кто-то уже делал такой резолвер и поделится решением.
Translitor вырезает все точки, это не очень хорошо, например когда используешь плагины или компоненты для транслитерации других вещей (например папок или файлов). Посему в translit можно указать свой паттерн, а тут нет. Это большой минус.
Ничего я не передергиваю, суть осталась. Мне тоже много чего кажется, но я не пишу людям что им нужно сделать, только лишь потому что мне что-то показалось.
Смотрите какая штука, я делал сайты на WP, после чего мигрировал на MODx и мне абсолютно фиолетово что там сейчас происходит с WP. Вы же пришли сюда из Laravel (который я тоже к слову изучаю) и начинаете рассказывать всем что кто-то (но точно не вы), должны сделать Fork.
Создавайте сайты где вам удобней, хоть свой движок пишите. Зачем вы здесь если вы ушли? Вернее не так вопрос поставил, зачем вы пишите тут людям что им нужно сделать, ведь вы ушли и вы то уж точно ничего из того что пишите делать не будете?
По этой причине я и написал этот плагин. Менеджеры могут забыть указать альт, но плагин им об этом напомнит и они пройдутся еще раз по всем изображениям и проверят их заполненность. Это их работа, а если уж они пишут там полную хрень, то это вопросы не к плагинам или сниппетам, а к менеджеру сайта. :) На картинки не из контента плагин не обращает внимания, т.к. большинство сайтов работают именно с полем content.
Применив должную фантазию и совсем немного строк кода, можно прописать любую логику в этом плагине и не только в поле content. Это минимум функционала, что-то типа базовой функции. Ну а дальше этот сниппет можно развивать и даже собрать из него дополнение.
Может быть так и произойдет, если найду причины его расширения.
Тоже вариант, но далеко не факт что alt должен содержать название заголовка. Alt отображает текстовую информацию о рисунке при отключенной в браузере загрузке изображений. Да и как там роботы воспринимают alt я не знаю. Может для них как раз важно что в alt будет вписан заголовок…
И вообще, это работа менеджера сайта, писать хороший контент правильно. Так что я, например, свое решение установил и себе на сайты, дабы не забывать про alt.
Почитай статью, я написал почему такой вариант не подошел. Как пример, представь сайт который по госту должен иметь версию для слабовидящих. На таких версиях дают возможность отключать изображения и посетитель вместо изображений будет видеть alt. По твоей логике получится везде одинаковые названия изображений.
Я уже молчу про SEO, они за такое по рукам бить будут.
P.S.
Раз тебе не нужно сбрасывать процесс сохранения, то ты можешь изменить скрипт. Там где проверяется alt на пустоту, вместо $alts[1] подставляй что угодно.
Я использую другой вариант плагина, подставляю источник файлов на основании шаблона. Проще говоря — каждому шаблону, свой источник файлов, без привязки к юзерам. Я тоже хотел свой плагин доработать, чтобы он создавал папки по текущему id ресурса. Но там всплывает множество подводных камней, типа что будет если у ресурса сменить шаблон или если удалить ресурс. Как потом удалять неиспользуемые файлы и папки и т.д. Посему управление диспетчером файлов я возлагаю на пользователей.
Например на своих сайтах я создаю папки и обрабатываю их плагином транслитерации и добавляю в название текущую дату. Так проще структуру соблюдать.
А вообще, когда сайт разрастается, пользоваться встроенным диспетчером файлов становится не очень удобно.
Так же я интегрировал в свою сборку gulp (для внесения изменений в верстку на лету). Ну это мне просто так удобно, когда верстка рядом с кодом лежит.
В будущем планирую этот билдер выложить в открытый доступ, но сейчас есть 2 небольшие проблемы, вернее одна небольшая, с ней сам справлюсь — а вот вторая большая. Мне нужна помощь в написании ресолвера, который будет устанавливать пакеты из папки. В идеале принцип работы такой, в резолвере прописать логику установки компонентов, в файле конфигурации указать название пакета и его версию, если резолвер такой пакет находит — производим установку, если нет — пропускаем и работаем дальше.
Возможно @Илья Уткин подскажет или поможет с реализацией этой идеи. Это нужно для установки собственных пакетов, которых нет в репозиториях. Свой репозиторий делать ради этого, такая себе идея. Конечно можно установить ручками — но идея как раз избежать этого! :)
Возможно кто-то уже делал такой резолвер и поделится решением.
Создавайте сайты где вам удобней, хоть свой движок пишите. Зачем вы здесь если вы ушли? Вернее не так вопрос поставил, зачем вы пишите тут людям что им нужно сделать, ведь вы ушли и вы то уж точно ничего из того что пишите делать не будете?
github.com/iWatchYouFromAfar/TinyMCERTE-Installer-for-MODX/blob/master/source/assets/components/site/tinymcerte/js/external-config.json
В самом начале пишите пути (там уже есть 2) и в них размещаете обычные файлы .html, с нужной разметкой.
Миша, спасибо за статью!
P.S.
И это с большим деревом, вложенность около 6 уровней.
Признавайтесь, вы депутат?
Применив должную фантазию и совсем немного строк кода, можно прописать любую логику в этом плагине и не только в поле content. Это минимум функционала, что-то типа базовой функции. Ну а дальше этот сниппет можно развивать и даже собрать из него дополнение.
Может быть так и произойдет, если найду причины его расширения.
И вообще, это работа менеджера сайта, писать хороший контент правильно. Так что я, например, свое решение установил и себе на сайты, дабы не забывать про alt.
Я уже молчу про SEO, они за такое по рукам бить будут.
P.S.
Раз тебе не нужно сбрасывать процесс сохранения, то ты можешь изменить скрипт. Там где проверяется alt на пустоту, вместо $alts[1] подставляй что угодно.
Я использую другой вариант плагина, подставляю источник файлов на основании шаблона. Проще говоря — каждому шаблону, свой источник файлов, без привязки к юзерам. Я тоже хотел свой плагин доработать, чтобы он создавал папки по текущему id ресурса. Но там всплывает множество подводных камней, типа что будет если у ресурса сменить шаблон или если удалить ресурс. Как потом удалять неиспользуемые файлы и папки и т.д. Посему управление диспетчером файлов я возлагаю на пользователей.
Например на своих сайтах я создаю папки и обрабатываю их плагином транслитерации и добавляю в название текущую дату. Так проще структуру соблюдать.
А вообще, когда сайт разрастается, пользоваться встроенным диспетчером файлов становится не очень удобно.
Обновил пост, добавил версию плагина который проверяет когда последний раз изменялся файл.
Спасибо за фидбэк!