Простой сайт на Symfony — есть ли смысл? Часть 2. Управление данными

В этой части подробно разберем создание админки для управления специфичными для сайта данными.

Напомню, что мы пытаемся быстро и эффективно создать на фреймворке Symfony 4.4 простейший сайт-визитку с панелью администрирования и оценить плюсы и минусы такого подхода в сравнении с WordPress.

В предыдущей части статьи мы сверстали сайт на html и установили Sonata Admin.


Оглавление


3. Бэкэнд. Специфичные данные

3.1. Создание админки для работы со страницами

Простая пошаговая инструкция тут.

После создания класса PageAdmin для администрирования страниц, и прописывания этого класса в services.html, у нас появилась неплохая админка для страниц, имеющая, однако, жирный недостаток в плане удобства редактирования html кода страницы.

В нашем конкретном случае, нам в первую очередь нужно, чтобы было удобно редактировать именно HTML страниц с максимальным контролем, то есть нам нужна подсветка синтаксиса HTML, а не WYSIWYG, как в большинстве случаев. Поэтому привяжем к textarea полям именно CodeMirror на этот раз, хотя обычно я ставлю TinyMCE.

В процессе установки CodeMirror нет ничего хитрого, кроме процесса привязывания нужного js и css в шаблон страницы Sonata Admin.

Процесс состоит из двух этапов. Прописываем новый шаблон страницы в конфиге:

Прописываем в новом шаблоне наши файлы:

В файлах admin.js и admin.scss, которые тут не приведены, у нас привязывается и инициализируется CodeMirror. После этих действий редактор кода в админке уже работает в нужных полях.


Так как в поле «h1» у нас записывается html код, в списке страниц это поле отображается прямо в html тэгами, что выглядит странно:

Поэтому нам нужно переопределить шаблон вывода поля «h1» в списке страниц. Это можно сделать так:

После того, как админка для страниц готова, создаем страницы, копируем наши ранее заверстанные страницы, и настраиваем вывод страниц из базы. В результате у нас есть инструмент для работы и html основных текстовых страниц.

3.2. Создание админки для работы с контактными данными

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

Безусловно, такой формат намного удобнее для пользователя, чем необходимость менять телефон во всех местах на сайте, где он используется.

На Вордпрессе, чтобы получить подобное, пришлось бы писать плагин, что, несомненно, отняло бы больше времени. Таким образом, несмотря на то, что установка WordPress явно попроще, чем установка Sonata Admin с медиатекой, управление данными в связке Symfony + Sonata Admin, на мой взгляд, значительно более гибкое.

3.3. Создание админки для работы со списком заказчиков

Сейчас наконец мы порадуемся тому, что потратили столько сил на установку медиатеки!

Сама сущность заказчика из списка заказчиков у нас очень проста и имеет всего два поля: название и логотип.

Первое, что нам нужно сделать, — создать в сущности заказчика связь с сущностью изображения. Класс сущности изображения — «App\Application\Sonata\MediaBundle\Entity\Media».

Затем настраиваем Sonata Admin для работы с полем изображения:

В результате, после небольшой доработки, получили такую админку с изображениями:

Админку для работы со списком объектов делаем по аналогии.

4. Сравнение полученного решения с решением на WordPress

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

СвойствоWordPressSymfony
Простота админпанели
В минималистичной админпанели, созданной специально для этого сайта, намного проще что-либо найти.
+
Гибкость админпанели для пользователя без навыков программирования+
Простота установки+
Yoast SEO
Минималистичных полей для ввода мета-тэгов страниц может быть недостаточно для SEO оптимизации конечным пользователем.
+
Работа с формами
Гибкость Symfony Form, особенно с учетом валидации, не знает равных.
+
Работа с базой данных
Doctrine ORM, безусловно, выигрывает у WPDB, особенно в связке с maker bundle.
+
Релиз
Поддержка различных окружений и отсутствие жесткой привязки к домену в Symfony радует.
+
Фронтэнд
Symfony Encore позволяет очень просто собрать фронтэнд на базе webpack, и минифицировать ассеты в продакшен окружении. Это, конечно, можно сделать и вручную для темы WordPress, но получается несколько менее естественно.
+
Производительность+

О производительности поговорим подробнее.

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

Ну а это — просто порадоваться! 🙂

Выводы

Выводы неоднозначные.

С одной стороны, делать сайт-визитку на Symfony как-то избыточно. Без Sonata Admin было бы совсем грустно.

В то же время, трудозатраты при разработке на Symfony превышают трудозатраты при разработке на WordPress всего лишь примерно на треть, что не так уж много.

Производительность проекта на Symfony очень радует.

Однако, настраиваемость проекта на WordPress из админки заказчиком способом «наклацать мышью» все-таки значительно выше. И, хотя мы не раз убеждались, что большие возможности, данные клиенту, приводят к большим проблемам с вероятностью, близкой к 100%, в дальнейшем, несмотря на все плюсы Symfony, WordPress списывать мы не собираемся.