Drupal 7 was released in early 2011. It lasted 14 years, which is a long time for a software product, and something that powers websites. Sure, it's gone through a number of updates in that time, the latest version being Drupal 7.103.
Compared to previous Drupal series, it had a number of improvements built into it:
- Support for fields for any content type, user profiles and comments (instead of the former Content Construction Kit module)
- Multilingualism has been integrated directly into the core, making it easier to create multilingual websites
- A system for controlling access to individual content nodes has emerged
- There was built-in support for working with image editing, support for multisite instances, RDF, support for long running tasks
- The installer went to run from the command line
- Database abstraction brought a query builder for building queries and statements in an object-oriented way. SQLite support has also been added.
- Secured cron against arbitrary calls from outside, as well as got better password security instead of the previous MD5.
- Vertical tabs appeared in the administration and there was standardized support for visual editors. Unfortunately without a specific editor in the core.
There were certainly many more changes that made Drupal so popular. The threshold for learning it was much lower than it is today. The system requirements for the server were also ridiculous from today's perspective (PHP 5.2 and a memory limit of 40 MB), so it's safe to say that it ran everywhere. That wasn't true, unfortunately I still remember how Czech hosts of that time had a problem to set up even something like that.
Compared to WordPress, Drupal 7 had one major handicap. It was often called a content management system for programmers. Not only in terms of building the site, but also in terms of operating it. That's because while it had editor support in it, none was included in the base installation. This led to all sorts of basting, and although adding CKEditor or TinyMCE was a matter of moments, it wasn't rare to see sites where the operator was forced to manually type HTML tags into a box.
Originally Drupal was supposed to end sometime around the time of covid. The end of its support has been extended several times due to its extremely large user base. And the first extension came just with covid, when site operators had other concerns than migrating to a new version or another platform.
Drupal 7 was a great system for hobby developers
Seven was the last version of Drupal written the "old way". It was, in a way, a PHP framework to build on top of, but it was a fairly easy to understand affair for anyone who had learned PHP from the old days. No lots of controllers, methods, classes and who knows what. A module was usually a single file with eventual includes, a seemingly obvious set of hook_* functions that you drilled down or easily found in the documentation and used to make the first one last.
Preparing the visual part of the website was about PHP files with HTML tags and styling. Sure, it was never that easy to code any HTML and put in a few bits of PHP from Drupal. Not all HTML output went customized or easy. But a lot of casual developers managed it.
From trainings, from readers of my books, from meetings and from practice, I have a lot of contacts to Drupalists from the ranks of small businessmen, teachers, marketeers, newbies, parishes... In short, it has impressed a lot of people with its flexibility of working with content and defining what the user will fill in where and how it will be displayed. I have to say that it has also brought me many friends and acquaintances.
With the advent of Drupal 8, unfortunately, there was a big breakthrough. The new generation, including the current version 11, is built on the Symfony framework. While the controls are similar and the concepts work the same, the development is different. Hooks were abandoned in favor of objects and classes, Composer came along, the whole thing moved closer to the modern PHP world but further away from the hobby developers.
And I'm not talking about the visual preparation in Drupal. To build a new theme look requires knowledge of working with the Twig templating system. We have a lot of configurations in YAML. There's a lot that a Drupal developer needs to know, and I can kind of understand why some people get discouraged. On the other hand, he web development in general is getting more and more complex. Both technically, marketing-wise and legislatively.
How I built websites on Drupal 7
The transitions from Drupal 6 were not always as easy as one would think. I remember the hassle of saving images on some sites. I soon found a way to build sites on 7 in a way that was pleasant to navigate.
Everywhere I used the tried and tested combination of the TinyMCE editor with the IMCE file manager. I worked extensively with different types of content. Views were of course essential for various listings and user filtering. Everywhere I added a module to transliterate file names so that downloading would not be a problem. Redirects, duplicate addresses, SEO descriptions, sitemaps, share buttons... were dealt with.
I loved the Display Suite. It allowed you to configure the display template without having to go into the code, although from today's point of view I find just editing in the code much faster and more flexible.
Over time, I added the Paragraph module for more flexible component-based page creation, and today Drupal 10/11 actually forms the basis of how editors work with Drupal.
It's actually funny. Drupal current generation has all this and much more right in it, it has media management ala WordPress, but yet it still inserts a dose of nostalgia that it used to be easier and faster.
I started learning the Symfony framework before Drupal 8 came along, and later I found out what a lucky choice it was, because I could then use everything in the new generation of my favourite content management system and jump into 8 all the more quickly.
Migration to the new Drupal
Enough reminiscing. Drupal 7 is now a thing of the past, albeit a lingering one for some if it still powers the web. If that's the case for you, it would probably be a good idea to upgrade to a new version of Drupal.
The problem is that while it does have a migration to pull data from the old site, as well as from other sources, using the migration API is different than running an upgrade process between versions, like it was when moving from version 6 to 7.
Now you actually have to build a new website and pull in the old content. It's quite a bit of work, and not everything is likely to be set up the way it would be when you build a new site manually on Drupal, but it's one way to go. Expect to have to make a whole new theme look and feel, and you can't avoid Twig.
Drupal 10
What other alternatives to migrate from Drupal 7?
An interesting alternative to Drupal 7 is the Backdrop content management system. When some active members of the Drupal community found out where 8 was going, they took the existing version, made it a fork, a derivative, and started building a new system based on it. Backdrop retains the simplicity of Drupal 7 in terms of control and development, while adding new functionality. It's still based on the original code concept, which is all good old PHP.
Tip: Backdrop has an upgrade mechanism for easy migration from Drupal. Learn more in How I migrated sites from Drupal 7 to Backdrop.
Another alternative, of course, is to switch to another platform. The biggest competitor, WordPress, is the logical choice. I have experience with it too, and for a small website I would recommend it over Drupal at the moment. It means more work than switching to Backdrop, but again, you can easily import existing content.
Backdrop admin interface
In truth, websites running on Drupal 7 are not only technologically old, but morally old as well. Unless some inexperienced developer handed it to you as a new one last year. So I wouldn't bother upgrading at all. I recommend clients not to think this way and just build a new site.
You need current graphics, current communication concepts and marketing, current technologies for fast loading and compatibility with web browsers, etc.
The content pages will thus usually be created in a new and different graphic. In the case of my sites, additionally based on the partitions from the Paragraph module and in the code on Single Directory Components. So we prepare and fill everything manually.
Data such as products, news, people, etc. are something else. Here we could use the migration API in the current Drupal. It allows you to import data, revert the import back to the original state, and play around with it that way. But I've always found this significantly more complicated than writing an import mechanism for Drush, running it in the command line and being done in a minute.
In the old Drupal I can use the Views Data Export module to prepare exports to XML or CSV and then import them as needed.
Don't wait any longer
Whether you're considering staying with Drupal or switching to another platform, you shouldn't delay. The end of Drupal 7 support doesn't mean it stops working overnight. But if a security flaw is discovered, you won't get a patch for it anymore (although large companies will pay LTS support for the corresponding money). If your hosting drops support for the old PHP after a while, Drupal won't run there anymore. And similar problems will increase.
