Today marks the release of Drupal 8, and the birthday of its founder, Dries Buytaert. This release is more than just a new digit, it's an entirely new platform with something for everyone to love, but it's particularly big for web site owners.
What's the big deal? The biggest, most powerful, one of the most successful open source projects in the world has two major, fundamental changes that change everything you thought you knew about it.
Well, not everything. Lots of the things that people love about Drupal are getting some nice improvements:
- Mobile, responsive support straight out of the box -- it's actually a nice experience administering a D8 site on your phone!
- The information architecture is the same as always -- content types, vocabularies, comments, anything you've learned about how content is organized in Drupal is the same, but...
- Lots of powerful modules like Views and CKEditor are now in core, and much less quirky than ever before
- Deploying updates and configuration settings between multiple copies of the site is completely overhauled, and now very simple to do
- Caching support is baked in, enabled by default, so in spite of doubling in code size it uses less computing resources and responds much faster, especially on busy sites
- Loads of other improvements.
All of that is great, and we could go on for hours, days about how much of an improvement this is. And that is the stuff you will notice today, next week, next month. But that's not the big change, that's not the killer feature of this upgrade for site owners.
The killer feature is what happens in 6 months, in 1 year, in 5 years. And that is, the great big upgrade cost you don't have, when it's time to upgrade to 8.1.0, or 8.2.0, or even 9.0.0.
Two Fundamental Changes.
Ask any Drupal site owner where their biggest pain is. You'll run into two big complaints: How hard it is to find decent Drupal developer talent, and how painful it is to migrate to the next version. Those both change with Drupal 8.
The next version
The current version of Drupal 7 is 7.41. The new version of Drupal 8 is 8.0.0. The next version of Drupal 7 will be 7.42. The next version of Drupal 8 will be 8.0.1. Notice anything different? It's called "Semantic versioning," and yes, it's just one more number between the dots (or added to the end). But the change behind that simple little version number is enormous.
Drupal is changing its entire release process to have "minor" version releases every 6 months. That means 6 months from now will be 8.1.0, and in a year, 8.2.0. These are calendar-based releases that contain new functionality, AND maintain backwards compatibility with the previous minor version. Upgrades from 8.0.4 to 8.1.0 should be completely transparent, nothing breaking as a result -- but new stuff available.
Drupal has never maintained backwards compatibility like this before -- this is a fundamental change in the project, and it represents the maturity the platform has reached.
There will only be a Drupal 9 when there's enough changes that are not backwards compatible that it's time for a new major release. But this "minor release" plan provides plenty of notice of functionality being deprecated to allow people to transition away from those things that are going away, long before 9 arrives.
That means an update to Drupal 9, will mostly be a matter of making sure you've either moved away from stuff being changed in Drupal 8, or have added an alternative. And then update, potentially like any other minor release.
No more completely rebuilding your site in the new version! For the first time ever, major version updates in Drupal should be relatively painless, as long as you keep your site relatively current and pay attention to changes as they develop.
"Drupal Developers"
Drupal has always come with a steep learning curve, particularly for developers. This is because it has developed out of procedural code, with a "hook" system and naming conventions that make a lot of things happen "automagically". It takes a couple years to get your head around the many Drupalisms, code patterns, hooks, conventions that are not seen or used in most other projects. You need to be very proficient in coding, using a debugger, and having an open mind to be a good Drupal developer... until now.
"Object Oriented" is a term that came in vogue in development circles... in the 1960s. It became the dominant way of programming in the 1990s, particularly with the rise of Java in popularity, and it's at the heart of .NET as well as many open source practices. And while Drupal uses a lot of object-oriented concepts in its information architecture, it has never been fully object-oriented in its code... until Drupal 8.
Why should a site owner care about this? Two huge benefits -- the same two I'm talking about here:
- Drupal development now shares the same programming architecture as 90% of the rest of the industry, instead of being its own thing. Now you don't need to find a good "Drupal developer" -- a good developer should be able to pick it up and figure it out without years of learning the specific incantations and magic charms of all those Drupalisms.
- Updates. Because we now encapsulate all this code into objects that extend other classes, this allows for upgrading smaller bits of functionality without affecting the rest of the site. This means that it should be possible to upgrade some modules to Drupal 9, before the site itself.
I think a lot of people in the Drupal community don't fully realize how huge a change this is (and it is interesting to see some backlash to the changes from those who may fear some of this change).
In other words, when Drupal 9 eventually arrives, it won't be such a big deal -- it should be possible to run exactly the same contributed modules for Drupal 8 and Drupal 9, with no changes whatsoever -- and even if something important does need to change, it can be changed by inserting a "shim" class that translates the API changes as appropriate -- it will almost certainly be possible to run Drupal 9 modules in Drupal 8, and vice versa. And you won't have to find a Drupal-specific developer to do this for you, either.
The new world of web applications
Drupal has long been a compelling platform in terms of functionality, the speed that new functionality becomes available, and the power built into the system. Drupal 8 is not just another release -- it is the maturing of this platform into something that is completely up-to-date and capable of staying that way for at least the next decade, if not more.
If you are looking for a new content management system, a new project management system, a new platform for managing all kinds of communications between groups of people, you can't pick a better base for doing so than Drupal 8. Give us a call, and let's discuss what you want to build!
Client Spotlight
Lease Crutcher Lewis
In December of 2013, we were contacted by Lease Crutcher Lewis to take over their hosting. Their site is a great contender for Drupal 8! They were also interested in our Drupal maintenance plan and our Drupal Site Assessment.
Freelock News
As you might imagine, we're starting our first Drupal 6 - Drupal 8 upgrade projects now, and should have much more hands-on experience with this process shortly.
The official "End-of-life" date for Drupal 6, when no further security updates will get released, is February 24, 2016. For all those running Drupal 6, this is the target date to have migrations completed.
Of course, if you're on Drupal 6, your site won't suddenly stop working at that point -- it will continue running as is without updates indefinitely. It's just with nobody paying attention to the code, you're incurring a gradual, increasing risk of something going wrong that will be hard/expensive to recover from.
So if you're one of our customers still on Drupal 6, expect to hear from us in a couple weeks about the upgrade process. If you're not one of our customers but are on Drupal 6, we'd be happy to get you to Drupal 8. And if you're on Drupal 7, hang tight -- there are plenty of great reasons to upgrade to Drupal 8, but there is no urgency, and this process will be easier/more complete in 6 months or so.
And finally, as we go roaring into the holiday season, I just wanted to extend thanks to our clients and community for your support of our business, have a great Thanksgiving!
- John and the Freelock team
not true
This is so tragically not true it's not even funny. Now instead of php + drupalisms we have php + drupalisms + symfonyisms + drupfonyisms + backbone-isms + underscore-isms + ?.
I've already seen symfony developers posting about how they're trying to wrap their head around drupal 8. Why? The entire point of adding symfony to the mix was to remove that obstacle. There was supposed to be nothing to wrap their head around.
In order to properly 'get off the island', drupal should have been completely rewritten from the ground up around symfony-- without any drupfonyisms. Since drupal NEVER supports backward compatibility, what was there to be gained by only partially converting to symfony and leaving a ton of WTF's for BOTH drupal devs and symfony devs???
imo this was a complete lack of vision. Instead of migrating to symfony intelligently and with careful forethought and planning, it just sort of happened piecemeal (oh, lets migrate the menu router to symfony.... oh wait, lets migrate the theme system to twig.... oh wait, lets migrate to symfony dependency injection... etc etc). What resulted is a frankenstein of both.
If anything, this will actually exacerbate the issue of false drupal devs. Instead of random php developers calling themselves drupal devs (and charging accordingly) who end up posting to stackexchange about how to db_connect to a different db, we'll have certified symfony developers (also charging accordingly) posting to stackexchange about how to specify "database_driver: pdo_mysql". Surprise-- the joke's on you symfony dev-- it's still done the drupal7 way)!
And lets not even go into the fact that, after waiting for over 2+ years, someone unwrapping their brand spanking new drupal 8 site will have to deal with an incessantly and unrelenting blinking page on every single page load as the toolbars spasmodically re-render (tried it with 3 browsers under 2 operating systems locally installed and with simplytest.me).
Knowing both drupal and symfony this is actually great for me-- it will keep me busy well into retirement, lol. But the amount of spinning going on right now to explain how gr8 this is all is, is absurd.
Useful Article!
Excellent article indeed, content management on web definitely can change even it change very frequently and there are many guidelines from Google so they should follow otherwise they can penalize. I also did the same on my professional logo design services website and I got good results indeed.
Content management is…
Content management is everything in today's era, such an informative article, thanks for sharing.
Add new comment