Стив Макдугал задал нам отличный вопрос в Твиттере о нашем редизайне и перезапуске новостей Laravel на Statamic:
Мне бы хотелось прочитать статью кого-нибудь из команды @laravelnews о том, как они адаптировались к @statamic и что заставило их выбрать эту систему управления контентом.Было бы действительно интересно посмотреть, как им пришлось бы адаптироваться, и какие непредвиденные преимущества они могли бы найти.
Ответы на эти вопросы не поместятся в один твит, поэтому я хотел пройтись по каждому пункту и немного рассказать о том, как все это происходило за кулисами.
Почему мы выбрали Statamic
Я присмотрел Statamic с момента его первого запуска. Глядя на мою историю покупок Statamic, я был клиентом с версии v1, но никогда не чувствовал, что пришло время совершить переход от моей старой системы. Все изменилось, когда они запустили v3 в прошлом году и переместил его в настройку, более похожую на пакет Laravel.
В версии 3 вы можете установить его с любым приложением Laravel, а это значит, что я смогу сохранить большую часть существующего вторичного кода, который запускает Laravel News. Это такие вещи, как раздел ссылок, автоматический ежедневный информационный бюллетень, управление учетными записями и т. д. Знание того, что я могу сохранить все это и получить новую панель управления для написания и публикации сообщений, было большой победой.
Еще одним преимуществом является то, что Statamic позволяет смешивать и сопоставлять базу данных и плоские файлы. У нас уже были пользователи в таблице, но у нас было странное несоответствие с нашей старой системой, где у нас были авторы статей в двух системах, наша таблица пользователей и сайт WordPress. Я вручную синхронизировал их, чтобы авторы совпадали, и это сделало гостевую публикацию довольно сложной.
Кроме этого, я всегда хотел, чтобы сайт максимально использовал сообщество Laravel, и поддержка авторов, которые являются нашими и моими коллегами, была заманчивой.
Как мы адаптировались к Statamic
Statamic стал для меня процессом обучения, и мне еще предстоит многому научиться. Адаптация была довольно простой с точки зрения повседневной публикации.
Все статьи на сайте находятся в единой коллекции Statamic с примерно 14 различными наборами полей для каждой публикации.
Все они в основном соответствуют тому, что мы использовали в WordPress для старого сайта, поэтому аспект публикации не сильно изменился.
Что изменилось, так это то, как все хранится. Statamic дает вам возможность использовать плоские файлы или базу данных, и в нашем текущем выпуске мы используем плоские файлы уценки. Это более 2500 только для статей, и хотя база данных, вероятно, более производительна в нашем масштабе, у Statamic есть несколько встроенных опций кэширования, которые делают это спорным вопросом.
Мы используем их систему статического кэширования, и она работает так: когда страница загружается впервые, она сохраняет статический HTML-код. файл, поэтому Nginx пытается обслужить его, если он существует. Если нет, он создает файл и обслуживает его в следующий раз. Это ускоряет работу, когда вы получаете кешированную версию.
Конечно, с 2500 сообщениями, десятком категорий и кучей тегов количество создаваемых статических файлов довольно велико. Это не то, что мы планируем очищать часто, только когда нам нужно внести изменения в дизайн. Однако при публикации мы удаляем некоторые критически важные страницы, такие как домашняя страница и страница родительской категории.
В сочетании со статическим кэшированием каждый раз, когда у нас есть раздел сайта, которому нужны свежие данные, мы используем Alpine.js для захватить данные. Например, под каждой страницей сведений о сообщениях есть раздел, в котором отображаются последние сообщения.
Вот внутренний код Statamic Antlers в паре с Alpine, который сохраняет актуальность:
<ul x-data x-init="fetch('/ajax/latest').then(response => response.text()).then(html => $el.innerHTML = html)"
class="lg:gap-16 sm:gap-8 grid grid-cols-12 col-span-10 col-start-2 gap-6">
{{ collection:articles limit="3" :id:not="id" }}
{{ partial:articles/card class="text-white" }}
{{ /collection:articles }}
</ul>По умолчанию элементы списка предварительно заполняются самыми последними данными при первоначальном кэшировании файла, но как можно скорее они заменяются «настоящими» последними. Таким образом, у него есть данные на случай, если запрос не будет выполнен.
Наконец, на маршруте ajax/latest он извлекается из вторичного кеша Redis. Таким образом, он по-прежнему кэшируется, но не навсегда, как страница сообщения.
Еще один пакет, который мы используем, — это Alpine Turbo Links.Это еще одна причина, по которой сайт так быстро переключается между страницами, а с установленным Turbolinks он автоматически извлекает страницу, заменяет ее <body> и объединяет ее <head>, и все это без затрат на полную загрузку страницы.
Есть непредвиденные преимущества?
Я думаю, что еще рано, но я заметил, что мне нравится панель управления Statamic.
