Discussions about Drupal 8
In his article in Web Magazine in August, Eric Herrmann noted growing resentment towards Drupal 8 - trends within the Drupal community that I wasn't even aware of. He bases this on postings by Drupal core developers quicksketch (AKA Nathan Haug) and Dave Reid in the Drupal 8 issue queue, in which the two announce in clearly frustrated words that they are retiring as Drupal core developers. Now the two are not just anyone, but as employees at two of the most important US companies in Drupal - Lullabot and Palantir - and as long-time contributors and lead maintainers of various projects, they are certainly important people within the Drupal community.
In the course of this development, Nathan Haug has opened the project "Backdrop" as a fork of Drupal 7 to further develop this version.
But what are the serious changes that cause long-serving members of the community to jump off the current development and start parallel projects? As a developer, three things jump out at you first:
"Transformation is necessary like the renewal of leaves in spring.
"
Vincent van Gogh, Letters
The Symfony 2 Framework
The decision in favor of Symfony was made because Drupal has an "insular status" in the PHP landscape and can only benefit from collaboration with other (open source) PHP projects, but also because it is clearly inefficient to develop your own solutions in all possible places when there are already reliable, open frameworks such as Symfony that make the development of a large number of functionalities superfluous.
However, the integration of Symfony into Drupal 8 is not only motivated by the desire to grow together with other PHP frameworks and standards and thus utilize synergy effects. Symfony is primarily intended to fulfill a very specific purpose in Drupal 8: Making Drupal "out of the box" ready for web services. Dries Buytaert has explained the considerations for this and the decision for Symfony 2 in his article The future is a RESTful Drupal. The significance of this step is far-reaching: viewed as a framework, Drupal 8 is even more than its previous versions not "just a CMS" - it is a framework, an application server that can be used also as a powerful CMS.
We at Tojio find this development very exciting. A few years ago, it was precisely these possibilities (among others) that were decisive for our decision to use Drupal. We have worked on a number of web applications with server/client architectures. There was always the requirement that the content and data of the applications a) had to be edited by editors without a technical background and b) this data had to be seamlessly integrated into the rest of the website - Drupal was already a good candidate for this back then and is becoming more and more so.
Object-oriented programming in PHP
Object-oriented programming (OOP) in PHP has been possible for some time and many modules have been using it for a long time. With Drupal 8, however, it is now mandatory. There are quite a few people who warn that this will alienate quite a few Drupal developers who are not familiar with OOP. This point is not easy to refute, because learning object-oriented thinking and implementing it consistently in code is no easy task - especially if you have previously programmed procedurally in PHP for years.
I myself learned OOP from scratch with Java during my time at university. My first contact with PHP(4) outside the ivory tower was... scary. The language seemed completely stone-age, was full of inconsistencies and I was able to throw my painstakingly acquired OOP skills overboard again because they were no good there. In this respect, I realize how hard the transition to a completely different programming paradigm is.
In the meantime (since PHP5), it is now possible to program object-oriented (or at least use objects) in this language as well. This is a huge advantage in terms of the reusability and maintainability of code and the encapsulation in objects also limits a number of sources of error. Learning and using OOP techniques is worthwhile, even if it takes time and effort!
Twig - the new template engine
Twig is the new template engine in Drupal 8. The switch from PHPTemplate to Twig was made with web designers and Themer in mind, to make working with templates safer and easier:
"We hand them a loaded gun and tell them to hammer in a nail with it. Oh and be careful!
"
John Albin, at DrupalCon Denver
The problem with PHPTemplate as a template engine is that any PHP code can be executed in templates. It is now general best practice not to execute any code in template files, to move all processing logic to corresponding preprocessor functions and to only output variables in the template at this point. However, the mere possibility of executing arbitrary code there poses a serious security risk. It also presents unnecessary potential sources of error. In addition to greater speed and security, Twig should also make life easier for web designers and themers.
So why the fuss?
Drupal 8 has sparked many discussions, heated tempers and stirred up fears - mainly because of the drastic changes such as the integration of Symfony and OOP. But I think every developer or designer knows the phenomenon: a project grows over the years, the requirements change. At some point, the moment comes when you evaluate the current status, look at the lessons of the past and certainly have new ideas on how the project could be improved. Then it may be a promising investment for the future to implement the project from scratch.
"It's a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.
"
Dries Buytaert, buytaert.net
And he is right. Dragging legacy issues along with you does not create innovation.
Preview of Drupal 8
Last Wednesday, Dries Buytaert presented the current status of Drupal 8 in a keynote speech at DrupalCon Prague: