Abandoning Drupal 8

Written 1 September 2017. Last updated 9 September 2017.

When a change in my web hosting setup finally allowed me to meet the PHP version requirements for installing Drupal 8 I switched most sites back from HTML/CSS to that latest version of Drupal. When the launch of Drupal 8 was announced I began writing a book on single person businesses using Drupal due to my fondness for its Book module (for grouping webpages into a structured book format) and its Views module (for producing lists that the site visitor can alter to suit their needs). I mothballed the project because it was important that using Drupal was made as easy as using WordPress and the move to Drupal 8 appeared to abandon the non-enterprise sector by requiring a PHP version that many cheap web hosting services struggled to meet. The one-click installer Softaculous was used by my host Smart Hosting and although I could set a higher PHP version Softaculous refused to recognise anything but the host's default version, which was too low for Drupal 8. The problem was resolved by the completion of Smart Hosting's merger with the systems of its new owner Krystal. That gave Smart Hosting customers access to the Installatron one-click installer that properly recognises the PHP version in use. This then allowed me to transfer sites to Drupal 8 and consider resuming the Drupal book, of which 20,000 words were already written from a Drupal 7 perspective. It seemed that Drupal 8 was working fine when I transferred the sites, but too many issues have arisen where the system has degraded its functionality since Drupal 7.

Editor

A major change in version 8 Drupal was that it caught up with its rivals in offering an html editor out of the box. Previously the default installation provided only plain text editing and a module had to be downloaded and installed for html use. The most popular choice was CK Editor and that is now installed as part of the default installation (or Drupal Core). The problem is that this removed the configuration option to allow text formats access to the web browser's spell checker. The Drupal.org website claimed that this was being fixed, but as of September 2017 there remains no in-built way to allow spell-checking in CK Editor. This is a prime example of why I first abandoned the Drupal book: the sense that the Drupal community was abandoning non-enterprise users. To go so long without an html editor in Drupal Core showed a reluctance to fully reach out to the non-enterprise sector, but Drupal had with version 7 sought to win back some of the massive differential between websites it powered and the vastly more successful WordPress. Introducing CK Editor into core was a massive step forward, particularly when coupled with in-place editing, which meant that the user could click an option on the web page, rather than be taken away to admin mode. That meant Drupal 8 catching up with Joomla and overtaking WordPress, which still requires editing to be done within the admin dashboard. By not implementing either a spell checker or the Drupal 7 ability to give access to the browser's spell checker the Drupal community is giving a clear signal that it is no longer interested in competing in the non-enterprise market. Worse was to come for my attitude to CK Editor in Drupal 8 when I realised that what I thought was a Views module bug, was in fact a problem in CK Editor.

Views

The Views module has been the success story of Drupal and is one of the major reasons that I was writing a book advocating its use rather than the ubiquitous, but limited, WordPress. For some users the fact that Views was a third-party module presented security concerns and so bringing it into Drupal Core was a major recognition of how vital it was to Drupal's appeal. Unfortunately the implementation is buggy. A useful feature of the Views module was that it showed a preview of what your view settings would produce in the page seen by a site visitor. Unfortunately in Drupal 8's implementation that preview function is broken, although searching Drupal.org again claims that this is a fixed bug. This is a major problem for advocating that Drupal is easier to use than WordPress. I could draw on my Drupal 7 experience with the then independent Views module, but even then I hit the buffers when the only view I set up from scratch failed to update, not in the preview (which does not work at all) but on the final page. My main reason for loving the Views module is the ability to give the user a list of articles available on the site and even alter the order if I set it up in that way. On a site with only two articles on it to date I created a view using the settings I would have used on Drupal 7. It was frustrating that the preview did not work, but the two articles appeared in the list. I began putting together this article on abandoning Drupal 8 because when I published a third article the list did not update to include it. On further investigation I discovered that the problem lay with CK Editor. While working on that third article I selected the Save and Not Publish option in CK Editor. Subsequent edits showed the option as Save and Keep Unpublished, so when I finalised the article I used the drop down list to select Save and Publish. Despite doing so as the all powerful User 1 (meaning all permissions automatically apply) when I checked the Content list in the admin section I discovered that the article remained unpublished. So Views may be buggy only in regard to its broken previews, but overall this is unacceptable for Drupal 8, which was declared ready for production use in November 2015.

Themes

One of WordPress's major selling points for single person businesses is the huge collection of themes that give a distinctive look to the website. The downside of WordPress is that most advanced features are only accessible by re-coding the theme or writing a theme from scratch. This is a consequence of WordPress's origins as a blogging platform, whereas Drupal was a content management system from its first public release (although it started life as a messaging system developed for a student dorm). Drupal has the advantage that those advanced functions are part of the core system and without knowing any code a non-technical user can set up fairly advanced features through the point and click administration system. Themes in Drupal are therefore limited to presentational matters, but an unfortunate change in Drupal 8 has led to a lack of usable themes. Drupal previously used PHP for coding its themes, but those themes are unusable because it has switched over to its in-house Twig system. This might help enterprises who retain Drupal engineers on their staff, but those reliant on pre-made themes have found their choice dramatically limited. In the nearly three years since the launch of Drupal 8 very few themes have been converted to Twig and the older PHP themes are incompatible with Drupal 8. There is not even a beta version of my favourite Drupal theme, Zeropoint, and most themes available on Drupal.org (the preferred source due to security concerns over themes hosted elsewhere) are aimed at professional site designers. In other words they are base themes that a site designer uses to build a bespoke theme for their clients. Even some of the major base themes are still in beta for their Twig version or have only recently released stable versions. For example Adaptive Theme went stable in March 2017, 16 months after the release of Drupal 8. Meanwhile the more popular Omega base theme has only got as far as an alpha release for Drupal 8, and the even more popular Zen has not even got that far. This is partly because many designers object to newly restrictive requirements for hosting themes on Drupal.org and Drupal 8 themes (e.g., from Zen) are downloadable from Github. That removes the security reassurance that comes with downloading themes from the Drupal website, which helps converts from WordPress, who were used to obtaining themes via the WordPress dashboard. The upshot is that for the market that my Drupal book was aiming at (single person businesses) there is a very limited choice of good looking themes for Drupal 8.

Modules

The two main modules (extensions) that a Drupal 7 user would likely download first would be CK Editor (or a rival html editor) and Views. Both of those are now in Drupal Core, although poorly implemented. The coding for Drupal modules had a reputation for being complicated, which allowed Drupal site designers to demand high fees. This was changed in Drupal 8 to a more widely used coding system, but thirty-party module maintainers have been slow to catch up. Many modules remain in beta nearly three years after Drupal 8's launch. The inadequacy of Drupal 8's introduction is seen in the fact that when it launched even some of the modules in Drupal Core were unavailable for use, most worryingly for prior users this included the Migrate module for bringing a Drupal 7 site across to Drupal 8. My revised book plan had been to advocate Drupal 8 as a way to use the content management system without worrying about the security risk of adding any modules. That plan has fallen by the wayside because of the poor implementation of CK Editor and Views.

Statistics

When I abandoned the Drupal book I was about to write about the wonders of the statistics system, but in Drupal 8 this has been reduced to an error-based reporting system and the ability to monitor top sites (which WordPress converts would look for) had gone.

Future of Drupal

There is a sense that Drupal is losing its way and certainly that it will be losing many non-enterprise customers. The biggest worry is that Drupal drops support for a version once it it two behind the current release. So the non-enterprise-friendly Drupal 7 will cease to be officially supported when Drupal 9 is released. That may not be a major worry in light of the five year wait between Drupal 7 and Drupal 8, but Drupal know that the long delay lost them customers and are promising a faster move towards Drupal 9. That means a faster move towards removing support for Drupal 7, despite the feeling after nearly three years that Drupal 8 is still not ready for production use if your business cannot afford to hire a Drupal expert.

Abandoning Drupal 8

I remain undecided how to move away from Drupal 8. I could move to Drupal 7, which most of my sites were on in 2015. I am not a fan of WordPress, although I still have four sites on WordPress.com (retained for historical reference purposes) and one current site on WordPress.org. The problem with WordPress is that it is limited without adding third-party modules and those are a major security risk in WordPress. The sites could return to HTML/CSS sites using Pure.css (inspired by its use in the Drupal 7 Zeropoint theme) and reinstalling from my backups of those sites would be the easiest option. Those sites are not so easy to maintain in terms of editing while only having smartphone access. This is due to the new Smart Hosting system having a poorer in-built html editor that does not play well away from a desktop monitor. Another option is to switch to Joomla, a content management system that is growing on me. The main downside of Joomla is that is continues to enforce non-clean urls (i.e., it adds numbers into the website address to help its database). That system is due to change with the Joomla version update in September 2017, but I may find problems with that new release similar to the long-running ones with Drupal 8. At present the HTML/CSS route looks the most likely and I will have to live with the difficulties in maintaining the sites on the move. I can tolerate that because I do not allow comments on my sites, but those looking for any features that require signing in would be better to look to another content management system. Do not look to Drupal 8 at present, as it is not ready for production use for single person businesses. Consequently I do not envisage ever returning to my Drupal for Writers book project.

© Mercia McMahon. All rights reserved

Advert

advert for Smart Host web hosting service