Drupal 8 development is a closed discussion

Drupal 8 development is headed in the same direction as Drupal 7, a closed discussion on what could be achieved. I mentioned, in a previous article, Drupal 8 is headed for the same waterfall development approach despite repeated failures of the waterfall approach. Drupal 8 development appeared to open up into public discussion in pages such as [meta] New theme system. The discussions are not open.

An example

As an example, the theme discussion is aimed at introducing a specific change and any discussion towards something better is shot down in ways that discourage further discussion in that direction. I gave up. Every few days someone else tries to argue for the same steps forward and, so far, they all gave up. Some realise the open discussion is not open. Others just assume they are shot down by people with more experience or seniority.

The discussion is aimed at replacing a single theme layer with a new layer that does half of what the current theme layer does. The excuse is security but if security was the reason for the change, there are far simpler ways to implement the security.

The new layer does only half the work, which means they have to introduce an additional layer between Drupal and the theme layer. In most sites the new layer will have exactly the same security holes as the existing layer. We will gain nothing there. There might be a slight difference for a few hundred very large projects with many developers but not for the other sixty million web sites out there.

The new final theming template layer will be Twig, which is yet another template layer offering cut down script programming similar to early PHP. You lose all the flexibility of PHP and can only use the Twig layer to apply a coat of paint prior to the coat of paint applied by CSS and the final coat of paint applied by jQuery. You will still need a layer to structure the data and that layer will have the current lack of security and be used by the same theme developers as the current system.

Most of the theme developers argue the templates should be in the database where they are easy to develop. We already do this with most parts of Drupal including content types, fields, views, vocabularies, rules, and other stuff. Theme templates are almost the last item to go in the database and the technology is already available in Cel.

The closed argument against templates in the database is that templates are somehow magically different to everything else in Drupal.

The typical development cycle is to develop on a test system, test on the test system, then copy the changes to the production system. There may be a quality assurance system, a QA system, in the middle to allow extensive testing of a change while new development continues. git may be used to store the changes and to propagate the changes from one system to the next. Git handles text files, not database rows. There are ways to export data from a database and to import data into a database. When you use Twig, the database side does not matter because Twig compiles templates into PHP code, the compiled version goes straight into Git and is exported to QA then production. All your systems work identically.

If you add a small export of the template from the database to a text file, you can carry a copy of the source template with the file template.

The closed discussion does not like something so modern, free, and open. Instead they want to emulate the Features module. What does Features do? Features exports database entries as code to be shipped through Git to production. On the production system, Features does not install the data in the database to give you an identical system. instead Features attempts to emulate the database entries through function callbacks. The result is different. Some things work the same and some things are different. Features is a massive pain in the...(go look up PITA).

If we use the Twig approach to replace Features, we could solve a few problems including the lack of reliability in Features.

So the thought police in the theme discussion say there is not control over templates if they are in the database. Cel places templates in the database as a content type and we know Drupal has brilliant controls over access to content. If you have a lot of themers, you set up a Workbench to give them easy consistent access.

What about Git and the edited template? Using Cel as the example. Some implementations of Cel already have an export button for precisely that reason. The original Cel code was developed on a site using CVS, the grandparent of Git. CVS did not handle database rows. Cel exported to a file you could lock up in CVS. CVS then acquired an add-on module that collected rows from databases. The export was not needed. In a Drupal system, a Drupal based export and import is better because Drupal node versioning can be exported with the template then imported in other systems.

So Cel, or an equivalent, and Twig, or an equivalent, solve all the problems for everyone at the theme layer, including storing a copy of everything in Git, but the thought police do not want anything so easy because they want to keep all the current problems in place.

I mentioned the need for an extra later in the middle. That extra later will convert data from the open set of Drupal data into a closed set of data limited to whatever is required for the theme layer. There are several good suggestions, including drupal.org/node/1499460#comment-5825966, and they are all compatible with editing templates as content. The specific example of drupal.org/node/1499460#comment-5825966 is incredibly easy because it uses the existing Token system and the existing Token system has a very workable token listing facility ready to use in node content.

Lots of help

I mentioned the Cel and Token modules are already available. There are people working on a Twig library for Drupal 7. There are lots of Token helper modules, including Token ex and Token if, to provide general data to the templates. There are lots of data specific modules providing tokens. The growth in Drupal 7 tokens is sufficient to provide examples for developers handling the data layer between Drupal and Twig.

Most of the data layer modules work with Drupal access control and the remaining exceptions can be enhanced because there is a lot of example code.

Backport to Drupal 7

Because development has started on Drupal 8, everything has to be developed for Drupal 8 then backported to Drupal 7. There is actually nothing to stop people using a combination of Twig, Cel, Token, Token ex, Token if, and other modules in a theme for Drupal 7.