I've been working on a personal site that I've maintained since before I even got involved with Drupal. It's been iteratively migrated and upgraded from those early days on pmachine to its current iteration on Drupal 7. Obviously, I've been planning to upgrade it to the newest Drupal 8. All in all, this has gone pretty well, but as a big contributor to Layout Builder, I really wanted to use it on the site as much as possible. This hasn't gone anywhere close to how I would have liked. :-(
What's wrong with Layout Builder?
In a word: "nothing". Layout Builder does exactly what it says on the label and it does it well. At first, most of my issues were easily solved by building new field formatter plugins. I built a "Heading" formatter so that string data (like titles) could be turned into h1s or h2s via the user interface. I built an SVG formatter for displaying dates. I was rocking and rolling, and really enjoying the process. However, once I stopped to look critically at my ACTUAL layouts, I wasn't very happy. Layout Builder, like page_manager/panels/display_suite before it, is limited to the pre-existing layout plugins in the system. While the 33/66 & 66/33 layouts had been great for roughing in the site, they were falling desperately short of what I actually wanted. This left me with 3 options:
- Abandon Layout Builder in these cases, and use old school css to style my entities.
- Build custom layout plugins for each use case (and I have a bunch).
- Build a single custom layout plugin that could be configured however I might need situationally.
Initially, I did a lot of 1. As the site stands right now in my local development environment, this is the choice I've taken. It really rankles me. I KNEW I wasn't going to do 2. I've been down that road before, and while Layout Builder has a bunch of great options for limiting how users might experience a situation like that, I really didn't want to write and maintain that many new layouts and control when they are or aren't available.
While adopting option 1, I made myself familiar with css grid. Full disclosure, it doesn't work in IE 11. Also full disclosure... I couldn't care less. CSS grid is GREAT! I think most of us got into web development at the front end. At some point we've all been the one-stop-shop for everything we wanted to get done. So, as page layout tools have evolved, doing the sort of CSS I used to spend hours on has become a simpler and more elegant process. Elegant enough to attempt building a tool around. Now, I'm certainly not the first to do something like this. Both inside and outside of Drupal, other tools have and do exist. Merlinofchaos built a flexible layout plugin builder in Drupal 6/7 for panels, but things like flex & grid were a distant dream at that time and so the implementation was much more difficult, and had some interesting side effects for deeply nested regions. Having a new version of that idea built on new standards has been a personal goal for quite some time.
So with that small introduction, I give to you the Grid Layout module. This is a first pass at building the most basic version of what I wanted. Grid Layout provides a new configurable layout plugin with two form elements. These form elements conform to the grid-template-columns and the grid-template-areas css properties. By implementing these two properties as configuration, we can extrapolate how many layout regions to create, and we use the raw css to style the divs.
Stuff to do NOW!
I have form errors in my code, but they aren't showing, and even I got confused a couple times when I did the css wrong and it wouldn't submit. Clearly, something changed since the last time I did this, so I should square that away sooner rather than later. Patches welcome :-)
Also, there's very little validation on the user input... the danger is probably pretty mitigated by the fact that most sites wouldn't allow untrusted users to build layouts, but if you are doing that, consider this a warning.
Stuff to do LATER...
Currently, I'm writing the css directly into the inline styles of the divs. CSS grid is simple enough that I'm actually ok with doing this, however in the long term it might be nice to dynamically generate css library definitions for Drupal. It seems very doable, I just haven't double checked that all the on-screen events have some programatic API I can use for doing things like cleaning up libraries that are no longer used.
Better css grid spec integration... What I did here is SUPER basic. It communicates the possibilities I think, but grid can do a lot.
This thing could also use a really awesome UI. Initially I tried to build an ajax-y solution for this, and while I find Drupal's form ajax system super aggravating (a blog for another day perhaps), building a UI that communicated what we were ACTUALLY doing proved a much more difficult and abstract problem than I wanted to solve (seeing as how I do have a site I'm in the middle of upgrading).
And now... a quick demo:
Interested in any feedback you might have.
I've been hacking around with Layout Builder for a couple of months and I want to first thank you for sharing your efforts. I've found examples of how people are modifying or making the most of Layout Builder in interesting ways to be scarce.
My efforts (https://github.com/omnidoes/omni_layouts) have mostly focused on creating a configuration for sections that gives content creators the most common options (alignment, layout, background) for a given layout. If a user selects a 2-column layout, there are options to split those columns 50/50, 25/75, etc. It's okay for simple use cases but omits a lot of the complexity that comes with responsive layouts.
I also need to update my module to include a base set of templates/css, enabling the theme to override layout templates as wanted.
One of these days I hope all these individual efforts will get rolled up into a big suite of common section design configurations.
Hey Kris, I'm really excited to see this. :) Thanks for all your hard work and I'm excited to see what the future brings to the project.
Thanks for making the world a better place!
Thomas (not verified)
By building new field formatter plugins. I built a "Heading" formatter so that string data (like titles) could be turned into h1s or h2s via the user interface.
Have you tried fences? Alot easier for those simple markup changes: https://www.drupal.org/project/fences
Building it as its own field for matter lets me build up a set of common tools that I can take with me. I’m not against modules like fences, I just don’t usually use them.