The article compares current solutions for creating heterogeneous publications and landing pages, as well as longrides in the administrative interface of CMS Drupal . Heterogeneity is understood as the possibility to embed arbitrary interactive elements, such as media frames, lists of relevant materials, questionnaires and other non-text elements, into the text in an arbitrary place. The author's top based on the analysis of 16 critical parameters.

Anyone who often develops websites in Drupal sooner or later faces the need to provide editors with a convenient interface for creating and editing so-called “rich” story pages or landing pages: pages with complex internal structure, layout, interactive elements, internal navigation and personalized in blocks.

At the same time, one landing page or story may be completely different from others, both in content and in structure, the background images used and the set of elements already mentioned.

Examples of tools for creating full mini-sites not from the world of Drupal include commercial services such as Weebly , Wix , which offer features comparable to the requirements, as well as paid plug-ins for Wordpress such as Visual omposer , Qards or Beaver Builder .

In recent years, Drupal itself has formed a fair number of approaches to implement the required functionality, which to some extent meet the intuitive requirements: “so that it has a wow effect”, “do it like this”. And since the options, how to do it all, there is a big headache - finally decide: what to choose? If all of them, in principle, allow to achieve a result ...

Intuition is intuition, but some normal weighted approach is needed. After all, maybe by a combination of criteria, if we consider them separately, a clear leader will appear? You can try, just need to decide what criteria exist in nature for such tools in general.

If you think about it, you can guess that there is no need to go far. On the basis of modern requirements for CMS, it is possible to distinguish a subgroup of requirements for tools for creating deeply customized pages or landing pages, since, in fact, they are mini-sites, or sites in the site due to the large difference from other pages.

Following this observation, we use the following criteria for analyzing and comparing approaches (sorted by importance in ascending order, based on our own experience, that is, subjectively):

1. Quality of implementation (compliance with Drupal standards, availability of documentation, potential extensibility by third-party modules, in general, DX);
2. UX (usability administrative interface);
3. Temizability and adaptability (the ability to create and edit templates in a flexible and unified manner, the required temization efforts from scratch to an acceptable type);
4. Internationalization and localization (support for multiple languages);
5. Support for revisions and moderation (the ability to "roll back" to previous versions of materials; support for draft versions);
6. Drupal 8 support;
7. Functionality out of the box (the number of standard elements, blocks, lists and other things);
8. Configurability and extensibility (number of settings, current extensibility by third-party modules);
9. Performance (from the administrative interface and from ordinary visitors to the site);
10. The abstractability of output (the possibility of rendering in non-HTML formats);
11. Semantic conclusion (microformats, RDF support, accessibility for people with disabilities);
12. Access control (support roles and access rights);
13. Background information and documentation (as well as the level of provided or potential support in the event of problems);
14. Reuse (the ability to clone pages, group and reuse layouts);
15. Testability (availability of ready-made automatic tests, as well as the ability to write new ones);
16. Exportability (possibility to export and import pages).

Approaches

When considering the alternatives below, the emphasis is not on listing their basic capabilities, but on identifying the key factors affecting a particular rating, which are of direct importance when compared with approaches that occupy neighboring places in the rating.

Panels

Probably the most "ancient" tool for creating landing pages in Drupal, the main component of which - the Panels module - leads its own history from Drupal 4.7 .

With a built-in system of contexts, variants, a mock generator, and its cache plug-ins, the module has long been a combine, without which it was difficult to imagine the creation of heterogeneous pages. The sheer number of settings and features is so huge that if you include their description in this article, then it will be larger in size than the article itself.

The functionality of the module is greatly expanded with the help of Panelizer , which allows processing arbitrary nodes through panels, dividing the monolithic content into parts, placing it in different columns, and much more.

To create arbitrary text sections on the pages, the Bean or Fieldable Panels Panes modules found their use, which added the ability to streamline their content and use regular fields instead of the only textarea that was initially possible.

There are several variations of this approach. Common is the use of Panels and Panelizer modules.

1. Fieldable panels panes
2. Beans

Drupal 8 requires the use of additional modules: Page Manager , Layout Plugin .

The most impressive demo of this approach can be found in the Panopoly module.

Among the additional modules that extend the functionality and are used quite often, we can distinguish:

1. FPP Bundles
2. Drupal Panels Preview
3. Panels Everywhere

Benefits:

1. Giant ecosystem of modules
2. A huge number of settings to control the visibility of elements
3. A large number of active users

Disadvantages:

1. Overloaded interface
2. Somewhat difficult localization
3. Weak revision support

Nested fields and entities

Field Collection, Multi-field

The module that appeared in 2010 was a real breakthrough, because it allowed to completely rethink the structuring of the content in Drupal, without the need to use the miraculous crutches in the form of serialized data. Prior to his release, as a rule, all data relating to the fields were stored directly in the table of values ​​(or revisions) of the field. That is, one field in the bundle - one widget - one formatter - and infinity of the same type values.

(With the serialized data, everything was somewhat simpler - so the Flexifield and Composed Field modules made it possible, in principle, to get several others from one field, but you had to pay for it with the inability of normal sampling or filtering by nested fields using the same Views. Although who knows, maybe these modules will get a second life due to the appearance in MySQL 5.7 JSON datatype ).

But what if the meaning of the field value is in fact component? For example, cost, where, in addition to the value of value, there is a currency, or weight, where in addition to the weight value, there is a unit of measurement.

All this allowed to do the module Field Collection, which in its essence made it possible to use the fields inside other fields.

Nowadays, the module is still actively used, and not only for creating the mentioned combo-fields, but also for creating infinitely nested content structures. What, however, we can safely recommend not to do, due to the presence of a more flexible following alternatives in the review.

Benefits:

1. Maturity decision
2. A large number of free modules that extend the functionality
3. The rapid development of 8.x branches using the Inline Entity Form

Disadvantages:

1. Inability to create content variants without crutches (for example, to support omni-channel)
2. The inability to choose an alternative bundle for each new field value
3. Lack of reusability

Paragraphs

The Paragraphs module appeared in 2013 after the Field Collection, and, apparently, was created to fix one fundamentally missing collection capability — the ability to arbitrarily specify a different bundle for each added field value. The functionality, initially being only an extreme case of using collections, led to monstrous crutches if developers tried to start using collections not to store homogeneous nested data, but rather to create complexly structured pages.

Despite the impressive possibilities, this approach only recently began to receive increased attention.

A wonderful lotion to paragraphs is the Paragraph Panes module, which allows you to create paragraphs right in the panels. Among the most important features is that the elements created in this way are not entities, but only the configuration of this particular panel. This means that if you panelize a certain node and add Paragraph Panes to arbitrary places, then you will get out of the box to support revisionity not only for the node, but also for paragraphs in the panels.

Benefits:

1. Huge flexibility in creating nested materials
2. Possibility of use in panels as a configuration
3. Excellent community support

Disadvantages:

1. Inability to create content variants without crutches (for example, to support omni-channel)
2. Lack of visuality (for example, normally shown nesting) when editing
3. Inability to move nested paragraphs to other parents

Inline Entity Form

As it is known in Drupal, you can easily make a field reference to arbitrary entities using the Entity Reference module. But, what if the entities to which we plan to refer, does not yet exist in nature? Right! It needs to be created (cap). And for this it is necessary to switch to another form. Enter all the values ​​there, save the result. Return to the form of the material where you plan to link. Find the required entity and click "Save." Everything seems to be wonderful, only 100500 actions are real.

This problem is well solved with the help of the Inline Entity Form module.

IEF is a rather old module, which appeared already in 2011, for simultaneous editing of the current material, as well as the materials to which the current material refers or will refer.

However, the entities embedded in Drupal (nodes, taxonomy terms, etc.) are not quite suitable for the tasks of storing structured data, as they have "attached" in the form of special access control, heaps of third-party hooks that react to any actions and much more.

Fortunately, there is an Entity API in Drupal, an interface that allows you to create your own arbitrary entities by implementing a couple of special hooks. The Entity Construction Kit module is a tool that allows you to easily create your own entity types with an arbitrary set of fields, widgets and formatters, without resorting to programming at all.

Now only one thing is missing for storing vaguely nested structured data - the ability to select an arbitrary bundle of the entity referenced. The recently appeared module called EntityReference Dynamic Bundle allows you to do this. This means that links to not only different entities, but also arbitrary bands of these entities can be stored in one field.

By combining all these three modules together, you can get a curious mix, reminiscent of the Paragraphs module, only more abstract, which allows you to get extremely powerful functionality for assembling an arbitrary data structure from pre-created atoms (entities created using ECK).

At the same time, unlike paragraphs, it is possible to reuse sections created once. If we add an additional Inline Entity Form Preview module to all this good, we will get an additional preview functionality.

Benefits:

1. A high level of abstractions that allows you to extend the functionality by borrowing modules from rich ecosystems around each of the three key modules (since these modules are independent).
2. The ability to reuse entities.
3. Performance problems when editing a large number of entities at the same time.

Disadvantages:

1. A large number of modules to implement the required functionality. If the community “scores” on one of the key components, there will be a problem with support.
2. Somewhat overloaded interface.
3. Not everything is ported to Drupal 8.

Note. There is also a Bricks module, consisting of only 200 lines of code, and based on the ECK and IEF modules already mentioned. This module allows you to distribute the mentioned entities in columns, and also provides an interface out of the box for setting CSS classes. Bricks could well claim to be a full-fledged alternative if we are not half dead and extremely small in number of installations.

Layout and content in text box

CKEditor Widgets

Of course, no one forbids taking and writing arbitrary HTML in the Body text field to make a longrid or landing, but can a person who does not know him do it? And is there any point in spending hours or even days on it?

On the other hand, there are visual editors, such as TinyMCE or CKEditor . Who seek to do everything "as in Word'e." Just pushing the table is enough ... Unfortunately, everything turns out again not so simple.

Anyone who has been actively working with these editors knows about one typical “disease”: an unsuccessfully pressed backspace, a copy that is not so done, and everything — there is a much greater than zero probability of simply breaking the layout. Sometimes hopeless (to fix, you have to go into HTML).

The Widget API, which appeared in the CKEditor editor a couple of years ago (the editor is now built into Drupal 8), is intended to solve this problem. Using the Widget API allows you to create correctly moved and copied complex sections, which are interpreted by the editor as a whole.

On the other hand, the last years in web development are somehow connected with the rapid development of the CSS framework Bootstrap , which allows you to simply typeset complex layouts, in many ways using only the special naming of classes.

And the appearance of special Bootstrap-compatible widgets in CKEditor was only a matter of time. So it happened.

At the moment, a suitable, albeit damp, approach is to use the modules CKEditor Bootstrap Bundle , CKEditor Bootstrap Library , CKEditor Widgets , to add a number of buttons and functionality designed to make it as easy as possible for the user to create complex layouts in the text field using a visual editor.

Benefits:

1. Great proximity to the final result in terms of preview
2. Arbitrary dragging
3. Excellent support for revisions, translations and moderation (due to the encapsulation of the nested structure in the text field)

Disadvantages:

1. Anyway, the remaining probability of "breaking" the layout
2. Small library of Drupal elements out of the box
3. The inability to flexibly operate with separate encapsulated elements at the DrupalAPI level

Shortcodes

As you know, Drupal has a concept such as tokens (otherwise shortcodes in some other systems), which in essence allows you to dynamically replace special sequences of characters in the text in square brackets with arbitrary data. For example, [current-user: name] defaults to the name of the current user.

On the other hand, single tokens or shortcodes are not all options for using special square brackets. With a pair of similar tokens (opening and closing), it is quite possible to perform logical markup of your text so as not to resort to direct layout of complexly structured text using HTML.

As an example, we can fully consider the use of shortcodes to designate columns, for example, by framing the necessary text in [col] and [/ col]. It is enough to implement the conversion of tokens into the corresponding tags with certain classes and styles, for example, with the Bootstrap framework . It seems to be all fine. If it were not for one "but."

The reality is that in Drupal, the use of shortcodes was much less developed than in Wordpress, and therefore almost all existing ready-made solutions cannot be called really powerful in terms of integration with Drupal itself.

Although the use of shortcodes allows, in principle, not to use visual editors at all, such as CKEditor, or to minimize their use, which for some users (for example, those who don’t like gui) can be quite serious help.

For another camp of users who still want to have a convenient visual interface for arranging complex layouts (for example, multi-column without using tables) in a visual editor, there are ready-made solutions, such as the VCL module (albeit raw, and only for Drupal 8), as well as Drupal Visual Shortcodes , which provide a convenient interface and a relatively rich library to the element, still using the same shortcodes under the hood.

Benefits:

1. Quite good extensibility
2. Alternative interface layout complex layouts
3. Excellent support for revisions, translations and moderation

Disadvantages:

1. Not everyone likes the text interface (in principle, it is leveled by using tools for visual editing)
2. Almost all available solutions are still raw.
3. Impossibility to operate with separate encapsulated elements at the DrupalAPI level

Own solutions

MD AweContent

MD AweContent is a commercial solution for building complex pages. It is distributed through Codecanyon and costs $ 32 at the time of writing. The cost includes support for 6 months, which, nevertheless, does not include any refinement of the file, although it promises help with fixing bugs.

Among the remarkable features we can mention a rather original drag & drop interface, as well as saving layouts and data in a serialized form in a special table.

Benefits:

1. The original and quite convenient interface for editing
2. Rich visual appearance management features
3. The ability to reuse items

Disadvantages:

1. Poor support for internationalization, revisions and moderation
2. Inability to flexibly control access to items
3. Lack of support for Drupal 8

Drag & drop builder

Drag & Drop Builder is also a commercial solution distributed through Codecanyon. The price of the product at the time of this writing is $ 28. The cost includes support for 6 months, which, nevertheless, does not include any refinement of the file, although it promises help with fixing bugs.

Notable features include the original implementation based on Drupal fields that store serialized data.

Benefits:

1. Convenient drag & drop interface with arbitrary nesting support
2. Drupal 8 support
3. Realized export and import

Disadvantages:

1. A small number of items out of the box
2. Rare update for commercial products
3. Not enough good quality code

Azexo composer

The original paid page builder, which appeared in 2014, is now completely free to download on GitHub.

Among the features you can highlight the implementation with a filter, support for shortcodes, as well as the fact that the entire layout and data are stored in an editable text field.

Benefits:

1. Free drag & drop solution
2. Good presentational opportunities
3. Nice Bootstrap support

Disadvantages:

1. Bad code quality
2. Lack of support for Drupal 8
3. No updates

Carbide builder

The Carbide Builder visual editor based approach is, at the moment, one of the most prominent players in the market for commercial modules and themes for Drupal.

Partly inheriting from Azexo Composer functionality and interface, Carbide Builder introduces a number of significant improvements in terms of features and items out of the box. As in the Azexo Composer, the entire layout is stored directly in the text field.

The module is distributed along with the theme with the commercial version of the Glazed theme and at the time of this writing is $ 48 in the United States per year per domain.

Benefits:

1. A large number of components and ready-made templates.
2. Inline editing in Drupal 7
3. Bootstrap 3 support

Disadvantages:

1. Lack of support for Drupal 8
2. Overloaded layout
3. The inconvenience of editing on mobile devices

results

In the course of subjective assessment of the considered alternatives, points were awarded (on a scale from 0 to 5) for each of the criteria, and an aggregated weighted result was calculated, taking into account the relative importance of each of the criteria separately:

1. Paragraphs (3.68 points)
2. Glazed, Carbide Builder (3.65 points)
3. ECK, Inline Entity Form (3.63 points)

(marks for each of the criteria, as well as a complete list of results, are not specifically mentioned so as not to provoke disputes over non-conceptual issues)

Thus, according to the aggregate of 16 criteria, the Paragraphs module became the winner, as well as the approaches based on it, which correlates well with the growing global interest to it.

At the moment, paragraphs in conjunction with the Panelizer and Mini Panels modules allow you to do real miracles in terms of data layout flexibility with a virtually zero level of programming required and time consuming. If you or other users familiar with Drupal are the end users of the developed site, then the best approach is now difficult to find. The happiest person to use this approach is the site builder and developer of distributions.

As for the other approaches, it is very important to note that the gap between the alternatives is practically minimal, and one place or another can be determined on the basis of 1-3 criteria. What, however, explains the large variability in the tools used at present.

If your site is focused on a small business, a blog or something similar, or if the “wow effect” for sale is critical for you and the end user of your system is never a site builder, or you simply lack some desire tightly to engage in resource support, it is better to first pay attention to paid modules and topics based on a full-fledged attachment of Bootstrap 3 to text fields and with a trendy interface. The happiest person from using this approach is a non-technical specialist working with the site, a designer or a marketer .

And finally, if the solution being developed is very complex and large in terms of resources attracted, access control, microformats, personalization, localization, etc., it may be appropriate to use the second-place approach based on nested entities and ECK. Although it will have to somehow solve the problems associated with performance and somewhat unfriendly UX for the authors. The happiest person to use this approach is a leader or architect of a complex product with large resources.

As you can, with some surprise, notice, the panels, as an independent and main tool for creating landing pages and longrides, completely dropped out of the top. Although they continue to be actively used as an auxiliary file, mainly due to the presence of a panelizer. This was largely due to some monstrousness of the version for the seven, the lack of versioning, normal work with languages, and also sluggishness in terms of UX. But in terms of prospects, and especially if we take into account the latest progress in terms of UX in the version for the eight, with due effort, the community may well return to it in triumph. Strangely enough, the winner will be under the greatest threat - paragraphs - as the demand for the maximum abstract architecture and easy visual wow interface will probably always be.

And to make an abstract wow interface to text fields is much easier and more profitable (read WYSIWYG 2.0), than to make the same interface tied to structured data. In spite of the fact that text blobs on the side of information architecture is awful . Since in the first case there is practically no restriction on the use within a particular CMS, and - the binding is more likely on a specific frontend grid framework.

The author is very grateful to Vitaly Kuzmenko for his indispensable help in working on this article.