Drupal New Releases

Seven or Eight years after I retired, I joined a local community service organization. The organization holds an annual "Fall Fest" event that had grown from a single day event in a small park featuring 2 vendors and a local musician playing music to a 3 day event featuring over 100 vendors and bands from all over the Northwest (and somtimes Nashville or Austin).

The organization was wanting a website to market the Fall Fest event.  After discussing a number of different options over a couple of years, I foolishly said "if we can't find anyone to build a website, I will do it.".  Of course, the effort to find someone to build the website stopped immediately.  I had only created one website and it was a very minimal personal website.

I started researching Content Management Systems and found that the two most popular CMS systems were Word Press and Drupal.  I downloaded both and tried both of them.  I really didn't care for Word Press and liked Drupal - later I read that non-programmers tended to like Word Press while programmers tended to like Drupal.  At the time, they had rougly the same number of sites reported using the 2 CMS systems.  

I actually committed to building 3 websites for local non-profit community organizations. A friend of mine has a web hosting business and he was setup primarily to host Drupal sites.  He volunteered to host one of the community organization websites for free. So, I decided to commit to Drupal since that was what was setup to support.

If was quick and easy to build a relatively nice static content website.  I quickly built a website (actually 3 websites) that the various groups loved.  However, I quickly developed a need to create input forms.  Drupal is built entirely using PHP.  At the time I didn't know PHP and really didn't have a strong desire to learn PHP.  The current release of Drupal was Drupal 7.

Not a Problem!  Drupal has a form-building module that allows non-programmers to build input forms without having to learn PHP.  I created a form for vendors to apply online for the Fall Fest event.  The form building process involved assembling components (drupal modules) each component developed and contributed by different programmers.  

The obvious problem with Community Developed software became apparent immediately.  While the Drupal organization is nominally the controlling authority, they really have no process to QA all of the nearly infinite combination of modules that can be used.  All of those different modules contributed by various community members did work as inteded -- by themselves.  However, as I started to combine the more sophisticated  components, problems started to occur.  I created a huge spreadsheet of components by releases to track how they interacted together.  If I found a combination of versions of components that actually worked together I had to never update the component because it tended to break the interactions.

Clearly that was an untenable situation.  So, I quickly abandoned that and started writing my own forms in PHP using the Drupal Form Api. The Drupal Form API is pretty extensive and I was able to build forms quickly and efficiently that didn't depend on some combination of independently developed components working together.  I was quite happy with that.

And then Drupal put out a new release: Drupal 8.   By then I had created over 10 different websites with a lot of custom code.  I expected I might have to make some changes to the code I had written.  I WAS WRONG! 

Drupal 8 required a total rewrite of every module I had written.  There were no tools to do conversion of the code.  For websites that used contributed modules we had to wait until that contributed module was rewritten for Drupl 8.  Some people decided NOT to rewrite their module and moved to another CMS instead (the numbers show Word Press grew dramatically).  It wasn't that the new paradigm and framework were that difficult, it was the amount of effort it took (and the inherent risks involved) to rewrite everything.  

I was stunned that the Drupal Organization would do that.  After working in the software industry for over 30 years (much of that time  as a manager/directory of product development) I was shocked that they would even consider doing forcing developers to rewrite everything.  Drupal did not offer some sort of compatability mode that allowed the Drupal 7 modules to run in Drupal 8 -- the modules had to be rewritten.  There was a vague promise that they once upgraded they deveoper would not have to do that again in the future.

Until Drupal 9 - which involved more mandatory rewrites. And Drupal 10.

So, I started evaluating alternatives.  Clearly staying with Drupal 7 and not upgrading was the easiest path.  But, eventually Drupal 7 will fall out of date with internet protocols and become unusable.  The Backdrop CMS was a fork of the Drupal 7 system that was created to give Drupal 7 users a reasonably compatible CMS that did not require a major rewrite.  Most of the changes were to change internal functions that started with drupal to start with backdrop. The other minor change was to rewrite how internal "variables" are handled.  

These changes were minimal and easy to write a conversion program (I wrote the conversion program in Microsoft C# and ran it on windows. It took a couple of days to write the conversion program and it worked well.

However, the Backdrop CMS developers made some crazy decisions after they forked Drupal.  For reasons that totally elude me, they dropped support for the Postgresql database. Backdrop only suports MySQL.  WHY? When Drupal was forked Postgresql support was in Drupal. What possible reason could there be for taking it out of Backdrop?

Unlike Drupal, Backdrop did NOT provide an easy process for incorporating an HTML editor (like tinymc or ckedit), they incorporated ckedit into the system. AND made unfathomable choices.  For instance, there is no option for changing Font sizes or Font Colors or background colors.  They took a very usable image upload process and dropped features from it.  Enhancing functionality to add more/improved features is reasonable - removing very useful functionality is ridiculous.  

There are many things I like about Backdrop over Drupal (besides the fact that I didn't have to rewrite thousands and thousands of lines of code).  Backdrop separated the Layout from the Theme.  So, I can implement different layouts for different pages and I can theme pages differently. 

Instead of having to do a Drupal rewrite of EVERYTHING to upgrade, I was able to convert modules to Backdrop. BUT then I had to spend a considerable amount of time learning to write ckeditor functionality to implement the missing pieces.

Over the last 10 years, the percentage of websites using Drupal has dropped precipitously while the number of Word Press sites has grown dramatically. 

I do believe Drupal made a huge mistake.  Now my decisions are:

  • How long can I stay with Drupal 7 before I just have to move to something else
  • Can I live with Backdrop?
  • Do I bite the bullet and start using Word Press (and rewriting everything for Word Press)
  • Write my own CMS and be done with it.

I wish I was 25 again and not 71.  It does make a difference!