I’m a senior developer at Kalamuna with 22 years of experience developing sites (with the last 6 or so in Drupal) so I was pretty excited to jump into Drupal 8 when it was released. I jumped in feet-first and without much preparation on my first D8 site. Once I got behind the scenes, I saw right off the bat that adopting it will be a massive shift for everyone who has ever been involved with the project. After building two sites and working on a third, I’ve got some predictions and lessons to share. We will address fun topics such as: What will D8 mean for developers? Why move to OOP PHP? Will people adopt Drupal 8? What are the things that will make Drupal 8 easier to use? Finally, we will also cover what you can do to embrace the change and continue on with your Drupal conquests.
The Move to OOP PHP Will Repel Some Devs
The shift from procedural to object oriented programming PHP is a big one. For as long as I have been using Drupal we have never really embraced a true OOP model. PHP 5 came out in 2004 and with it finally came a stable OOP architecture. Adoption was slow though, but Drupal is finally embracing it in its entirety. The nomenclature makes sense after a little bit of coding experience (and a couple lessons online). However, it represents a totally different way of thinking when you are writing the code now. So what does this mean for some devs?
Experienced and more adaptive devs will need a few months to pick up OOP PHP and become comfortable with it. Within a year or so, it will become second nature. People who had a hard time understanding the backend of Drupal will probably get lost. I see these people leaving Drupal for another CMS similar to what the backend of Drupal’s former self looked like, such as Wordpress or BackDrop. This is my 22nd year as a professional programmer and I have seen many paradigm shifts in my career. An exodus of some shape or form always occurs and this is what I see transpiring with some developers. On the other hand, it will bring in new blood. Symfony and OOP PHP developers may start to use Drupal 8, but time will tell.
There were many examples of a quasi OOP structure in Drupal 7. If you ever wrote a Views custom filter, dealt with 3rd party API’s (Salesforce’s SOQL interface, Braintree, etc.) or really dug into the Entity structure, then you have seen what Drupal 8 is like on the backend. I really enjoyed all this because it was powerful and easy to extend. If you had a hard time understanding these examples in Drupal 7, then you will more then likely be lost in Drupal 8 without a lot of training.
Why Should We Use OOP PHP?
Why use object oriented programming over procedural programming? This question gets asked a lot regardless of what language you use. It all breaks down to the scope of the project. For small simple projects, procedural programming is just fine. If you just need to write a script or three, there is no need to write a whole bunch of classes just to achieve the same thing. However, the drawback in doing things this way is that your code becomes very enclosed and not reusable. This is where Drupal 7 and below started to create problems. It was very heavy in the function universe and the API could be arduous to understand. Not every module exposed its function to the rest of the code base either. At times, you were unsure if you should realy access a function buried deep in an inc file. This is a very basic reason why there was a need for a change.
When you first start a new OOP project, there’s a lot more code to write. You are creating a whole system of objects for the entire system to use. However, once that has been achieved, you have before you a powerful set of base classes that can be utilized anywhere. This is what Drupal needed for quite some time and really lacked, especially in Drupal 7. Drupal 7 is very powerful, but very cluttered on the backend. So with a massive project like Drupal itself, we can now extend items in core and contrib with very little effort. This is the beauty of OOP PHP and should make Drupal a powerful force if used properly.
Drupal 8 Adoption Will Be Slow
In having already built two sites in Drupal 8, I can tell you adoption will be very slow. Besides the paradigm shift, contrib just isn't there and won’t be for another year, at least. I heard chatter online that we can build sites without many contrib modules in Drupal 8, which is quasi true. Drupal 8 touts itself as an Enterprise CMS. However, as it stands right now, we aren’t be able to use it to build anything but a brochure site. Contrib needs to get there and that isn’t happening very fast. Take a look around and you will see that a good portion of the widely used contrib modules are still in alpha or have buggy beta versions. Obviously, the answer is to jump in and contribute, but the paradigm shift may prevent people from doing this. It could be a vicious circle, but I could also be totally wrong.
People are scared of change, it is a well known fact. Drupal has been around for over 15 years and has remained the same, programmatically, since its inception. There are legions of developers who become Drupal masters who will now have to basically start over. I will say this, though: the way Drupal operated from a theoretical level is still about the same. So if you have that knowledge, all you need to do is embrace the infusion of OOP and Symfony. It is not going to be an easy change. It is hard to tell clients who only see this as a new version that we can’t upgrade their site right now. It doesn't bode well for people who are budget-ready and want to make the change now. Time and commitment from everyone will be the telltale sign of adoption rates in the end. It is up to the community as a collective to make things happen. You will have to dedicate a large amount of time to learn the new changes - don’t assume you can just pick this up and go. However, once you do, like I just mentioned, the community needs you.
Drupal 8 Pros and Cons in Historical Context
Goodbye PHPTemplate, Hello Twig!
I heard a story one from a Drupal elder that PHPTemplate was written in a weekend and just thrown into the mix. Whether or not this is true, I don’t know, but it does seem plausible. That is fine though, not here to point fingers. The problem with PHPTemplate is that it allowed a lot of very bad practices which would lead to a forray of messes. We have all seen heavy business logic in a TPL file and shook our heads.
Twig changes all of this. You will no longer be allowed to throw PHP in a theme layer template file. You will be forced to pass variables via a preprocess as — it should have been, anyway. Twig as a templating engine is used by a variety of other modern frameworks. This may help bring more talent into the fold. It is easy to understand once you get the gist of the lingo. Then you can bang out fancy sites once again.
Entities for the Masses
So many different types of entities objects have evolved with Drupal, all with their own APIs and sets of functions. Things got confusing real quick In Drupal 7 when you had a complicated website with a variety of nodes, taxonomies, custom entities, etc. Thankfully, the entity module came along in Drupal 7 and helped some, but it was still a mountain to climb to get everything to play well together.
This is all better in Drupal 8. All the things are extended from the entity class now, it appears. They are still classified as the terms we are used to, but all operate as entities under the hood. The potential this opens up is massive. We can do anything we want now. We can connect to any system in the known (and maybe the unknown) universe and import all their stuff easily via the newly polished Entity API. Good job with this one.
We’ll Build More Robust Search Mechanisms
We are a panels shop and integrating panels and the Search API can be a pain. Throw page manager into that mix and you also have a layer of complexity that is annoying and very buggy. Sometimes it just won’t work and you are at a loss as to what to do. I have written a few custom solutions to win this, but it shouldn’t be that way.
As I mentioned above, Drupal 8 centralized entities and as such, the Search API embraces this. They also improved performance and how the entities are indexed in the database. Everything is still in alpha, but it shows a lot of promise.
Routing Structure is Uber Confusing
Jumping into Drupal 8 also poses some challenges if you are used to the init and menu hooks. One of the hardest obstacles I have found with understanding Drupal 8 is bridging the gap of what hook_menu did and what the new routing system does. The routing and controller system can be mystifyingly complicated and frustrating. I am thankful for tools such as Drupal Console to bridge that vacancy of knowledge, but I am sure many others may feel as I do. So many YAML files and confusing classes can scare anyone away quickly.
I mostly get it now, but at first it was daunting. There is no menu system anymore, we are using Symfony’s Kernel structure and have to call it every time. It is an annoying hurdle to overcome. This article by Lullabot is probably the best reference out there to help wrap your mind around the changes.
Documentation is Sad Sometimes
The documentation also isn’t quite there yet. Drupal 8 went through massive changes in its project development cycle. Some of the documentation out there is depreciated or flat out wrong and has yet to be changed or updated. In time this will change, of course, as more people adopt and contribute. One rule of thumb I heard that remains true: disregard most articles written before June of 2015.
How to Embrace the Change and Get Up to Par
“Live in the solution and not the problem” is a mantra I have lived by for many years. Before you consider jumping into Drupal 8, you will need to learn proper OOP PHP principles. Without this, you are of very little help in the new system. If you spend a couple weekends watching and learning from these resources below, you will be off to a great start. Watch the tutorials below in the order I present them. This is the best way to win.
When learning a new task, it is best to act as if you know nothing. Absorb all the knowledge this guy lays out in a few quick videos. It is as basic as it can get, but it helps leaps and bounds.
Jon Peck of 4 Kitchens was a master PHP craftsman before hopping into Drupal. His video above is as straightforward as it gets. It has all the examples and instructions you will need to understand all the new lingo and structure of OOP PHP.
Another win from Jon Peck. As you know, Drupal 8 is built on the Symfony framework and as such, it is best to learn the basics. Jon again lays it out in an easy and straightforward fashion.
The folks at Lullabot always do a great job in showing the world how to easily navigate Drupal. Some of the initial topics are covered above, but it is good to get a double dose of the knowledge. They teamed up with KNP University for almost all these videos. All the basics and them some are covered in these videos.
Drupal 8 will be difficult to embrace and learn. The only way you are going to get it is by buckling down and learning a whole new way to write code on the backend and frontend. There are tools like Drupal Console to help you, but you do need to learn the basics on this new paradigm. If you do not take the time, you will fall behind. Drupal 8 has a long way to go until it is the Enterprise CMS it claims to be. Jump in, get your hands dirty and continue on your magical Drupal journey.