Очень требовательный разработчик в отношении статических генераторов сайтов PHP: Часть 1 - Sculpin

1. Sculpin (около 1200 ★)
2. Структура каталогов
3. Пользовательские типы контента
4. Готов ли Sculpin к содержанию?
5. решение суда

Работая в такой отрасли, как технология, вы начинаете замечать тенденции, которые приходят и уходят, но есть один язык (и его экосистема), который исторически не слишком заботился об этих тенденциях, как это делало свое дело: PHP. Я являюсь разработчиком PHP более 10 лет, и хотя это правда, что долгое время PHP был изюминкой всех серьезных разработчиков , верно и то, что в последние годы он стал потрясающей платформой: PHP 7 привел к фантастическим улучшениям производительности (не говоря уже о таких дополнениях, как объявления скалярных типов или обработка ошибок через интерфейс Throwable), и экосистема расцвела благодаря Composer, возможно, одному из лучших менеджеров пакетов, разделяющим стандарты в форме PSR, и высококачественные фреймворки и компоненты (Symfony, Laravel, Zend Framework, Slim ...)

Но одна тенденция, которая, похоже, не оставила следов в мире PHP, - это статические сайты. Теперь они снова классные, так что, я думаю, вы либо умрете героем, либо живете достаточно долго, чтобы увидеть себя злодеем, но потом снова переродиться героем? Кто знает. Однако я знаю, что разработчики PHP должны иметь доступ к качественным генераторам статических сайтов (SSG), которые есть у других: я думаю о Джекиле, Мидлмане, Хьюго, Металсмите, Гэтсби, Уайаме и многом другом. Поэтому в тот солнечный день в дождливый день в парке в моем домашнем офисе я решил узнать больше о статусе генераторов статических сайтов на PHP-земле и рассказать вам все об этом.

Первое, что я понял, было то, что, хотя сообщество вокруг статических сайтов в PHP может не создавать столько шума, оно очень живое и активное. На самом деле есть много вариантов на выбор! Для собственного здравого смысла я свел список до четырех SSG с наибольшим количеством звездочек на GitHub: Sculpin , Головоломка , Кускус , а также SНажать кнопку , Чтобы сделать несколько честное сравнение, я выбрал практический подход и попытался загрузить их и заставить их работать, исследуя, как они сделаны и как они заставляют вас работать. Для справки, я использую PHP 7.1 на macOS, а Composer 1.6 установлен глобально. На этой неделе мы исследуем Sculpin!

Sculpin (около 1200 ★)

https://sculpin.io

Вы, наверное, слышали об этом, так как он самый популярный в списке. Он основан на платформе Symfony, использует шаблоны Twig и поддерживает файлы Markdown. Поскольку я впервые пробую это, я буду использовать их официальную документацию, и особенно их Руководство по началу работы , Первое, что они просят, помимо установки Composer, - это загрузить каркасный проект и установить зависимости:

удар

1 2 3 git clone https://github.com/sculpin/sculpin-blog-skeleton.git Скульптура Компакт-диск Композитор Композитор Установка

Итак, во-первых, я получил целую кучу предупреждений при запуске composer install. Очевидно, что подпись какого-либо плагина Composer, предоставляемого Sculpin, не такая, какой она должна быть, поэтому она вызывает множество уведомлений об устаревании. Не сильно провалиться, так что давайте продолжим.

Как вы можете себе представить, меня больше всего интересует понимание того, как все работает под капотом. Поэтому я делаю то, что делаю всегда, когда нахожу новый интересный проект PHP: я смотрю на файл composer.json. Проект Sculpin по умолчанию требует (конечно) самого Sculpin, dflydev / embedded-composer, Assetic, а затем трио Bootstrap, jQuery и HighlightJS из организации компонентов. Если честно, я обычно предпочитаю, чтобы зависимости от внешнего интерфейса были отделены от моих зависимостей PHP, но я могу позволить этому скользить здесь.

Следующий шаг - взглянуть на собственный composer.json, созданный Sculpin, который находится в vendor /ulpin /ulpin / composer.json. Выбор установленных пакетов интересен, но здесь есть огромная проблема: все компоненты Symfony заблокированы в версии 2.3, которая действительно была LTS, но достигла конца срока службы около года. Взглянув на ветку разработки репозитория Sculpin GitHub, я вижу, что он использует версию 3.2 компонентов, которая лучше, но все же не идеальна - вероятно, она должна быть как минимум на 3.4, что является еще одним LTS. Я также заметил, что последняя стабильная версия Sculpin была опубликована около года назад, что побуждает меня искать информацию о ее статусе. Я быстро нахожу Сообщение блога где старый сопровождающий объявляет о переходе на новый, но это тоже давно, так что я не совсем уверен, что происходит. Если у кого-то есть более свежие обновления, пожалуйста, дайте мне знать!

Я решил, что сегодня меня это не волнует: Sculpin, возможно, уже великолепен и не нуждается в дальнейшей разработке, насколько я знаю, так что давайте вернемся к моему проекту. Давайте запустим сервер:

удар

1 продавец / бин / скульптин генерирует --watch --server

И мы живы! Давайте откроем URL и вот зрелище, которое Скалпин дарит нам.

Визуальные эффекты немного разочаровывают, но есть все, что нам нужно, из коробки. В настоящее время мы просматриваем версию веб-сайта, которая будет перестраиваться при каждом изменении исходных файлов.

Руководство по началу работы в значительной степени заканчивается кратким объяснением того, как мы должны добавлять сообщения в блог. Здесь я понимаю, что мне нужно взглянуть на документацию, так что дайте мне несколько минут, и я сейчас вернусь.

Структура каталогов

Sculpin хранит почти все в каталоге / source - за исключением некоторой конфигурации в / app - и создаст ваш сайт в / output_ {env}. Эта настройка «все в одном», возможно, удобна, но я бы предпочел иметь одно место для хранения данных, одно место для хранения шаблонов и, опционально, одно место для хранения кода или конфигурации, которая соединяет их.

На самом деле содержимое / source будет выглядеть так, как будет выглядеть финальная сборка, поэтому любой файл в ней служит определенной цели. Ваша карта сайта, ваш файл роботов, ваш значок, все они должны быть сохранены здесь. Это означает, что используемая здесь структура каталогов будет той же, что будет применена к окончательной сборке. Хотите иметь /project/something/something-else.html на своем веб-сайте? Хорошо, создайте этот самый файл в каталоге / source. Это, конечно, интуитивно понятно! Необходимо обратить внимание на определенные каталоги, названия которых начинаются с подчеркивания. Здесь у меня есть _layouts, _views и _posts. Здесь происходит какое-то волшебство Sculpin, поэтому давайте выясним, что это такое.

Как вы можете догадаться, каталоги с именами _layouts и _views связаны с форматированием определенных частей ваших HTML-страниц. Если вы что-то знаете о Twig и о том, как работает его механизм наследования, подумайте об этом так: _layouts будет включать шаблоны, которые вы определяете с помощью {% extends 'layout.html.twig'%}, они являются самыми внешними оболочками страниц вы собираетесь генерировать; Вместо этого _views предоставляет шаблоны для конкретного типа контента, которые в нашем примере сайта определены только для типа контента Post (поэтому у нас есть только _views / post.html). Если бы нам нужно было создать другой тип контента с именем Project (подробнее об этом позже), мы бы создали специальный шаблон в /_views/project.html.

В то время как связь между представлениями и шаблонами является довольно явной (представления имеют фактический оператор extends), способ управления сообщениями немного более неявный. Когда они отображаются, Sculpin автоматически сохраняет содержимое ваших сообщений в блоге в специальной переменной Twig page.blocks.content, которую вы затем можете использовать (не забывайте использовать фильтр | raw, иначе вы также избежите обычных HTML-тегов) ,

Теперь давайте посмотрим на каталог / source / _posts. Здесь мы находим несколько файлов: большинство из них являются Markdown, один написан с использованием Textile. Выбор велик, но лично я могу придерживаться Markdown и не сожалеть! Открыв эти файлы, вы увидите, что они представляют фронтальный раздел (блок YAML в начале файла), где вы можете определить дополнительные параметры, которые будут доступны в переменной страницы в представлении поста. Например, этот раздел:

YAML

1 2 3 title: Мои классные записи в блоге категории: - разное

приведет к page.title и page.categories. После начального вопроса все будет обрабатываться как тело страницы и попадет в вышеупомянутую переменную page.blocks.content. Кажется, ничего необычного или сложного. Если бы я хотел добавить новое сообщение в блоге, мне просто нужно было бы создать новый файл здесь, заполнить его содержимым, которое я хочу, и Скалпин подобрал бы его автоматически. Ницца!

Пользовательские типы контента

Сообщения в блоге великолепны, но они не являются конечными в жизни. Что если я хотел бы иметь тип контента «Проект», который я могу использовать для отображения своего портфолио? На страницах проекта будет отображаться что-то вроде заголовка, URL-адреса, возможно, некоторых тегов, объясняющих технологию, которую я использовал, снимок экрана и описание. Ну, к счастью, Sculpin позволяет нам делать только то Итак, чтобы создать пользовательский тип контента, давайте добавим это в разделulpin_content_types в /app/config/sculpin_kernel.yml:

YAML

1 2 3 4 5 6 7 проектов: тип: путь к пути: _проекты singular_name: макет проекта: проект включен: истинные таксономии: [теги]

Документация Sculpin достаточно хорошо описывает значение каждого ключа, поэтому я не буду это обсуждать. Вместо этого я бы предпочел сосредоточиться на чем-то другом: как вы можете видеть, мы не определяем какое-либо специальное свойство или поле, которые будут иметь проекты. Фактически, типы контента в Sculpin на самом деле не определяют, как структурируются данные, потому что концептуально элемент контента равен тексту и некоторым дополнительным метаданным . Это определение, вероятно, подходит для простых проектов, но отсутствие структуры может быть проблемой для более сложных веб-сайтов.

Готов ли Sculpin к содержанию?

Sculpin предлагает способы расширения, которые в основном вращаются вокруг создания пакетов и их интеграции в ваш проект. Я должен признать, что документация здесь его немного не хватает, так как он слишком часто сокращается, не приводя слишком много примеров. Что мне показалось особенно странным, так это то, что не существует четкого, предложенного способа добавления собственных сценариев, не прибегая к созданию полного пакета.

Мысль о том, что нужно создать реальный пакет Symfony, определить автозагрузчик в composer.json, зарегистрировать его в app / SculpinKernel.php (которого нет в скелетном проекте), а затем взглянуть на какой-нибудь сторонний код для понять, как подключить систему событий ... Ну, это может быть много работы, особенно если учесть, как сама Symfony отходит от пакетов, где они не предназначены для повторного использования в нескольких проектах.

Так что, если бы я настроил сайт Sculpin для импорта содержательных записей? Ну, проще всего было бы обойти это, а не с этим. Я бы запустил composer, чтобы загрузить наш PHP SDK , а затем, возможно, создайте файл contentful.php, в который я вручную извлекаю записи и собираю нужные мне файлы, которые я позже дам в каталог _source.

Однако идеальным решением, вероятно, было бы создание пакета, который настраивает прослушиватель событий очень рано в процессе сборки, а затем создание всех файлов, созданных из записей Contentful. Проблема, которую я вижу в этом подходе, заключается в том, что при каждом запуске Sculpin будет извлекать все записи из Contentful, что означает большие накладные расходы в ситуациях, когда, возможно, вы просто настраиваете шаблон. Лучшее разделение между содержанием и представлением, вероятно, поможет смягчить эту проблему.

решение суда

Sculpin - это не генератор статических сайтов, а генератор блогов, который также можно расширять для других целей. Он обеспечивает нормальные стандартные настройки для создания собственного блога (есть также несколько отличных сценариев для публикации его в корзину S3), и его достаточно легко взять и запустить, особенно если у вас есть некоторые знания о как работает Твиг. Он также основан на компонентах Symfony, что означает, что пакеты Symfony поддерживаются (хотя я должен признать, что я не пробовал их использовать).

Увы, есть несколько минусов, о которых стоит упомянуть. Наиболее поразительным является, возможно, устаревание базовой инфраструктуры. Конечно, с SSG вы на самом деле не публикуете этот код, но это все еще не совсем помогает мне. Более того, контент и презентация могут быть немного более раздельными: сейчас все помещено в один огромный каталог, что противоречит чистой архитектуре проекта (и, возможно, даже разделению интересов). Наконец, типы контента структурированы очень слабо, а записи данных рассматриваются как блок контента с некоторыми метаданными.

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

Похожие

Комментарии