Having had the opportunity to read a recent comparative study between Drupal 8 and SPIP, I discovered a Drupal perception that is not mine. Far be it from me to want to compare Drupal and SPIP. Indeed, I know very badly SPIP, at least only as a basic user, and much less than Drupal, and so I will not venture on such a comparison. Also, I wanted to share these mythical, real or perceived defects of Drupal 8, which I recently discovered and which I think deserve a counterpoint.
Drupal 8 Upward Compliance
Drupal 7 modules are incompatible with Drupal 8. It must also be said that the technological break introduced with the new version of Drupal 8 left no room for a such option. On the other hand, Drupal 8's backward compatibility to its future major versions is guaranteed. Let's say that the technological breakthrough of Drupal 8, with the adoption of current best practices in web development, the reduction of its past technical debt, was sufficient to be able to embrace now a smooth upgrade path, for the next major Drupal version.
The low number of modules and their quality
12,000 modules for Drupal 7. Only 3,000 modules for Drupal 8 including 1,000 in stable version. The module offer on Drupal 8 is actually less plethora, but at the same time more coherent, with modules with similar functional perimeters that come together. But it is certain that we do not have the same functional coverage as Drupal 7. Do you need them with Drupal 8 is an another question. And the answer can only be done on a case-by-case basis.
But another aspect also emerges on Drupal 8: the implementation of a business logic can be done much more easily and quickly, thanks to its new architecture. When you could achieve the same result on Drupal 7 with 1 or 5 modules. The advantages and disadvantages are discussed. And also depend on the skills available to design your Drupal 8 project.
The question of the number of stable versions of the modules is much more pernicious. I know modules in beta 10 times more reliable than a so-called stable version of another Drupal 8 module. It all depends on the maintainer's personality, his spirit of perfection, or not. The use of such number is therefore questionable. But addressing this issue of the stability of available modules can lead to a doubt about the quality of these. Drupal has an organized process (The Project Application Review) to allow new developers to publish their module on drupal.org. And overall, the quality of the available modules is felt, especially since the object-oriented architecture of Drupal 8 makes it more difficult to write spaghetti code. It should be noted that for some months now this process is no longer compulsory for new entrants, but in parallel a new policy in terms of security cover has been put in place.
Usage statistics show low adoption of Drupal 8
Usage statistics should be analyzed with great caution. Indeed these statistics come from the Drupal sites that have the Update module enabled, module which allows to warn a webmaster of updates available. Apart from this it is typically the type of modules that is never activated on many Drupal projects. Why ? On the one hand this module will perform queries on drupal.org to detect the available updates, and therefore will impact the website's performance. On the other hand because many Drupal 8 sites are managed from Composer or Drush, tools that allow you to collect this information from the command line and launch the appropriate updates in seconds.
But do not hide that Drupal 8 is progressing slowly. Is it due to a less crowded presence of modules contributed on Drupal 8? Is it a preference to migrate directly to Drupal 9, and not have to do two migrations? Is it due to this technological breakthrough and a rise in skills needed? Is it due to a positioning issue of Drupal 8 that clearly addresses large-scale projects to the detriment of less ambitious projects? There is a clear debate within the Drupal community.
The Next End of Drupal 8 Maintenance
"Drupal 8 could be maintained only until 2019, then in 2021 for security maintenance" I could read. In short, a short life span for the necessary investment with an uncertainty on the effort to produce to migrate to the next major Drupal release, Drupal 9.
The date of the end of Drupal 8 maintenance is not known to date, and such an announcement today is more some astrology than proven facts. In addition, the new policy for backwards compatibility allows for a smooth and continuous migration towards future versions of Drupal, minor or major. Read Do I have to wait for Drupal 9 for my web project? on this subject for more details.
Drupal 8 has few themes
Drupal has few ready-made themes on drupal.org, compared to Wordpress for example. But we can find many, in the same way as other CMS, on the online platforms offering these products. And for $ 40 you can acquire a theme Waouh!. Depending on your need, your project, this can be quite enough. You get what you pay for, but no more. These themes are often distributions that integrate business or functional logic at the level of the theme layer. In short, a real hodgepodge, like all themes ready to use on these platforms as a rule for all CMS. But if you do not foresee heavy adjustments, these themes can be a good compromise.
With large projects, or with many customizations, it is always better to design your own theme, if you do not want to fight against it and its implementations at some point. And in this case Drupal 8 has many built-in frameworks (Bootstrap, Foundation, etc.) that provide a solid basis for realizing your responsive theme.
Content composition with Drupal 8
Comparing the power of composition of a content with Drupal 8 and the typographical shortcuts of SPIP seems to reveal a profound ignorance of Drupal. Drupal makes it possible to compose complex content in a structured way, allowing the webmaster, the editor, in brief the content producer, to make complex layouts by focusing on its content only and not its formatting. The Paragraphs module is one of the methods of structuring this data of a content while giving the users a great freedom in their composition. While the typographical shortcuts of SPIP make it possible to make elaborate layouts, but by fighting more or less, within a single text field.
Clearly we are not talking about the same thing at all here. Structured data enabling contents cross-referencing, transverse or vertical navigations, allowing layouts completely controlled by the theme layer, and not by the content's author, which is neither work nor vocation, have nothing to do with the use of a single text field where one inserts pelle-mell, as best he can, its contents and their shaping.
Powerful but complicated rights management
"Rights management under Drupal 8 is powerful but can quickly become complicated with over 100 check boxes". Certainly this may be true. But this also reveals a lack of knowledge of Drupal or a poor approach / project design. Many solutions allow you to manage access rights other than by assigning rights roles on content. The use of taxonomy can be another approach for making rights management dynamic: rights are not assigned to roles on content in a static way, but can be given dynamically depending on some content's attributes. And this without heavy parameterization. Rights management, as appropriate, can be simplified. But it is not the management of Drupal's rights that is complicated, it is rights management needs that can be complex. And Drupal can address any kind of need. If the needs are simple, rights management will be just as simple.
A reduced functional coverage of Drupal 8
Yes, I admit Drupal does not natively have the system of headings of SPIP, nor its harvesting, nor typographic shortcuts, nor the possibility of inserting an attachment in a text body, the possibility of programming dates of Publication, and formatting capabilities of SPIP articles. For some functional failures, I think Drupal 8 can even assume it proudly. But to say that the functional coverage of Drupal 8 is smaller than that of SPIP, the arms fall to me.
Migrating time-consuming data
Migrating from a SPIP site to Drupal 8 is time consuming with a lot of manual data recovery. In fact it depends on the target site. If the Drupal project is produced with the same structure of SPIP, a title, a body of text, a field keywords, a heading (more probably still some others that I must forget) then this migration can be completely automated . Drupal 8 natively has a framework (Migrate) to implement this migration scheme, from database to database (a house mill can also do the trick, everything depends on the constraints of the migration). But if you want to take advantage of a migration to Drupal 8 to structure your data (for example, put a date in a Date field, put a price in a Price field, put an image in an Image field, etc.), make your content enrich to allow cross-referencing, cross-browsing, cross-publishing, so yes a SPIP migration to Drupal will be time-consuming because you will have to intervene on your migrated contents to enrich them with the new data that do not yet exist.
Administer Drupal 8 is complicated
Yes Drupal 8 is not simple to administer. But we can not compare SPIP and Drupal 8 on this pure aspect of administration. Both CMS have a completely different approach. SPIP is a turnkey site, with an identical backoffice (with plugins installed) on all SPIP sites. You will not find a Drupal site identical to another Drupal site. The backoffice of Drupal 8 is at the disposal of an administrator who will build the site, create its types of contents, its listings, its taxonomies. An administrator who will also build a backoffice intended for site users, webmasters, for publishing content. The backoffice of SPIP is at the disposal of a webmaster who will be able to begin to publish its content, to create its headings.
Yes Drupal 8 is more complicated because it is not the same target of users, if one compares a site SPIP and a site Drupal freshly installed. But the power of Drupal 8 is precisely to be able to easily design a customized backoffice for webmasters without all the configuration options that belong to a technical administration and not an editorial administration. Drupal is too a CMF (Content Management Framework) before being a CMS.
To illustrate this, you can do a SPIP like with Drupal 8. The reverse is not possible.
Drupal 8 is less efficient
Clearly Drupal 8 is less powerful than Drupal 7, if we make a raw benchmark comparison. And certainly even less powerful than SPIP. Just as SPIP must be less efficient than a static HTML page. Simply Drupal 8 embeds much more code, and does not offer the same level of architecture and functionality.
Nevertheless, Drupal 8 has a high-performance cache system for both anonymous and authenticated users, with a revolutionary dynamic cache system. It integrates natively into its core BigPipe, a technique invented by Facebook, to further improve the felt performance, and the so-called TurboLinks technique, with the Refreshless module, which allows to load only parts of pages that change, not the entire page.
Drupal 8 has a wide range of tools to enable it to propel very high traffic sites. For example, if the cache management from the database is not sufficient to meet the traffic of your site, you can again change easily this system to store the native cache of Drupal on Redis or Memcache. And if this is not enough to meet the tens or hundreds of thousands of visitors a day, it is always possible to couple a Varnish or Nginx in front of your site.
Drupal 8 is buggy
Oh good? You know a computer system, relatively complex, that has no bugs. Big deal. Yes Drupal has a bugtracker, public, which allows the Drupal community to work together, fix bugs, exchange, propose new features. Hiding bugs from a system does not mean they do not exist. Drupal is also a platform, a community, mature, organized.
It should also be recognized that Drupal 8 is a young system, which has been rewritten almost completely, and like any new system it must wipe off some youthful defects. The systematic writing of automated tests is also a novelty introduced with Drupal 8, automated tests that can only enhance its maturity in the short and medium term. The more complex a system, the more diverse and varied it is, the more numerous and demanding its users, and the more potential bugs. A simple information system with a limited base of users will have mathematically fewer bugs, either because of less functional coverage or because they have not yet been discovered.
Finally, Drupal 8 with its new versioning policy and a roadmap for functional evolutions in every minor release is a constantly evolving system. You found too bugs in Drupal Core that are linked to its experimental module policy (see https://www.drupal.org/core/experimental), a policy that allows to integrate as soon as possible new functionalities in Core, and thus allow developers to iterate on this new module. Most experimental modules integrated in the core are not intended to be used in production, unless they have expert skills on Drupal, and therefore integrate the Drupal 8 core in alpha version. Based on this finding, it makes perfect sense to find many major or critical bugs.
It is certain that a Formula 1 car demands more maintenance, is more demanding, is more prone to breakdowns than a car produced on the same model for many years. It is his nature.
Drupal is not secure
Five security bulletins, including a critical flaw, were released in 2016. Does this mean Drupal 8 is not secure?
Zero risk does not exist, the infallible security no more. Drupal 8 is recognized as one of the most secure CMS in the world. The important thing is not to know if Drupal has had or will have a security flaw, but how Drupal handles this one. The management of the issue SA-CORE-2014-005 is a perfect illustration.
In addition, it is important to note that these security advisories, critical or not, make it possible to evaluate very precisely the threat, and if the conditions of a potential attack are indeed gathered for your site Drupal. This is not always the case, given the modular aspect of Drupal core, and often conditions are not met.
Some defects of Drupal 8 are not mythical. They are real. Drupal 8 is bigger and slower, if you measure its raw performance without the tools available. But some defects are also compensated by a whole palette of tools made available. Other flaws in my opinion seem more to be a real misunderstanding of Drupal, when it is not simply the brief counter. Yes it is more complicated to build a five floors building than a wooden hut. They are not the same materials, the same techniques, nor the same foundations. But in the end, for the daily use of a building or a hut, to use a lift, nothing complicated, it will be necessary to press a button (except that the hut will have no elevator), to light a heater you will have to turn a button, etc. The only difference will be the respective capacities of these constructions.