This is the conundrum some may be facing when moving away from Drupal 7.

If you or others in your organization are battling with this question, there are several considerations you should make before choosing to move away from the Drupal platform. We'll cover them in 5 short reads:

• Part 1: Coming to grips with the task
• Part 2: Comparing apples to apples
• Part 3: Better, or just different?
• Part 4: How much are you really outsourcing?
• Part 5: Knowledge attrition

Comparing Apples to Apples

Given the importance of your organization’s website, it’s always good to explore your options. Beware, though, the natural inclination to compare the bells and whistles of a different platform (proprietary or otherwise) to those of your current Drupal 7 website. Here’s why that’s important.

An organization’s website often involves multiple people with different areas of concern. Those not involved with the technical aspects may be tempted to blame any shortfalls of your current site on the Drupal platform itself, and convincing them otherwise will be impossible without a side-by-side comparison of features.

You’ll need to remind them Drupal 7 was first launched in 2011. Once Drupal 8 launched in 2015, all the innovation and updates went to the new version, not Drupal 7. In other words, there is a good reason why your Drupal 7 interface looks comparatively outdated. 

Another thing—and this is important—Drupal 7 runs on PHP 7 which will also sunsets in November of 2023. Drupal has no control over that. Staying on Drupal 7 isn’t even an option unless you’re going to pay for third-party PHP security support.

What I’m getting at is, the shortcomings of your current Drupal 7 site are related to the version of Drupal, not the Drupal platform. Make sure you’re comparing the new features of any non-Drupal solution to the new and improved features of Drupal 9 and 10 before making a final decision.

Analytics integration, content moderation, publishing workflows, SEO, accessibility tools and API integration with third-party services (Mailchimp, for example) are all available for Drupal 9 and 10 via well-supported, contributed (free) modules if they aren’t already in Drupal core. 

Why?

Keep in mind the operational upheaval that results from moving to an entirely new platform. You may be asked to justify why you’re going to force maintainers to relearn how to do their jobs. Are you really making things better overall, or just different?

This is the conundrum some may be facing when moving away from Drupal 7.

If you or others in your organization are battling with this question, there are several considerations you should make before choosing to move away from the Drupal platform. We'll cover them in 5 short reads:

• Part 1: Coming to grips with the task
• Part 2: Comparing apples to apples
• Part 3: Better, or just different?
• Part 4: How much are you really outsourcing?
• Part 5: Knowledge attrition

Better, or just different?

So you’ve set up a Drupal 9/10 sandbox to evaluate against other platforms. One critique often levied against Drupal is its complexity, usually in reference to the editing interface. This is another area the Drupal community worked hard to resolve, and Drupal 8+ provides numerous tools to simplify the user interface substantially. 

As a side note: Yes, the Drupal system is complex. So is Adobe Photoshop. And yet, it’s the industry standard for graphics. It’s professional-grade software used by skilled artists to produce breathtaking results in a variety of styles. You’re only going to get so far with the editor on a smart phone.

Maybe your organization’s website will never utilize Drupal’s flexibility, in which case your options are open. However, if there is any chance of you needing to scale up your website to compete in an ever-more-demanding marketplace, or reach that market across numerous channels, there is no better system to help you meet those challenges than Drupal. 

Getting back to the ‘Better vs Different’ statement, you’re likely to find some tasks are just as easy, some easier, while other tasks seem confusing or difficult. For example, one proprietary system I evaluated for a previous employer was based entirely on XML templates. Creating a new page for the website was simple enough, but adding it to the site’s navigation required finding and editing a completely different file. This is counter-intuitive for anyone accustomed to clicking a checkbox on the Drupal content creation form.

To be fair, there will be some re-training required to use the new versions of Drupal, too. So you’ll want to keep your eye on the big picture because at some point you’re likely to wonder whether the new platform really represents a measurable improvement over the Drupal experience, or just a different one.

Granted, this is all subjective. Every editor will have a slightly different response. But it’s worth considering if the potential benefits of changing platforms justifies making editors learn all-new procedures over an upgrade to those they’re already familiar with. 

Still thinking of switching platforms?

If you go with an entirely new platform, how long will it take to get your content editors up to speed and, more importantly, who is going to train them?

This is the conundrum some may be facing when moving away from Drupal 7.

If you or others in your organization are battling with this question, there are several considerations you should make before choosing to move away from the Drupal platform. We'll cover them in 5 short reads:

• Part 1: Coming to grips with the task
• Part 2: Comparing apples to apples
• Part 3: Better, or just different?
• Part 4: How much are you really outsourcing?
• Part 5: Knowledge attrition

Knowledge Attrition

This article is most applicable to organizations managing their web presence internally. 

Depending on your situation, one could argue moving away from Drupal is like throwing decades of organizational knowledge out the window. Given the considerable difference between version 8+ and Drupal 7, however, one could also argue the disparity between keeping or leaving is minimal because even if you stay with Drupal, it can feel like you’re still starting from scratch. That's understandable, but easily debatable.

However, this is not the only way for an organization to lose valuable knowledge.

As mentioned earlier, Drupal is now built on Symfony, a very popular framework for PHP—the language that powers almost 80% of today’s websites. Drupal also ships with the JSON:API module allowing multi-channel, decoupled access to your Drupal content using JavaScript or any other language. In short, staying with Drupal gives your front and back end developers the opportunity to use and improve in-demand skills. There’s little need to go job hunting because the jobs will always be there.

Not all content management systems are created equal, though, even those built with PHP. As part of your evaluation process, be sure to interview other organizations currently using the platform. Ask if they are having any challenges recruiting and retaining developers who want to work on the system. Why is this a good idea?

If the system or its underpinning language/technology is not in high demand, why should developers bother learning it to the detriment of more in-demand skills? 

Extending support for Drupal 7 is in part a testament to Drupal’s popularity. Gaining new proficiencies on an already-popular platform is job-security for your developers. It also means a large pool of replacement candidates if they choose to leave.

One other thing for a large organization to consider is how much of the migration will the vendor handle? Often, the initial contract will include migration of a limited number of sites. Your developers will then be expected to use those sites as models to write migration scripts for everything else. If you lose your good developers, you may need to add long-term maintenance and development to your list of recurring fees.

Lastly, in terms of long-term technical support, learning how to do anything on Drupal is simply a matter of figuring out how to ask the question in Google. Between the documentation on the drupal.org website, thousands of blog posts and freely available video tutorials, the answers to any question are out there. 

You’re not going to get that level of knowledge-share on just any CMS, and definitely not on any proprietary system.

What to decide?

The decision “to Drupal or not to Drupal” is as individual as each organization. Whether you stay with Drupal or move to a different CMS, it is inevitable A) your site will have to be rebuilt, B) new learning will be required, and C) some level of continued training and support for content editors will be necessary. 

What is also inevitable are the new, modern features you will enjoy. 

Ultimately, the question is whether the benefits of a new platform outweigh the total cost of the platform including the recruitment and retention of competent developers, if applicable. 

Staying with Drupal gives your organization a scalable platform and access to leading technology, top developer talent and a huge community of free, quality technical resources. And $0 licensing fees. So what’s not to like about that?

This is the conundrum some may be facing when moving away from Drupal 7.

If you or others in your organization are battling with this question, there are several considerations you should make before choosing to move away from the Drupal platform. We'll cover them in 5 short reads:

• Part 1: Coming to grips with the task
• Part 2: Comparing apples to apples
• Part 3: Better, or just different?
• Part 4: How much are you really outsourcing?
• Part 5: Knowledge attrition

How much are you really outsourcing?

As part of its licensing fees, the vendor of a proprietary system will likely provide regular training, resources and support for your editors. On the surface, this sounds fantastic. The vendor is going to liberate you from the daunting responsibility of documentation and training! Or will it? 

There are two aspects to using any CMS platform: Individual and Institutional.

The Individual aspect—how do I create an event for the calendar—is something the vendor can provide resources for.

The Institutional aspect covers:

• how do we tag events for proper categorization;
• prevent the creation of duplicates;
• share access with other departments

Topics like these can only be conceived, documented and trained by the institution itself. When it comes to using the platform as part of your organization, the vendor is likely to have little more than suggestions.

This is because the procedures for managing and sharing assets across departments will be different for every organization even if they’re all using the same platform. If you expect everyone to follow a uniform procedure, that procedure will have to be documented and people will have to be trained, but it will not be part of anything provided by your vendor. 

This is especially important if the majority of editors in your organization are transient workers such as student employees and interns. While the vendor’s training resources will indeed be valuable in keeping high-turnover positions up to speed, they won’t be enough to completely replace the knowledge lost when transient employees leave for other opportunities.

Speaking of lost knowledge, consider the knowledge you lose when more permanent employees find the exit door. Could moving away from Drupal cause you to lose regular employees?

This is the conundrum some may be facing when moving away from Drupal 7.

If you or others in your organization are battling with this question, there are several considerations you should make before choosing to move away from the Drupal platform. We'll cover them in 5 short reads:

• Part 1: Coming to grips with the task
• Part 2: Comparing apples to apples
• Part 3: Better, or just different?
• Part 4: How much are you really outsourcing?
• Part 5: Knowledge attrition

Coming to grips with the task

The announcement to extend support for Drupal 7 through November 1, 2023 was welcome news for thousands of organizations still running Drupal 7 websites. It also exposed a huge vulnerability for competing platforms to exploit. 

Seven years after the release of Drupal 8, the hurdle of completely rebuilding a Drupal 7 site is a serious pain point for many, and companies hawking their own proprietary solutions want to leverage that pain to increase their customer base. With well over 400,000 websites still running on Drupal 7, the opportunity to do just that appears considerable. 

These companies will find clever ways to explain and justify their licensing fees promising your organization will never have to completely rebuild its website ever again. Yes, there will be considerable time and cost getting moved onto the proprietary system, but in return you’ll get slick new tools to help with accessibility and SEO. Smooth, new feature rollouts and freedom from long-term platform management tasks will sweeten the deal even further. So what’s not to like about that?

In this series we'll cover a number of things your organization should consider when making a decision, beginning with Drupal’s latest release.

Drupal 10 is here!

A previous coworker of mine put it very well: [Until version 8] every major release of Drupal required not only a completely new track, but a completely new train itself.  This is something the Drupal community worked very hard to fix.

When Drupal 8 was released in late 2015, Drupal 7 had been the premier version for about seven years. In the seven years since then, we’ve witnessed the release of 9 and as of December 2022, version 10. Many of our clients who made the jump to Drupal 8 are already on Drupal 9 and in a very good position to move – with little cost – up to Drupal 10. That’s because the underlying framework (Symfony) is common to all these releases.

The vendor of a proprietary solution will happily tell you future upgrades on their system will be painless. Thanks to the changes introduced with Drupal 8, ‘a painless upgrade’ is not just a Drupal promise, it’s the reality.

Migrating to anything from Drupal 7 will be hard.

Moving off Drupal 7’s antiquated system of procedural code to a modern, object-oriented framework is a big change, there’s no way around it. Whether you stay with Drupal, choose another open-source platform or a proprietary one, it's going to be a heavy lift especially for those running highly customized websites.

If you work with external vendors, it will require a good deal of time and cost to rebuild your theme and migrate content to the new site. It isn’t (unfortunately) just a matter of clicking “upgrade.” The many reasons for this are best detailed elsewhere, but the bottom line is, budget for the upgrade. If you haven’t updated your site in years, it’s probably time to rebuild your content and design anyway. 

If you manage your site internally, the time and effort will fall to your developers. Drupal 8 and higher requires your team to learn Twig (the templating language in Drupal 8+) and become familiar with Composer and Drupal’s underlying framework, Symfony.

This might seem like a lot, but bear in mind, moving to a proprietary system is not a substitute for new learning. Any new system will have its own code and approaches to site building your developers will have to learn. And, before anyone can begin learning a proprietary platform, your organization must select the vendor, negotiate the contracts and participate in the vendor’s discovery process. Depending on the size and complexity of your website(s), it could be another year before getting into the nuts and bolts of actually moving and theming your content. 

Upgrading to a newer release of Drupal—even with the help of an external vendor—means the learning process can start today.

Okay, so?

Migrating your Drupal 7 website will require a heroic effort. Period. But do you stay with Drupal, or buy into the promises of another platform that, for the moment, sound so tantalizing? Well, once you develop the criteria to measure your success in this effort, your first concern will be to ensure you're comparing apples to apples.

Emerging on the heels of a few years that brought epic levels of setbacks, uncertainty, and upheaval, 2022 was marked by a sharp focus on powering forward, connection, and leveraging all that Drupal has to offer.  During a year in which defining and gaining traction within a new normal was an overarching goal, it’s not surprising that Drupal How-tos drove high levels of interest in 2022.

Direct .mp3 file download.

We talk with Alison Jo McCauley about how to be a mentor, including skills required, how to manage a mentor/mentee relationship, and tips for success.

Stan Ascher is the name of the person Alison mentioned during the podcast who played guitar during lunch at GovCon.

URLs mentioned

• #mentoring channel on the Drupal Slack workspace

DrupalEasy News

• Professional module development - 15 weeks, 90 hours, live, online course.
• Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Getting Personal With Dates and Times Image mandclu Mon, 01/02/2023 - 09:12 Body Conversations with other people in the Drupal community, and related communities, has been a continued source of inspiration for me. Back in September, in a discussion at the San Francisco Drupal Users Group, someone mentioned a Backdrop module that uses Javascript to automatically format dates and times in the timezone of any visitor using Javascript. It seemed like a really interesting idea, and I wondered if there was something in its approach I might be able to bring to Smart Date. But it was a busy time, and I noted it down, but forgot about it. It was during the recent Drupal 10 Launch Party that I was reminded about the idea of using Javascript to format dates, so they would be automatically in any visitor's timezone. The same idea had been implemented effectively for that site'sMore

How To Accelerate Drupal Development with Lando Shreyal Mandot 03 Jan, 2023 Subscribe to our Newsletter Now Subscribe Leave this field blank

Since there already are many development environment options available today like DDev and DockSal, why should you go for Lando for a Drupal setup?

Well, the reason is simple!

Lando is easy to work with, portable, and fast. And Lando can run anything, anywhere! It is the most approachable Devops tool that is quickly gaining popularity. A simple way to describe Lando is that it’s automated environment setup allows for easier development.

In this article, we’ll talk about Lando, its setup, architecture, and how you can use Lando recipes with Drupal, along with Lando configuration. So, let’s get started!

What is Lando?

Lando is a powerful local development environment and DevOps tool which is free and open source, built on Docker. It is compatible with local environments on OSX, Windows, and Linux. Using Lando, you can prepare various types of services and tools effortlessly. Lando allows you to set different services for every project without affecting other projects working on Lando.

As a developer, it becomes super easy to set up the configuration in the service and tooling codebase, as well as the application configuration that needs to be run. Once the setup is complete, developers can enter the repository to run Lando and begin working on the project in complete isolation without disturbing the consistency in their development environments.

How does Lando work and Why should you use it? (Lando Recipes & Drupal)

You’re already aware of what Lando is and its compatibility with Drupal. Now, as some of you may be familiar with Docker, you might be wondering how similar Lando and Docker are. The Lando setup configuration is similar to Docker compose and the isolated development environment is similar to that of Docker containers.

But such a similarity raises the question: why do you need Lando when you have Docker installed? Here’s why:

• Lando enables you with a more organized process of using Docker containers with the help of pre-defined recipes.
• When the docker container environment isn’t compatible with Lando recipes, you can easily define a container by defining a Lando service. You can do this without typing docker exec commands or setting up Dockerfiles.
• You can use your own custom docker compose files instead of Lando recipes while you benefit from the local development networking.
• Additionally, you can use SSL handling per container, set up proxy and custom URLs for your services, and use simple build and run steps.

If you need help learning about the system requirements and installation of Lando for Drupal 9, refer to our blog here.

Configuring Lando Recipes

Recipes are a combination of services, proxies, and tooling designed as start-state-of-sane defaults for a particular use case. Lando's recipes are the highest abstraction of Lando, containing common combinations of services, events, and tooling.
 
Services are simplified but highly configurable docker containers. They can run build steps such as installing a PHP extension or running yarn install. Tooling allows users to run arbitrary commands or combinations of commands or combination of services when invoked. They’re incredibly useful while being super simple to use.

Config allows you to set some more important things your recipe provides. With Lando, you can configure and make changes according to your requirements.

For a better understanding, let’s take a deeper look into Lando services and tooling.

Lando Services

Lando services are simplified and highly configurable Docker containers. They should be able to run build steps and can be overridden to low levels. Services get automatic networking and security features.

Some of the most useful services are:

• Elasticsearch/Solr
• Mailhog
• Node
• PhpMyadmin
• Redis
• Memcache
• Varnish

 

Services - Build Steps

If you need additional on-server dependencies like PHP extensions or node modules, it sounds like a build step.

There are four major build steps:

• “Build” : runs as "you" and before your service boots up
• “Build_as_root” : runs as root and before your service boots up
• “run” : runs as "you" and after your service boots up
• “run_as_root” :  runs as root and after your service boots up

 

How can you execute the four major steps?

• Use build to install application dependencies that are needed before you start your application
• Use build_as_root to install low level server packages required by your application
• Use run to install application dependencies or run build steps that require your application be started first
• Use run_as_root for any other post-start root level one-time setup commands.

Events

Events allow the user to run an arbitrary command before or after certain parts of the Lando runtime. In simple words, you can automate commands or tasks you might often or always run, either before or after something happens. Lando and App runtime events can be hooked into pre- or post-events.

You can also hook into pre and post-events for all tooling commands.

Adding Tooling for Lando Apps

Tooling allows you to run arbitrary commands on arbitrary services. Every Lando Drupal recipe ships with useful dev utilities. These are the commands that display on the Lando help page, such as

• Lando php
• Lando mysql
• Lando db-import
• Lando db-export

Here, using tooling we can create our custom commands and can define what these commands will do internally and on which containers. These also help us to expose certain services directly to the developer and automate processes.

Tooling - lando drupal-check

Whenever we execute this command, it will go into the app server service and will run the command to see if the code is as per the Drupal standard. If not, it will display appropriate error messages.

Tooling - lando xdebug-on

This command will set and enable the xdebug-on on the app server for debugging.

Next Steps?

Once you’ve set up Lando for your Drupal website, you can create custom services, and recipes, and use specific docker images for your services. Lando allows you to integrate with different server configurations and CI/CD. Additionally, you can also learn to automate testing to move ahead with your Lando recipes in Drupal.

Lando and Drupal blend well. And if you are already familiar with Docker and docker compose, setting up Lando for your Drupal website and using its recipes, combining the events, services, and tooling would be super easy for you!

Found this article useful? Here’s a really tiny URL of this article for you to copy, embed, or share: //--> //--> //-->

bit.ly/3WyZNoB

Click to copy URL to your clipboard

Author: Shreyal Mandot

Meet Shreyal Mandot, our Acquia-certified Solution Architect and Drupal 8 Grand Master, who has a passion for new technologies and travelling. In fact, he's already planning his next trip to Paris! Besides working, Shreyal enjoys road trips, swimming, and basketball.

Drupal 9 Drupal Development Drupal Planet

Leave us a Comment

 

Recent Blogs

Image

How To Accelerate Drupal Development with Lando

Image

Everything you wanted to know about Drupal 10 - Q&A with Experts

Image

7 Drupal Security Strategies you need to implement right away! (Includes top Drupal 9 Security Modules)

Want to extract the maximum out of Drupal? TALK TO US

Featured Success Stories

Upgrading and consolidating multiple web properties to offer a coherent digital experience for Physicians Insurance

Upgrading the web presence of IEEE Information Theory Society, the most trusted voice for advanced technology

Great Southern Homes, one of the fastest growing home builders in the United States, sees greater results with Drupal 9

View all Case Studies

Drupal 10 has finally been launched! But did you know that from now on CKEditor 5 will be the default WYSIWYG editor in Drupal?

After a two-year-long, massive undertaking and hard work on both the CKEditor and Drupal side by dedicated teams, the result is a modern, versatile editing experience for a state-of-the-art digital experience platform, the best there is on the web.

The new CKEditor 5 core module comes with many improvements and countless new features. Including but not limited to:

• A new better UI,
• Media widgets with a toolbar,
• A reworked styles dropdown,
• Tables with a dropdown,
• Document lists,
• Links with attached panel

What’s even more amazing is the fact that we are also introducing an accompanying module for CKEditor 5 Premium Features! So that Drupal users will not only be able to use the core editor features but also have the ability to collaborate on their content right within their Drupal project!