Should I Use Drupal 7 or Drupal 8?
Over the last 15 years, Drupal has earned a reputation for being the most powerful open source content management system.
Yes, Drupal may be harder to learn some alternatives, but it compensates for this with its options and flexibility.
Does Drupal 8 continue this tradition? I recently needed to find out.
I’ve been using Drupal 7 for several years and was asked to use Drupal 8 for a new site. This post contains my thoughts after evaluating Drupal 8 for the first time.
Core Modules
With Drupal 7, there were still many modules that needed to be added before it was truly ready to go. Drupal 8 has improved on this significantly. The ‘core’ package now includes many modules that with Drupal 7 had to be installed individually. Most notably – Views and the WYSIWYG editor. This makes installation much more of an ‘out-of-the-box’ process.
Out of the box, Drupal 8 installs following modules:
Automated Cron, Bartik, Block, Breakpoint, CKEditor, Classy, Color, Comment, Configuration Manager, Contact, Contextual Links, Custom Block, Custom Menu Links, Database Logging,Block, Breakpoint, CKEditor, Classy, Color, Comment, Configuration Manager, Contact, Contextual Links, Custom Block, Custom Menu Links, Database Logging, Datetime, Field, Field UI, File, Filter, Help, History, Image, Internal Dynamic Page Cache, Internal Page Cache, Link, Menu UI, Node, Options, Path, Quick Edit, RDF, Search, Seven, Shortcut, Stable, Standard, System, Taxonomy, Text, Text Editor, Toolbar, Tour, Update Manager, User, Views, and Views UI.
Theming
Theming is not significantly different. You still need access to FTP to create a new theme or sub-theme. The .info files have become .info.yml files that use the YAML syntax, but this is easy to use. Unlike Joomla and WordPress, Drupal 8 still does not offer out-the-box CSS editing in the admin section. If you would rather make theming changes through the back-end interface, you can add styles, using the CSS Editor module.
OPcache
Upon installation, Drupal 8 calls for PHP OPcode caching, claiming that OPcache can improve your site’s performance considerably. My shared server does not have this installed and a small site functions well regardless.
Security
Drupal 8 also takes security seriously and calls for trusted host patterns to be specified in settings.php. You need to add the following:
$settings['trusted_hwp_patterns'] = array(
'^example.com$',
);
at the bottom of the file.
My first attempt created an error The provided host name is not valid for this server. I did find the answer on drupal.stackexchange.com but not surprisingly there is less of a knowledge base for Drupal 8. After all, Drupal 7 has had a long, long run.
Dashboard
The administrative interface is cleaner and easier to use, but Drupal is still harder to fathom than the likes of WordPress and Joomla. In fact, the admin menu has not changed very much at all. The admin menu can now be viewed both vertically and horizontally at a click. However, this is not immediately apparent. It is possible to click in error and then wonder what happened to the menu bar.
Contrib Modules
The biggest concern is that many favored modules are not ready for Drupal 8. Rules, for instance, still only offers a pre-release version for Drupal 8. Its documentation is unavailable. With the #d8rules website calling for its implementation, the status of this project is unclear. That sort of thing makes developers nervous.
If you need some complicated functionality that was possible with some of Drupal 7’s modules, it is best to check their status before assuming that they will be available and fully functional in Drupal 8.
End of Life
There is still no clarity on Drupal 7’s end of life and there appears to be a good migration plan for sites moving to 8, so there’s no huge incentive not to create new 7 sites.
Conclusion
Easier and quicker to install, Drupal 8 is a good choice if you want most of Drupal’s functionality without having the cloud of future migration looming above you. If you are expecting to have all the familiar modules available and ready to enhance the experience, you may be in for a nasty surprise.
The back-end is cleaner and nicer to use. It’s quicker to install with the core modules all in one package. There’s no fiddling around trying to get the WYSIWYG editor to work.
If like me, you rely on forums to help you answer development hiccups, you may feel more comfortable with Drupal 7. Every problem ever encountered is well documented and help is on hand. With Drupal 8 however, you may well find yourself in pioneer country.
Essentially Drupal 8 isn’t a major change and if you are familiar with Drupal 7 you should have no problem getting comfortable with the new system.
Hi,
and what do you think about D7 fork Backdrop? Is it an alternative?
Regards, Karsten
Hey Karsten,
I help to contribute a little bit to the Backdrop CMS project. I haven’t followed the project closely, but I would definitely say it is an alternative to D7. Some people would call Backdrop Drupal 8 and call Drupal 8 Drupal 9. The Backdrop team is more focused on small to medium-sized businesses/organizations or sites where the user still maybe has shared hosting and is more of a site builder. Backdrop is nice to those people while Drupal 8 totally ignored that demographic. The Drupal 8 core team still feigns an interest in the site builder but they do it in a “My company is building a SaaS and so I need to put into Drupal what my company needs. A Composer GUI? Come on guys, just give up now and admit you are solely enterprise focused.
Also, people have some misconception that Backdrop wants to stay the same as D7 and use procedural PHP forever. That claim is ridiculous. The config initiative in D8 is very similar in Backdrop, except they smartly used JSON to actually have the config in code instead of the database…blew my mind when I found out most config checking in D8 is still in the db. More modules were put into Backdrop core. It seems way faster than D8 stock install…lots of changes from D7.
But you know what the best part is? Converting modules from D7 to Backdrop can sometimes only take an hour or two. Try that with D7 -> D8 and you will enter a world of pain most times.
I actually would prefer to use Drupal 8 for learning more OOP coming from learning programming in procedural PHP, but I really don’t like how Drupal is handling their project and community. If you are a small or medium-sized entity and like non-BC breaking changes, then I highly suggest looking into Backdrop.
Generally I think that using Symphony for PHP is a mistake. The idea with software is to make it better and simpler, not making it more sophisticated and trendy. While symphony may hold set of good toolkits and some good ideas, it is led by many misconceptions of trying to imitate concepts brought from Java EE. The problem is that ideas suitable for Java, a language that need to be compile for any software change, are not necessarily suitable for PHP that works with Interpreter. For example, what’s the point of abstracting request-controllers with descriptors, and inventing whole new syntax to pass arguments? After all, isn’t the most direct and flexible approach when working with interpreter, is to the use code for holding such kind of setting?
In the case of Java it is different. You may want to have system that you can configure with descriptors without having to recompile the code. But this is Java. PHP does not have this problem.
I worked years with Java, including development of few BPM like frameworks. As such I have some different perspective of when a Framework is necessary and when does it turn to be overhead. And clearly, Symphony was created without this perspective in mind. Framework should make R&D more productive, meaning making more easy to create many features across shorten time. Symphony does not help this to happen. It put the focus in the wrong places and generate non proportional projects. Some example:
– It promote the the concept of importing many libraries and more libraries and more libraries turn your project into giant, many time without any justification. Why? Couldn’t the core do the same?
– YML? Why YML? a syntax that sensitive to spaces and tabs – so prone for mistake. What’s wring with Json?
– Service? Why, is this structure realy necessary. Couldn’t Static functions provide much more direct and easy solution?
– ORM someone? Why, unless this is relay necessary?
It is important to understand that abstracting things does not necessarily improve productivity. There is no reason to look on any small or medium size monolithic service (implemented on single site) as kind of distributed system.
I tried Druapl 8 a year ago. This is the first time I had to use Drush in development environment, because apparently a small mistake in description had become a nightmare when it cached in a an abstraction layer that is clearly not necessary (symphony). In addition, after having some learning curve of working with Drupal-7, I suddenly had to start all over again learning the methodology. Considering the Drupal has a high learning curve this raise serious questions, isn’t it?
Do I want to deal with the “product” or do I want to deal with Drupal? (and I want to deal with the product, with the advantage that Drupal is providing)
Yes, there are probably 10000 things that could be improved in Drupal-7, but I think that Drupa- 8 should have an been created as an improvement to Drupal-7 major problems but not as a complete new creature.
My choice is therefore Drupal-7.
Composer is the big reason!
I recommend editing this article’s “Core Modules” section’s last paragraph which lists the D8 core modules, and either boldface or italicize those modules which D8 includes but which are either contrib-only, or not available at all, in D7.
You should also address the performance issue. D8 is much slower than D7 out-of-the-box, but adding modules to either slows it down further. Since D8 includes more core modules than D7 does, this is to be expected. A fairer benchmark would compare an out-of-the-box D8 install against a D7 install with contrib modules added to match as closely as possible the core modules of D8.
Also, the modules in that paragraph from “Block” through “Database logging” are duplicated. The comma after the first occurrence of “Database logging” has no space after it, and is immediately followed by the second occurrence of “Block.”
Moreover, you list Themes in there as well as Modules, and those should either be separated out or styled differently and the lead-in text amended appropriately. Bartik, Classy, Seven, and Stable are Themes, not Modules (and you’re missing the Stark Theme).
I have been building Drupal sites since Drupal 5 – I manage my own servers from the ground up. I have yet to successfully build a drupal 8 site with all the composer dependencies in a reliable fashion that I can move to production service. Every time I find instructional material on Composer/Drush/Drupal8 installation, it is outdated by some system upgrade or change. I am not adverse to change – but change without reliable documentation does not work for me.
“Theming is not significantly different.”
As a Drupal theme developer, i entirely don’t agree with this point. First: Setting some color values in the backend has nothing to do with theming. PHP Template is replaced by Twig, the whole libraries yml thing is a huge difference – this is not just another file extension, we have a deep responsive integration with breakpoints etc. We now can change nearly every piece of markup, because we have a lot more template files as in D7 instead of hard coded markup, we now have much better (coding)standards, …
So we got extremly more freedom on the frontend side. From my point of view, D8 is an immense step forward for theme developers.
I have edited settings.php by entering the above code on my D8 site. I obviously substituted example.com with the name of my site (webameriqa.com).
However, the “Trusted Host not enabled” error
won’t go away.
I am still debating if I go 7 or 8 on my next project but I’m worried about the lack of modules available, so I’ll probably stick with 7 for a while. Thanks for this, it really helped.
Note: You added those modules twice in the description: Block, Breakpoint, CKEditor, Classy, Color, Comment, Configuration Manager, Contact, Contextual Links, Custom Block, Custom Menu Links, Database Logging.
Great blog! Though there is a lot of confusion among the developers with Drupal 8 vs Drupal 7 modules. I hope their queries will get solved after reading this piece of content.