Postpone EOL of D7 indefinitely (delay the beginning of ES extended support)

A discussion about more or less the same issue, in the forums is Drupal 8 is not something I want to use, and Drupal 7 is EOL November 2023 → .

Drupal 7 EoL Extended by 14 Months; Announcement at DrupalCon Pittsburgh

https://www.thedroptimes.com/31878/drupal-7-end-life-date-extended

This is great news.

Was there any discussion about renaming D7 to Drupal Classic and allowing the community to keep it alive indefinitely?

https://www.drupal.org/psa-2023-06-07 →

This will be the final extension.

@freelylw , yes that's a direct correlation that proves without a shadow of a doubt change of course is was/is/ and will be needed such as for example what I've been openly advocating for, also known as "Drupal Classic", Drupal without symfony.

Multiple organizations should be willing to fund Drupal Classic (or a new name). So that Drupal Classic should be able to survive and be maintained under the Drupal Classic name (of Dries approves) or under a new name.

Once things settle down, Drupal Classic (or a new name), will get new users and developers.

I think the issue here is the Drupal Association is assuming we're all on small to medium sites that can be upgraded / rebuilt in the new version with relative ease.

I have 10 servers, with 10 multisite installs, each with 500+ customers on - all utlizing a custom CRM and Business management system with D7 at its core. We're talking 100+ custom modules, over $250 million worth of financial records, customer data, reporting history etc that cannot be simply migrated/rebuilt without millions of dollars of work.

I feel completely shafted by this decision, and would financially support a "Drupal Classic", or "Drupal Lite".

Drupal 7 is still a fantastic platform to build apps on. I like to strip out all contrib modules using the minimal profile and build custom code on top. It dramatically speeds up development having all user auth etc ready to go, and make a pretty good boilerplate for many projects.

I agree 100%. There are many D7 projects that can't be upgraded. I see many in the government.

@xmacinfo: Agreed! Drupal 7 has still the biggest market share on all current Drupal sites. It should be supported indefinitely until less than 10 % of Drupal sites are still on Drupal 7 or lower.

Keeping the EOL as is will hurt the Drupal community and make many Drupal 7 sites will be side-graded to other CMS, or platforms, instead of being upgraded to Drupal 9/10.

110% agreed on the later part. This is already happening in my firm, there is 5 years of efforts in making a multi-millionaire project in Drupal 7 and there is already planning undergo as the Drupal 7 support is going to end so this is the best time and lets rebuild this project in ROR or some other framework.

@Ahmed.Raza, Drupal 6 sites are still getting security updates via the long term support program.

Drupal 7 still has a lot of mileage left in it. With that said, in my opinion Drupal classic (D7) still has a lot of strengths , I believe and this is my opinion that Acquia should let us choose which version of Drupal we want to use for our projects. To me there's two versions, symfony Drupal and Drupal classic.

If Acquia and or the D.A without Acquia changed approach to allow a Symfony and Classic future with an intelligent strategy going forward and asked the community for funding I believe many from the community would go forward and support the initiative.

With that said, I'm currently looking at Laravel Livewire version 3 out of curiosity, looking for ways to leverage the strengths of Laravel livewire 3 with Drupal either classic or symfony or both.

I'll consider participating in Laracon next year.

I can see only 3 options

1: Move to backdrop by the end of next year
2: Some organization may take over/continue the D7 development and change the name of Drupal to something else
3: Stay in D7 for some paid LTS for few years

a: am wondering what will be the problem if most of the D7 sites (380k) move to backdrop ? seems pretty straightforward for most of the sites? anyone has experienced ?

All, or nearly all the multilingual related bug fixes that I personally worked so hard to fix for Drupal 7 contrib and core have made their way into Drupal 10 contrib and core since some time during Drupal 9.

What amazes me is , is that Drupal 7 has never been better, it's improved leaps and bounds since even 2015. I didn't really consider Drupal 7 to behave as I expected it to until some time around 2017 and it's kept improving since then in a stable way.

Why would we want to cut it off when it's just become so good, so stable and reliable and powerful? Each PHP release that comes out it gets faster and takes less memory.

There's obvious advantages to staying with Drupal 7 or even starting new projects on Drupal 7 is something that is being done also.

Drupal 10 is getting to be interesting now also, a lot of work has gone into it as well. It takes a bit more skill and effort to maintain a Drupal 10 system however there's a roadmap for simplifying things. It's on the priority list.

With that said, I've given up the idea of forking, someone else can do it. Maybe I join in later but not now.

am wondering what will be the problem if most of the D7 sites (380k) move to backdrop ? seems pretty straightforward for most of the sites?

You need to rework the theme and there is no compatibility for DB engines other than MySQL (so this is not an option for PostgreSQL users). So there is some effort needed as well, it is not a drop-in replacement.

Drupal 6 sites are still getting security updates via the long term support program.

I don't think that's correct any more, unless I'm missing something: https://www.drupal.org/psa-2022-03-09 →

am wondering abandon the D7 is a decision by few people or by poll from thousands developers ?

am wondering abandon the D7 is a decision by few people or by poll from thousands developers ?

It is a standard policy to retire old versions of Drupal core when new versions are released. This has been the policy for almost two decades, it's not a new thing.

It takes an awful lot of funding to maintain an old infrastructure to run old software and maintain the thousands of sub-projects. I see a lot of people here saying the d.o should do a thing they want, that someone else should do the work they want. After several years of discussion I still don't see anyone standing up to volunteer to take on this responsibility themselves.

If people really want Drupal 7 to live on after the official EOL in January 2025 (after it has already been extended several times) there's a lot of work that you all will need to do before then. Nobody is saying you can't, the codebase is under the GPL so you're 100% empowered to do that. What Drupal association, core maintainers, security team and most contrib maintainers are saying is that collectively they/we are not interested in continuing on that responsibility.

Nate and Jen took the incredible steps a number of years ago to fork Drupal 7 to create Backdrop and have had some success with their endeavors. I encourage you to talk with them about how much work it has been for them to do, and then work on a business plan to build a similar support plan for Drupal 7 for past January 2025 (repeating what I suggested in #126 above).

Drupal 7 (Classic) and Drupal (8 to 10) Symfony now have both around 400,000 active installations.

Drupal Classic still sees a steady decline month over month, essentially by abandoning the platform or switching platforms. Most of the Drupal 7 sites that were planning to move to Drupal Symfony already made the move.

Dries, Acquia, the Drupal association do not want to invest in long-term Drupal Classic, even if Drupal Classic is a fully functional development platform that can still live on for multiple years and still get enhancements and compatibility fixes over and over to support newer PHP and MySQL versions.

Drupal Classic already has good maintainers to take care of it. But without a good infrastructure and funds to support Drupal Classic, the maintainers won’t be able, alone, to move Drupal Classic forward.

It is very sad to see a perfectly functional platform that does not need a ton of dependencies to be left to rot.

Anyone who wants to can for Drupal Classic, but can we reach a critical number of developers to form a viable community?

As for Backdrop CMS, a regular Drupal 7 site can be upgraded directly to Backdrop. But as Joseph mentions, there are many multilingual sites that cannot move over to Backdrop CMS. So Backdrop is not a solution for all Drupal 7 sites; it's only one option.

So, without a clear group of people who wants to fork Drupal Classic and maintain the required infrastructure, Drupal Classic will die.

A few people here are ready to fund Drupal Classic; there is still some hope.

> Most of the Drupal 7 sites that were planning to move to Drupal Symfony already made the move

Is there any research to validate this statement? (Genuine curiosity)

Backdrop is not a drop in compatible solution although I am impressed with their efforts. With that said, I highly value the collaboration we get on Drupal.org and would prefer to live or die by what the benevolent dictator for life goes with. I've got hope that the benevolent dictator for life is aware of the issues and challenges and limitations of a Symfony future in comparison with what we've seen now with Drupal classic in it's very successful run that keeps going and going.

🌱 [policy] Decide how long major Drupal versions should be supported Needs review

I have elaborated some of these points in the linked message from comment #107.

.... please reconsider the hard EOL of January 2025 for Drupal classic.

Drupal classic not being reliant on symfony or tied to Zend PHP EOL dates offers smooth future roadmap because it does not require symfony. This allows clients to build very long term stacks and leverage PHP security releases from vendors such as Red Hat (and others) to provide security backports for current and older versions of PHP and those running Drupal classic are able to do so with minor release PHP security backport updates long into the future.

Hosting options for Drupal classic are vastly larger and less expensive than hosting options on cutting edge PHP.

A stable api not tied to symfony has enabled many large organisations using Drupal classic without symfony to be able to build and deliver deep and rich experiences without spending time worrying about PHP EOL or Synfony EOL.

I urge the D.A to reconsider the roadmap for Drupal and to open it up to Drupal classic along side Symfony based Drupal.

I've seen what an extremely stable API has done for École Polytechnique de Montréal, they have built 180 sites , all integrated with various internal and external systems, single sign-on, event calendar, advanced functionality specific to their needs. Migrating to symfony Drupal would increase their maintenance costs immensely, redirect their focus to symfony instead of end users and custom deliverables. There are compelling reasons why the D.A should solicit financial support from the community for a continued Drupal classic initiative to keep the excellence going forward.

I understand that there are also compelling reasons to move forward with Symfony Drupal and I appreciate all the hard work being done. I enjoy working with Drupal 10 also however it's very challenging to keep up with it. I would really like to see us co-exist and agree to move forward indefinitely rather than force obsolescence on a large portion of our base.

I have a Drupal 10 site with approximately 40 modules that I installed through the UI from admin/modules/install (excluding commerce). None of these modules require dependencies. so I fail to see the reason for Drupal to opt for the dependency approach, If the foundational theory is flawed, This reflects the current situation for Drupal 8/9/10..., I think those 380k D7 users understand such things and stay in D7 is the right way

I'm not in any way associated with this company, but I found this:

https://www.herodevs.com/support/nes-drupal

Claims to support Drupal 7 with "never-ending support". Prices not listed at the time of this post.

I run a software company, and use D7 extensively. I've been programming modules for D7 since it went live, and I basically program some kind of helper module for every site I create. Some sites are simple; some are VERY complex (ex: CRM's, medical EHR's, etc) with 10's of thousands of lines of code that will only work in D7. I have indeed tried module development in D9 and it was a nightmare compared to D7. So many little yaml files, so much rearranged and convoluted. Entire classes for every form?! Is it possible? Sure. But who has the time or money to spend recreating a site/product that already exists and works? Why take the risk of introducing years of bugs to your customer base which would never notice the difference otherwise?

I, for one, will probably never migrate to D9/10/11/whatever. Navigating symphony and composer is a huge pain compared to just unzipping files or editing simple .info files, implementing logical hook_ functions, etc. D7 was the peak for Drupal, and I'm afraid it's downhill from there.

My plan (if they actually do EOL it Jan 2025), is to first try to migrate all my custom code to Backdrop. If that fails, I'll pay for the service linked above or some other extended support. I'm hoping that as the real EOL gets closer and closer, enough people come together to keep the D7 (aka Drupal Classic) community alive.

@Richardp I've been using Backdrop for a few years now... and it's fantastic for us D7 lovers... Join the Zulip chat channel... the support is amazing.

@richardp I guess eventually there will be a way between D7 and backdrop coz there are still around 400k websites, one of the problem for D7 is no one continue and maintain the modules anymore even there is core bug fixed....

@DamienMcKenna brings up a good point about the cost and scale of the operation. For now we've got until January 2025. That's enough time to prepare.

I myself was considering forking the entire d.o, I already went so far as to clone every single git repository, but I crashed my server doing it as I imprudently used relative folders in my script and the script went crazy. I'll perhaps re-script it and fix the glitch. It would be a huge endeavor should I or someone else go forward with it, it could be profitable as one company is already offering never-ending-support as mentioned.

https://www.herodevs.com/support/nes-drupal

Personally, I think a 100% compatible fork would be more successful than "yet another" cms. In this case the Drupal Association has basically given the community this ultimatum.

With that said, I'm pleased with the progression of Drupal 10. They're improving certain pain points and trying to stretch the major release lifespan which IMHO is still vastly too short. Every major release is still requiring massive amounts of contrib work.

@freelylw What I see in the usage graph is that Drupal 10/11 has a better chance of disappearing than Drupal 7.

https://www.drupal.org/project/usage/drupal →

We have an EOL on Drupal 9.x while it is still the main driver before version 10.x. Although it is considerably easier to migrate from 9 to 10, it looks like a vast majority of sites may not have the ability to upgrade for one reason or another.

Instead of pushing too early for EOL, there should be some considerations taken to understand the roadblock that users are facing, preventing them from upgrading.

For Drupal 7 sites, if they are not upgraded to Drupal Symfony by 2025, those sites will probably continue to live as is for a few years more, until their owners either migrate to Drupal Symfony or migrate away on another platform.

For Drupal 9, the community should push back the EOL for at least one year and do a survey to understand the behaviours of the users of Drupal 9 to see if anything can be done to help them go to Drupal 10.

I have seen many instances of Drupal 7 or 9 sites that were funded for development, and maintenance. But the same sites are left without any funds to upgrade to the next major versions.

With all this said, the main solution is to push back EOL for both D7 and D9 sites.

@xmacinfo "Drupal 10/11 has a better chance of disappearing than Drupal 7.“ from that usage page, the d9+D10 has more than 300k usage already, its getting closer to the D7, which makes the drupal team won't go back to D7 anymore, so the question is where D7 should go, EOL is just something temporary, becasue no one fix those modules anymore, I use commerce a lot, the 7x and 8x version both has similar about 20k usage, I guess the flight will continue far longer than 2025, by the end, we need a solution for where D7 to go, I personally think it should be more than "eol" solution.

Since it came up,
I've performed 6 upgrades from D9 to D10, have gotten it down to a science.

While this is specific to a distribution , most of it applies to any Drupal 9 to 10 upgrade.
#3378351: [D10] - WxT 4.5.4 to 5.0.0 - Upgrade steps and helpful instructions →

In most cases if someone is familiar with composer, the upgrade can be performed quite often in less than 5 days.

It does require a significant amount of skill to do but I have been able to do upgrades as quickly as two days. The most complicated upgrade I did for a provincial govt took about 4 months in 2 release phases.

Most of the work was dealing with contrib.

For Drupal 9, the community should push back the EOL for at least one year and do a survey to understand the behaviours of the users of Drupal 9 to see if anything can be done to help them go to Drupal 10.

Drupal 9 is not being marked EOL just because the core maintainers are borked and like shiny new things, it's because many of the dependencies are hitting their own EOL - Symfony 4 (which D9 uses) andd CKEditor 4 both hit EOL this year:

• https://symfony.com/releases/4.4 - hit EOL in November 2023
• https://support.ckeditor.com/hc/en-us/articles/115005281629-How-long-wil... - hit EOL in June 2023, and they specifically gave a six month extension for the Drupal community.

The Drupal core team have learned to not put themselves in the position of not adopting responsibility for a huge volume of third party code just because some people can't upgrade their core releases yet. Drupal 10 has been out almost a year, this plan was announced well before that, there's no excuse to not be at least getting ready for the upgrade now.

It would be nice if both Zend and Symfony would play ball with us. Set a fundraising target to reach so that their regular support cycle could be extended by 2 full years up from 3 to 5 and from there allow our lifecycles for core and contrib major releases to last at least 4 years.

These very short 3 year cycles they have are really a big pill to swallow and force us to work at breakneck speed just to keep up to the churn up top. Forces major releases to only be supported for barely 2 years and we get this song and dance in a short cycle.

With Drupal classic, there's no one forcing anyone to use bleeding edge PHP, although you can if you want. Symfony isn't forcing their lifecycle down either because it's not included.

Like Damien says:

Drupal 10 has been out almost a year, this plan was announced well before that, there's no excuse to not be at least getting ready for the upgrade now.

Multiple D9 sites will not move to D10, at least in the short term. But for unknown reasons, multiple installations are stuck in D9 (I include myself, but I will eventually move all my sites to D10 when I have time, hoping the EOL for D9 will not bite me). I can only speculate on why the majority of D9 sites have not migrated yet to D10. If it is only a question of time, those sites will migrate to D10. If it is because of funds or team changes, there might be an additional delay before they finally move to D10.

Dependencies are hitting their own EOL

Yes, Drupal Symfony forces us to keep pace with Drupal latest versions and we should upgrade as soon as possible. That's the type of life that was chosen for Drupal Symfony since the beginning. It's just that for some teams, the cost of the regular upgrades to major versions is not always planned.

Drupal 7 does not suffer from that problem, having no dependencies. I am glad to see that after so many years it is still running finely and with great performance. But I am also sad to see it abandoned, even if I never use it to create new Drupal sites.

having no dependencies

Drupal 7 includes an EOL version of jquery, but that is more manageable to patch/backport than symfony or ckeditor would have been.

With Drupal classic, there's no one forcing anyone to use bleeding edge PHP, although you can if you want. Symfony isn't forcing their lifecycle down either because it's not included with Drupal classic.

This right here sums up everything wrong with Symphony Drupal, and every reason why Drupal Classic is amazing as a bit of open source software that can stand on its own.

I suppose most of D7 sites are using ckeditor, which is another library going to be EOL. So yes, there are similar issues with dependencies in D7 as well, but probably not as much. What makes this harder is fact that many site owners don't realise it, in comparision with D10, where the EOL is forced.

Yes, but things like jQuery and Ckeditor can be solved with relatively trivial updates to core or contrib - theres no need to force people to rebuild their entire sites just to upgrade them.

I for one am devastated by the loss of Drupal Classic and what it has already done to Drupal as a whole. I think its a huge mistake on the Drupals part, and will see the platform used less and less until it only gets used by die hard fans or hobbyists, and we lose our community entirely.

I am already seeing the majority of developers I know leave Drupal in favour of other platforms that don't force their hand and require them to make major updates to platforms just to maintain current functionality.

Do you know any other platform that handles internationalization and localization on par with Drupal? I may try those out.

I've heard very good things about Django , with that said, I've never spent much time with Python. Someone very respected that I know in Montréal loves Django and python, I saw his work in Drupal which was amazing.
UCLA I believe switched from D7 to Django quite a few years back.

@poker10 classic doesn't ship with ckeditor. I haven't seen a professional ck5 solution ready for Drupal classic but there was some preliminary work done here:
✨ Support CKEditor 5 Needs review

With that said, there's likely not that much concern with a supposed "security issue" with ck4 given how tightly ck4 can be locked down using the Advanced Content Filter (ACF) and how limited it can be set up based on role. Especially since it's in an iframe and doesn't even have access to the rest of the DOM.

With that said, I suggest ignoring the classic EOL and optimistically it'll continue in some new form somewhere(?), your contributions are greatly appreciated.

With that said, there's likely not that much concern with a supposed "security issue" with ck4

I stopped looking back after collecting this group so there might be more. Here's the past ~3 years of releases required by ckeditor4.

https://www.drupal.org/sa-core-2020-010 →
https://www.drupal.org/sa-core-2021-003 →
https://www.drupal.org/sa-core-2021-005 →
https://www.drupal.org/sa-core-2021-011 →
https://www.drupal.org/sa-core-2022-005 →

Some paths to exploitation require the attacker have access to ckeditor4 to exploit the vulnerability. Some paths to exploitation exist where the attacker can't use ckeditor4, but the victim (an admin) does have access which is likely a common setup.

I created 🌱 Proposing a Drupal 7 security team on Github Active to discuss how we can keep unsupported Drupal 7 contrib modules going.

Since it seems likely that Drupal Classic isn't going to be an "official" project from DA, and since Backdrop is the most developed alternative we're going to have in 2025, I wonder if the maintainers of Backdrop could be "convinced" (ie, paid) to work on some kind of semi-drop-in API compatibility module such that D7 contrib modules are easier to port over. I tried and failed to do something like this when D8 first came out.

Caveat: I have not used Backdrop yet, so I don't know what changes to the API/codebase they've made. My example below is only an example! I don't know what all in backdrop is incompatible with current D7.

Here's how it could work:

Let's say that Backdrop changed the way node_load() worked. Maybe they added new arguments or some such. My proposal is there's a Backdrop module called "d7b", and all you need to do is add "d7b_" to the incompatible function names for it to work.

So, to port over contrib modules that call node_load(), you'd simply find & replace it with d7b_node_load(). Similarly you could do that with any core API functions that are no longer compatible. Theoretically, the Backdrop "d7b" module would eventually contains hundreds of these helper functions that replicate how the original API worked for D7.

This would make it much easier to take existing modules for D7, run them through a quick script to convert the needed function names to the d7b_ equivalents, and presto, the contrib module now works in Backdrop.

I know this isn't going to work for everything, and I may be greatly over-simplifying things. Just wanted to toss in my 2 cents. Speaking of, I would gladly pay a "bounty" for any Backdrop development on such an effort. My business relies heavily on D7, and I will be forced to switch to Backdrop when D7 reaches EOL. I'd love for Backdrop to be a relatively smooth transition.

Some progress being made with ckeditor5

✨ Support CKEditor 5 Needs review

@richardp,
#3409190: Discussion on the merits of Backdrop →

I am sad to report that due to the uncertanties around Drupal 7 (Classic) - I have now commissioned a full rebuild of our saas platform in React and other technologies to move away from Drupal. This is taking 12 months and $250,000 to do.

Looking at how this was handled, I cannot afford to take the same risks by rebuilding in a later version of Drupal and having a similar problem down the road.

This means I am retracting my offer of $10,000 a year to support this initiative, and I will be taking my 2500+ Drupal 7 sites away by the end of the year (in time for the EOL).

Thank you to everyone who tried supporting this, I am sad to let Drupal go, but also 4 months into the new build, already seeing a plethora of benefits to moving to a new system and architecture. I didn't want to have to spend this money just to end up with essentially the same service just on a new platform, but I wasn't left with many choices.

@Collins405 It's sad to see you go away. But you are not the only one moving their large asset of Drupal 7 sites to another platform.

However, I really like starting new projects on Drupal 10.x.