Drupal 8 and Statistics

Submitted by peter on Thu, 11/30/2017 - 23:27

The statistics module in Drupal 8 shows some of the good and some of the bad in the evolution of Drupal. There are not yet any stable statistics modules of use in Drupal 8.

Drupal used to have an effective minimal Statistics module. In Drupal 8, the Statistics module is downgraded with replacement. The Statistics was changed without any real discussion. One person volunteered to create a replacement but did not. Lets look at how this and similar changes occur.

Prior to Drupal 8, Drupal was developed using a waterfall approach with multiple massive changes slamming developers and users every few years. Drupal 8 development was the same damaging waterfall process. Now that Drupal 8 is here, the development process uses an agile approach.

The Agile approach should make the change to the Statistics module easy and useful. The result is different. Why?

The Statistics module provided a usage log, reports, and a page counter. In Drupal 8, the Statistics module was stripped back to a page counter and the usage log was going to be moved to an external add-on module. The reason for removing statistics is simple, some developers decided they are not using the Statistics module so lets remove the module.

For some reason, they decided to keep the page counter. Removing the statistics log was based on the logic that the log requires a database write. Leaving the page counter in defies that logic because the page counter requires a slower, more expensive, database update. Weird.

Part of the change was to move statistics out to an add-on module. A code change like that would be easy when everything is working. Instead they deleted some of the code from the Statistics module and left the rest up to a volunteer with no support or incentive. The add-on module has not happened.

People who use the statistics module need to remain on Drupal 7 until the problems with Drupal 8 are fixed. Sponsor a real statistics module. The main Drupal developers expect you to cave in and open your Web site up to the Google Analytics invasion of privacy. Staying with Drupal 7 is one way to protest against the negative changes.

There are many good things in Drupal 8. The Lightning project is important. Drupal 8 might eventually have a working workflow. The random development of each new Drupal version slows down adoption of the good things by taking away other good things.

There are many indicators of the improvements to Drupal over the years. After I helped Drupal developers improve their approach to database usage and database requests, the developers set up a database team to work right through Drupal core. My work on memory reduction, and presentations at conferences, was followed by a significant improvement in the next version.

There are also endless examples of misguided development. Look at the cTools package. cTools started as an add-on module to provide something. The cTools developers added bunches of unrelated code. cTools should have been several modules you could install only when needed. The useful components of cTools could be brought into Drupal core when fully developed and stable. Instead we ended up with a massive package that had to be installed all the time. The move of cTools code into Drupal core was a massive waterfall change.

The main use for cTools is as a prerequisite for the Views module. When Views was moved into core, cTools code was moved into core. cTools remains as a collection of code that is not needed for Views. Unfortunately there are modules requiring the remaining cTools and we are still stuck with the idea of loading a big collection to satisfy one requirement.

The cTools development mistake is repeated elsewhere. There are also examples where code was split up first, before incorporation into Drupal core. The good examples show logical development. The modern agile type of development where you make several small changes instead of one big painful development.

Drupal 8 was announced with a plan to use parts of the Symfony framework and whatever else is useful. You can see comments in the development of Drupal 8 that show extremism. People promoting a change because it is in Symfony. Not a change along the line of "this is better". The extremists promoted "this is the Symfony way" and "I saw someone do this in Symfony so we have to do this".

Drupal 8 works and has more code overhead. The extra code overhead is offset by the arrival of PHP 7 to reduce processing overheads. Without the arrival of PHP 7, Drupal 8 would have been a performance disaster dependent entirely on internal caching that works only for some types of Web sites.

Drupal development consistently resists change up to a tipping point where the change suddenly becomes more important than logic. Suddenly everything has to change to the new way without analysis or measurement. Developers are often left with the problem of using the new way while also trying to return to the better performance or superior flexibility of the old way.

Prior to Drupal 8, you could use HMVC but now it is difficult because the code in an add-on module is scattered everywhere. You have to write many independent bits of code to fit in all over the place. You have to use artificial techniques to connect your code. Compare the result to Drupal 7 or a services oriented framework. Then try to explain your Drupal 8 code to someone without extensive Drupal 8 code development experience.

I do not like damaging Web sites with Google Analytics. Google artificially downgrades your Web site in search results if you do not use Google Analytics but they do far worse if you use Google Analytics temporarily then remove Google Analytics. On one site, Google Analytics Google Analytics was not used for years, was used for a few months as a test of Google Analytics, then Google Analytics was removed because Google Analytics made page viewing too slow. The site was high ranking before Google Analytics, was high ranking with Google Analytics, then was removed from search results when Google Analytics was switched off.

I looked at porting some of my statistics modules to Drupal. Drupal 6 and 7 were easy. Drupal 8 was too hard and too unstable. Drupal 8 is now stabilising but none of the Drupal 7 statistics related add-on modules work in Drupal 8.

One big advantage of statistics in your Web site, instead of an external Web site, is the ability to link to content as content appears in your Web site. With the right configuration of your Web site, you can have point in time analysis based on the actual content at that point. This is a superb result for ongoing page refinements and for continually updated pages. Drupal has everything that is needed, except statistics.


The Lightning distribution of Drupal is an excellent example of focused Drupal development. The distribution is aimed at publishing. Elements of Lightning are added to Drupal core. Drupal 8.5 is expected to replace the main part of Lightning.

Drupal core has too many people pulling Drupal towards the latest fashions. Lightning is focused on one aim, one type of work, and does only what is needed to achieve the right result. Lightning could be the best example of how Drupal could be developed.


govCMS is a distribution of Drupal 7 designed for and maintained by Australian federal government departments. There is a prebuilt hosting cloud for govCMS and a separate download for hosting anywhere. The hosted version meets certain security requirements inside and outside of Drupal. When you host your own govCMS site, you get only the security inside Drupal.

govCMS is an excellent example of industry specific development. The security side could be documented for use elsewhere. Outside of the security aspects, the Lightning distribution is of more use to my work. The use of Drupal 7 makes it hard to transfer ideas from govCMS to new Drupal 8 sites. I look forward to govCMS migrating to Drupal 8 so that we can reuse ideas from govCMS in other sites.


Drupal is a bouncy ride generally headed upwards and with many roadblocks to version upgrades. While Drupal 8 may reduce version upgrade problems, the underlying development approach is too haphazard to remove the bumps and roadblocks. govCMS, Lightning, and other distributions are an attempt to make Drupal development logical.