Стів Макдугал поставив нам чудове запитання в Twitter про наш редизайн та перезапуск Laravel News на Statamic:
>Я хотів би прочитати, як хтось із команди @laravelnews пристосувався до @statamic і що змусило їх вибрати це як систему CMS.Було б дійсно цікаво подивитися, як їм довелося адаптуватися, і які непередбачені переваги вони могли знайти.
Відповіді на ці запитання не вміщаються в твіті, тому я хотів розглянути кожен пункт і трохи поділитися за лаштунками про те, як все це сталося.
Чому ми вибрали Statamic
Я подивився на Stamic з моменту його першого запуску. Дивлячись на мою історію покупок Statamic, я був клієнтом з версії 1, але ніколи не відчував, що настав час, щоб зробити стрибок від моєї старої системи. Все змінилося, коли вони запустили версії 3 минулого року та перемістив його до більшої установки в стилі пакета 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.
