Drupal is quite popular and is recognized for its robust flexibility. Therefore, if the developer doesn’t have a hard time dealing with a particular task, then unfortunately the same thing cannot be said for the content manager (editor), who solely relies on additional directions.
With each passing year, the vision and the work experience related to content, has been constantly changing. This change includes, from editing content on special administrative site pages to editing directing only the public site page. Hence, Drupal 8 has been actively participating in evolving and improving in that direction.
Throughout the last few years, managing parts of the content has been significantly easier, but unfortunately same thing cannot be said about dealing with content management of the whole page. The similarity among the structure of the pages has a lot of influence on the time that will be needed to recreate pages with similar structure, ergo if a page needs to be added that does not exhibit enough similarity with the structure of the existing site’s pages, then this may require more time than expected from first glance.
Perhaps, a lot of people had dreamed that it will be possible someday to interact with the page via a constructor-like method. Today, this dream has been ratified into reality. Please meet the Panelizer! It doesn’t have anything that you haven’t seen before, it just simply broadens the capabilities of the well-known modules “Panels” and “Panels IPE”. The main difference is that the Panelizer can specify variant display for the already appointed entity, where as Panels IPE is more for all types of individual entities, aka - “bundle”. Also, unlike Panels IPE, the Panelizer permits to focus on specific fields instead of the whole bundle.
The Panelizer displays the insturments panel for the pages that were set up for the utilization of this module. It’s important to note, that the Panelizer allows to edit the structure of the page ( in essense, the “list” that we want to display), and not the content (for example the title of the page)! The result can be saved for the page being worked on (“Save as custom”), as well as for the pages of same structure (“Save as default”) (Drawing 2: Panels IPE and Panelizer are not displayed correspondingly). Thus, just like before, the module Panels has the capability to allocate elements of various types - blocks, contact forms, etc...
The module saves the settings of the individual page within its field, which allows to recall the previous versions by the help of the functionality - revision Drupal. Additionally, it's very convenient to export the setting along with the configuration of the content type.
Panels, Panels IPE, Panelizer greatly supplement the existing instruments used to edit the public part of the site. They allow to diversify the ways in which the content can be presented, and the method used to develop the functionality.
We’ve been using the Panelizer to obtain a maximum level of flexibility in administrating the web site and as a result we accomplished everything we intended and much more, without running into any bugs. To be frank, problems came up, but they were resolved easily without breaking any sweat.
In this overview I’ll try to describe a few of them from the editorial experience point of view.
Issues using the Panels/Panelizer
The major one is the messy toolbar. Unfortunately module Panels doesn’t provide any functionality to choose what items should be placed in that toolbar, so as a result we got something like this:
As you can see there are a lot of items in toolbar and almost all of them are useless for client (here I mean “editors”). The Panels module output all fields that it had been creating during development without filtering them at least by the type of content. After close examination, I’ve defined that there are two simple solutions to “fix” that issue - CSS and JS.
With CSS you just have to use rule display: none for items by attribute data-plugin-id and data-layout-id it depends what you want to hide.
With JS you need override via prototype Object items called renderCategories in panels/panels_ipe/js/views/CategoryView.js and template_item in panels/panels_ipe/js/views/BlockPicker.js
I've chosen JS. In my opinion it’s the more appropriate solution, because you don’t output unnecessary items, also JS is more flexible. So, here is the result:
Also Panelizer functionality gives you the possibility to move blocks on the page and save the page without reloading, which is pretty cool, but there is an issue with JS libraries - they aren’t initialized. My solution was - prototyping JS function.
Drupal.panelizer.panels_ipe.SaveTabView._save and force to reload page after ajax-call was done. This function calls every time you save page, so in other words - I forced to reload the page while panelizer was saving.
One more important bug is that collapsed panelizer toolbar is displayed over content with position: fixed and if you scroll the page to the end of the page you‘ll get a collapsed panelizer over footer. In this case, you won’t be able to use drupal’s contextual menu because it will be under panelizer block.
By default panelizer JS doesn’t add class to body on initialize, only when the toolbar is opened. So here I had to add the custom class manually and padding-bottom to body on panelizer init. And the last one that works for me is disable module’s css file and create new (my own) one. In that case I have access to theme’s css variables, mixins that adds possibility to customize color scheme or fix some bugs.
Panelizer is a great tool for building complex layouts. It gives your site as much flexibility as you need, while inputting minimum effort. But you should be prepared to troubleshoot and fix bugs after adding some custom feature. If you have something to add post your comments below.