How Symfony Station was built: an adventurous exploration of layout solutions

How Symfony, Drupal, Layout Builder, and Gutenberg became a crew.

Once Upon a Time, Not Long Ago, in a Nearby Galaxy

When I decided to found Symfony Station, the need for accessible, centralized, well-written, professionally designed news about the framework was so great, I felt I had to start immediately.

Thus, it began with the soft launch of a GoDaddy site-builder site. Its short life (like a test rocket flight) lasted less than a month while I explored how to build the permanent site.

I wanted the new site to serve as a gateway between WordPress (more on that below) and a CMS fully built with Symfony. As you know, it has a steep learning curve.

Note: Our site was redesigned in October 2023. However, the majority of the article still applies.

Our Developer Story

But before we get to the exploration, I want to give you a little bit of our backstory.

WordPress is my thing professionally. Incredible and exciting developments are going on with WordPress, including the Gutenberg block design system, Full Site Editing, and Headless WordPress.

My company is Mobile Atom Media - Digital Content, Simplified. It's built on WordPress and provides WordPress content solutions. Before 2018, I mainly used custom code via HTML and CSS tweaks of WordPress themes. I would also Google some functionality to copy and paste into the functions.php file.

My Coding Boot Camp Story

I saw that coding was a way to future-proof my career and wanted an additional skill set to use with Mobile Atom Media. This would eventually lead to the establishment of Mobile Atom Code - Worry-free Content Development & Management.

Plus, I wanted to take on a difficult mental challenge. And boy was going from the front end to the back end of the web just that. So, be careful what you wish for; you might get it.

Six months of anguish was all for this graphic.

Just kidding, I went through 24 weeks climbing Mt. Major Suck to learn how to become a developer. There was only one problem. The Boot camp taught Node.js, not PHP. :(

So, my final project was a custom WordPress child theme completed with no assistance from any of the instructors or tutors. But I did it.

If I had stopped then, I may have wasted most of what I learned and the money spent on it.

Thus, I then spent two more years climbing Mount Lesser Suck on my own to learn PHP and OOP for use in WordPress development.

I built a full OOP theme for Mobile Atom Media and began doing so for my clients. My time, effort, and money spent on the boot camp were not wasted. I am now a half-decent developer. ;)

For my next challenge, I’m learning Symfony via covering it through my new venture, Symfony Station.

Again, there was a problem; WordPress has minimal Symfony integration. And its use is mainly via plugins like WooCommerce. Also, I felt it would be hypocritical to use WordPress to cover the Symfony universe.

So, what is Symfony Station made with?

Symfony - Base

Drupal is built with Symfony tightly integrated. Its update roadmap is tied to Symfony's.

Components used include:

• ClassLoader
• Console
• DependencyInjection
• EventDispatcher
• HttpFoundation
• HttpKernel
• Polyfill Iconv
• Process
• Routing
• Serializer
• Translation
• Validator
• Yaml

 

It also incorporates Twig.

Drupal - Facilities Super Structure

If Symfony could be thought of as the base for Symfony Station, a Symfony inspired CMS could be considered its superstructure.

CMSs we explored extensively include:

• Bolt - liked it (3rd choice)
• Sulu - tightly integrated with Symfony (2nd choice)
• Drupal - the winner
• Grav - didn't want a static site

We also looked at:

• Fork
• EZ Platform
• Contao

Why we chose Drupal

1. It is a gateway between the WordPress and Symfony developer experiences.
2. Learning Drupal is good for our parent company Mobile Atom Media and Code on the financial front. Historically, we competed with Drupal but can now use it. Or we can compete more effectively against it.
3. It has an extensive community and ecosystem. Thus, it's well supported.
4. I had some experience with Drupal on the content creation side years ago.

Plus, Drupal is a DXP (digital experience platform) not just a CMS (content management system).

If you would like to see how Symfony works in Drupal I recommend the SymfonyCast, Drupal8 under the hood. Much of the content is dated, but it’s good for Drupal and Symfony noobie developers. Plus, you get another completed course on your profile.

It’s how I found the Devel module with all the cool dev tools it provides, including Web Profiler. And I learned how to create a custom page via a custom Drupal module with OOP PHP functionality. Hurray for controllers, routing, caching, configuration, service containers, shortcut methods, construct methods, and more.

I assume you can integrate custom Symfony programming as well.

Themes used and why

Unlike WordPress, Drupal has back (admin) and front end themes.

For the front we chose the EduX base theme and the EduXPro child theme.

These themes most closely match our desired branding and are clean with no 3rd-party modules required. Plus, they allow easy customization via CSS.

For the admin them we chose Gin.

The default Drupal admin theme at the time was dreadful. I think using it actually damaged my eyesight. ;) Once I learned the admin functionality (via tutorials that use the default), I dropped it.

Gin is beautiful in comparison. It's clean, cool, and collected with some customization options.

Drupal Layout - Buildings Exteriors

If Drupal can be thought of as the superstructure of Symfony Station, Layout Builder can be thought of as its buildings' exteriors.

In Drupal 8 the Layout Builder was added to core. They describe its functionality as:

"Layout Builder allows content editors and site builders to easily and quickly create visual layouts for displaying content. Users can customize how content is arranged on a single page, or across types of content, or even create custom landing pages with an easy to use drag-and-drop interface."

We went with this default technique for Symfony Station's articles and communiques. If we are using Drupal, we should stay with their solution whenever possible. Drupal calls posts an "article content-type".

Layouts are built with Sections that hold core Drupal blocks like "title" and "body" or custom blocks (that are built with Drupal fields).

Layout Builder "is a powerful system for managing layouts across an entire website. With Layout Builder, site administrators and content managers can place content from virtually anywhere (including custom blocks) within specific regions of a layout" according to an article from Aten.

On this page the tags, Symfony Station and Symfony logos section, separators, author section, and social share icons appear via the layout builder.

Layout Paragraphs (almost)

The Layout Paragraphs Module provides integration of Drupal paragraphs into Layout Builder. However, Drupal paragraphs aren't paragraphs. WTF?

Okay. Since I'm not a experienced Drupal developer yet, I will let SpecBee explain this:

"Drupal Paragraphs can be of different types. They can be anything from an image to a video or a simple text to a configurable slideshow. 

Instead of putting all the data in one body field, we can create multiple Paragraphs Types with different structures. This allows the end-user to choose between pre-defined Paragraphs Types.

By using Drupal Paragraphs, we can create multiple featured Paragraphs, allowing the end users to pick the one most suitable for their needs.

The Drupal Paragraphs module is easily manageable for non-technical users, while also offering Drupal developers the ability to control the appearance of the elements at the theme level."

Justin Toupin has posted that "the Layout Paragraphs module combines Drupal Paragraphs with the Layout API and works seamlessly with existing paragraph reference fields. This makes it dead simple for authors to build rich pages from a library of available components. It offers drag-and-drop controls for managing the content flow and layout".

In the future, I plan to explore the Paragraphs Editor Enhancements module to improve the UI of the editorial workflow during layout creation.

Morpht looks at some of the popular Drupal layout combinations over the years and gives them over all scores, weighted by functionality and editor experience in this table.

These scores come from a weighted average of various parts of the techniques: flexibility, control, editor experience, etc.

So, I am confident this is the best approach for layout in Drupal articles and will use it for ones in the future.

Note: April 2022 -> I changed and used the Gutenberg solution below for articles as well. It's just ten times easier.

Other Solutions

I also explored the Rocketship and LayoutComponents Drupal modules. Installation problems and too many required modules cost these a chance, respectively. Which was a shame for Rocketship since I like the way it looks and its name. ;)

Gutenberg - Exteriors

For Symfony Station's pages (called "Basic Page" by Drupal) and as of April 2022 for articles, we use an integration of Gutenberg blocks via a module. Currently, this is the best solution for us.

Gutenberg provides a library of component blocks. The Drupal module is not as extensive as WordPress's core and plugin block solutions. Although, the module contributors may just be waiting for the final implementation of the block ecosystem in 2022's WordPress 5.9 before they build it out for Drupal. If you would like to explore Gutenberg's Drupal functionality see this post.

You can also use the code editor. With it you can paste and customize code from:

• Gutenberg Hub - Create an entire page
• WordPress Patterns

Like WordPress, the module provides fully customizable control via the ability to create custom blocks with PHP or the WordPress REST API with JavaScript (including React). As mentioned earlier, we have experience with this block-based approach to layout.

And frankly, it's just easier to use than the Drupal editor.

 

Other Exteriors Solutions

We also reconnoitered Twig, Custom Drupal Modules, Tailwind CSS, AlpineJs, and Hotwire/StimulusJS. The first two can be used with Drupal. The others not so easily, unfortunately. I hope StimulusJS makes its way into Drupal.

Starmap to Possible Futures

We will continually tweak and improve the current design.

And there are unlimited options for a future Symfony Station redesign. They include the following.

 

A Custom Drupal Theme

This would be the next logical step. I might even build a custom theme that looks like the current one with bespoke functionality as an interim solution.

Our new design from October 2023 is a heavily customized child theme of Olivero.

 

Sulu CMS

I liked the back end of Sulu as it is built entirely with Symfony. You can customize it with Symfony programming as well.

Plus, it has headless capabilities, which will be more important in the future. But I need to become a better Symfony and Javascript developer before taking this route.

This is still true for 2024.

 

Symfony CMF

I was waiting for version 6 and wanted to gain more Symfony experience before I took this on.

These SymfonyWorld Winter 2021 Online sessions will be helpful for future redesigns:

• Vulnerabilities and Security Round Trip
• Runtime Component: The Game Changer
• Dealing with Dependency Troubles
• Symfony Components and Design Patterns
• Symfony Backwards Compatibilty Promise
• Everything for Symfony 6
• Using the Security Bundle in Symfony 6
• Tools for Updating Symfony Applications
• Working with Twig in Symfony
• Symfony and Docker
• Give your Site the SPA feel with Turbo

Taking this path will depend on what the future brings for Mobile Atom Code and Symfony Station. It might have to wait till I "retire" in ten years. Although, hopefully not.

Symfony CMF has been retired. Before me. ;)

The End

Thanks for reading the adventure (aka case study) of how Symfony Station was built. I hope you learned some things about Drupal, Gutenberg, even Bootstrap, and myself.

Happy coding Symfonistas!