Алексей Соин

и что мешает вывод данных полей отключить и не видеть их, если они так тебе мешают?

Два раза пишут одно и тоже в поле pagetitle / longtitile

Зачем? можно написать чтото типо такого:

{$_modx->resource.longtitle ?: $_modx->resource.pagetitle~' | '~$_modx->config.site_name}

title нужен в первую очередь для SEO и он может отличаться от заголовка страницы

Если данные поля именно ты не используешь, это не значит, что их нужно выпелить за ненадобность, мне недавно написал один человек который каждую страницу на сайте хранит в отдельном шаблоне))) понятное дело, что так тоже както «работает», но это не есть верная и правильная практика ?

это уже на совести их авторов

тут бы придусмотреть такой вариант, чтобы не только автору можно было адаптировать дополнение под API, а и самому разработчику сайта, например, я не думаю, что тотже автор MIGX сразу обновит дополнение, а своими силами почему бы и не адаптировать)))

Недавно тоже задумывался сделать простенькую админку для менеджеров, в результате задумался о проблеме кастомных тв, и страниц администрирования созданных дополнениями. Возникла такая идея, возможно она мегакостыльно звучит, но всёже, vuejs хорошо работает в связке с другими js библиотеками, с темже jquery например, что если не отказываться от extjs, а оставить возможным работу с дополнениями написанными на нем, а уже для новых дополнений делать некую поддержку выноса на фронт, как предложил Сергей. В таком случае можно и развивать дополнения и оставить поддержку на первых началах стандартной админки.

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

Grav CMS — это представитель так называемых Flat-FIle CMS (October CMS кстати тоже к такой относится), хорошая система, у меня даже по ней статейка есть))) но это не в коем случае не JAMstack.

Да, согласен, JAM-стек достаточно молодое направление, а началось всё с jekyll и тем, что github его из коробки у себя стал поддерживать =)

Ого! Сложно, но интересно. Давно хотел узнать, как в MODX сделать API, даже как то на modx-клубе спрашивал у тебя по данной теме, а тут уже два варианта за несколько дней))) Спасибо!

Если комменты disqus, обратная связь Netlify и т.д. и т.п., то это уже практически полностью статический html-сайт без большинства современных прелестей.

Ну судя по документациям в работе с JAM-стеком в большинстве случаев предлагают именно так делать. Думаю у многих было такое, что разрабатывал лет 5 назад небольшой сайт на modx кому то, он прекрасно работал, и тут бац, пошли массовые взломы всех версий modx до 2.6.7 версии и этот сайт перестает работать, данные затерлись, в общем ужас… Мелкий сайт, а получаем большие проблемы, данные восстановить, modx обновить, проверить что всё работает и т.д. Хотя для заказчика этот сайт нужен был для статей и как визитка организации. Используя статически генерируемые сайты эта проблема просто не могла бы возникнуть, и если бы уж и как то получилось так, что с сайтом что то случилось, то используя версионирование github можно просто откатиться на стабильную версию и посмотреть в чем проблема.

Про безопасность в GraphQL — отдельная тема.

Интересно было бы почитать =)

Тут тогда сразу возникает вопрос, а какие данные не могут быть сгенерированны один раз в html файл и их нужно брать из бд по API? Страницы с контентом вполне можно собрать один раз в виде html файлов и никаких обращений к бд не потребуются. А если нужна, например, форма обратной связи, то у самого сервиса Netlify есть api для этого или можно воспользоваться вот таким сервисом. Если нужны комментарии на сайте, то подключаем disqus. Это конечно как вариант, можно конечно всё своё использовать для формы обратной связи и комментариев.

А тем текстом, который приведен в цитате, я хотел сказать, что статичные сайты получают такое преимущество, как исключения взлома с помощью sql инъекций(возможно даже ddos, но тут я не уверен). И тут еще такой момент возникает, эти динамичные запросы которые будут в статичном сайте с большой долей вероятности будут и на динамическом сайте, и они будут работать по тому же принципу, следовательно дыр безопасности будет меньше на статичном сайте.

Николай, насколько я знаю, в вашей cms используется как раз rest api для работы с данными, исходя и накопленного опыта можешь рассказать, какие есть проблемы в безопасности при работе с rest api(или там graphQL используется… я уже точно не помню)?

Если как в данном случае использовать генератор статических сайтов Hugo, то ресурсы (то есть исходники страниц сайта) хранятся в папке content и имеет вот такую структуру

├── _index.md
├── about.md
└── post
    ├── _index.md
    ├── post-1.md
    ├── post-2.md
    └── post-3.md

А если использовать такую безголовую CMS как strapi, то в ней хранятся данные в файле SQL lite

Я был готов к такому комментарию ?. Лично я считаю, что увеличение кругозора и списка известных технологий помогают разработчику более профессионально использовать свои навыки в проектах. Например в данной статье я рассказывал про такой сервис как Netlify, которым, если рассматривать в ключе MODX, очень удобно пользоваться для показа верстки заказчику и последующей интеграции её с MODX, ведь с этим сервисом очень хорошо экономиться время на размещении верстки. Или например когда я переносил свой блог с MODX на GRAV CMS я увидел весь кайф в работе с yaml файлами и тем, как php работает с ним, и вот теперь везде где это уместно, при разработке сайтов на MODX или на какой то другой системе, я использую yaml файл вместо json файлов, как это было у меня ранее)))

А помойкой сайт modx.pro точно не станет, если учесть как часто на сайте выходят новые статьи увеличение тем только пойдут на пользу.

клиент для которого я делал этот рынок, начал активно просить сделать управление подписками

В данном контексте звучит типо «клиент хотелку придумал, но платить не хочет, давайте соберем ему на реализацию данной штуки»)))

А если серьезно, то нужна ли вообще данная вещь в «Tickets» из коробки? Или это планируется сделать как отдельное дополнение?

Иван, спасибо большое за активность в жизни сообщества и вклад в MODX!? И отдельное спасибо за помощь в различных вопросах смежных с MODX ?

напомнило эту картинку))) ну незнаю, может я или не делал чтото глобальное или очень сложное, но возможностей VSC мне сейчас хватает

эт ты еще на всяких форумах и чатиках по линуксу не спрашивал начальные вопросы)))) вот там джентльмены знают толк в покрывании хренами)

честно говоря твой посыл в этом сообщении я понял только после 4-5 раза перечитывания :D

Советую вместо gulp-uglify использовать gulp-uglify-es, так как gulp-uglify не поддерживает ES6 и при компиляции такого кода будут возникать ошибки

мне кажется, лучше всего возвращать не дату, а md5 хеш файла, по типу как работает gulp-version-number, таким образом хеш изменится только тогда, когда в файле будут внесены изменения, но тут уж кому что нравится))

Интересно было бы почитать статью по данной теме от вас, про безопасность и примеры использования, сам уже на нескольких проектах использовал vuejs, для вывода данных использовал axios запросы.

Вряд ли контент-менеджер знаком с vue ))

А для чего контент-менеджеру знать vue если для него уже будет готовое решение?

Редактирование контента на пользовательской стороне часто просят реализовать, простым пользователям намного проще редактировать информацию именно там где она выводится. Очень хотелось бы прочитать статью о практических способах реализации данной вещи)))