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

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.

The overall Drupal installation dropped from 1,200,000 sites running Drupal in 2018 to 950 000 in October 2021.

Overall Usage Statistics for Drupal:
https://www.drupal.org/project/usage/drupal

I am moving this to the correct queue for product ideas.

Trust me, I get the point. Upgrading to Drupal 8 cost us a lot of money. But there are certain realities to consider, and this issue is not a plan for OSS maintenance. This issue lists some justifications but it requires quite a bit more than asking nicely for the BDFL's approval. Have you considered the following?

• Who will maintain the software indefinitely? There is a small team of committers today. I have no idea if they would like to do so forever. Do you?
• Who will promptly evaluate security patches for backport?
• What funds exist to host the product itself and its documentation?
• What funds exist to host Drupal 7's testing infrastructure indefinitely?
• How will Drupal 7 be made compatible with PHP 5 through 8, and beyond? How will Drupal 7 continue working with future database engines along those it originally supported?
• Drupal 7 was forked. I am ignorant about the suitability of Backdrop as the destination for Drupal 7 sites in general, but I am curious if anyone had success with it.

Until those, and probably a few more, questions are answered in a detailed plan, I think this should be postponed.

Again, that is more justifications, but not a plan.

Drupal 7 was forked. I am ignorant about the suitability of Backdrop as the destination for Drupal 7 sites in general, but I am curious if anyone had success with it.

Most Drupal 7 sites still expect to migrate to Drupal 9/10 eventually. Moving to Backdrop would give them only a short term solution, as they still would face the big job of migrating at a later date to their target of Drupal 9/10.

Yes, most Drupal 7 (those that that are not moving/side-upgrading to Wordpress or other CMS, or moving to BackdropCMS) are expecting to move to Drupal 9/10 at their own pace. The pressure of EOL will not make them move faster, as many of them may not have the budget approved or that are still working internally on the update to D9 or planning the migration, etc. There are no answer that apply to them all.

The overall number of Drupal 7 sites is getting lower and lower and it will take a few more years before we see a significant drop.

That being said, based on current statistics, sites actively maintained and upgraded amount to:
Drupal 7: 151,017 sites are using the latest version of Drupal 7 (7.82); those are the real candidates for a postponed EOL.
Drupal 9: 97,546 are on Drupal 9.2 and about 23000 on Drupal 9.3; that number is still very low.

Who is going to do these things?

We already have the maintainers and I believe most of them a willing to maintain Drupal 7 indefinitely or willing to name other maintainers.

The idea is to move Drupal 7 to a maintenance stream, which may not need the same amount of maintainers.

Reposition / Remarket Drupal 7 as Drupal classic much like coke did with the new coke and cocacola classic

I'm one of the founders of Backdrop. Shortly after the announcement, @jenlampton and I had a conversation with @Dries about this exact idea, where we would maintain it as 'Drupal Classic" rather than being a separate, new project. That was over 8 years ago . At the time, the outcome of that meeting was "Drupal is Drupal 8" (or 9/10, etc now). Splitting the marketing between D8 and Drupal Classic would have undercut confidence in D8 and likely decreased the adoption rate.

There's many reasons why Drupal 7 had an easy adoption rate, highly compatible with hosting providers constraints , less dependent on external libraries.

...

• Update policies to unleash/unrestrain development of Drupal classic.
• Develop a product roadmap , determine Drupal classics strengths and build on them.

A lot of these things are essentially describing Backdrop. Backdrop is an alternate history where Drupal didn't adopt Symfony: https://backdropcms.org/user-guide/project-history. It still works on PHP 5.3(!), is faster then Drupal 7, and bundles all its dependencies (which are much fewer).

However the big caveat to all of this is that Backdrop is not 100% Drupal 7 compatible. At the time we forked, there had already been 4+ years of Drupal 8 development, which included multilingual changes and the start of configuration management. We forked right at the point Symfony was included.

Even so, going from D7 to Backdrop is still by comparison remarkably easier than moving to D8+. Backdrop is a permanent, alternative project, not a stepping-stone to D8/9. We're both coming from the same place but diverging into different use-cases, where Backdrop is targeting smaller sites and Drupal is targeting larger ones.

If your objective is to have "Drupal Classic" that will be maintained and have new features, then my opinion is that you're looking for Backdrop. If you want to simply continue supporting existing Drupal 7 sites for a longer period of time, then that would be a good reason to postpone Drupal 7 EOL (or just stick with the current plan for Extended Support).

If your objective is to have "Drupal Classic" that will be maintained and have new features, then my opinion is that you're looking for Backdrop. If you want to simply continue supporting existing Drupal 7 sites for a longer period of time, then that would be a good reason to postpone Drupal 7 EOL (or just stick with the current plan for Extended Support).

The idea is to give Drupal 7 sites more time to switch to Drupal 9/10. Essentially putting Drupal 7 on a maintenance mode for the foreseeable future while keeping automated tests running (and supporting infrastructure).

Many people jumped into Drupal 7 not knowing the full roadmap and then got surprised.

This is categorically untrue - the upgrade path from Drupal 5 to 6 and 6 to 7 was very similar to the upgrade to 8 - practically no code could be used as-is, most sites were rebuilt due to the architectural changes of contrib world. The specific processes have changed, but in practical terms it's about the same amount of work.

The idea is to give Drupal 7 sites more time to switch to Drupal 9/10.

Drupal 7 was released in January 2011. That was over ten years ago. Drupal 8 was released in November 2016. That was roughly five years ago. Drupal 9 was released in June 2020. That was over a year ago.

By the time Drupal 7 hits EOL in November 2022 it'll have been six years since 8.0.0 was released - how much longer do sites need to upgrade?

We already have the maintainers and I believe most of them a willing to maintain Drupal 7 indefinitely or willing to name other maintainers.

You might find a small handful of people in this boat, but the majority of maintainers are not willing to maintain D7 modules indefinitely. Module maintainers are already marking their D7 versions unsupported, and how many of the top 100 D7 projects haven't had updates in years? As an example, I don't see anyone stepping up to maintain the Omega theme, despite their not being any updates to the 7.x-4.x branch in six years and 40,000+ sites using it.

This is categorically untrue - the upgrade path from Drupal 5 to 6 and 6 to 7 was very similar to the upgrade to 8 - practically no code could be used as-is, most sites were rebuilt due to the architectural changes of contrib world. The specific processes have changed, but in practical terms it's about the same amount of work.

This is so false. Upgrading from Drupal 5 to 6 and Drupal 6 to 7 was in an order of magnitude considerably easier that upgrading from Drupal 7 to Drupal 8.

I can tell because I upgraded multiples Drupal sites to Drupal 7. Upgrading to Drupal 8 represents much more works.

By telling managers and users that upgrading to Drupal 8 represents the same amount of work hurts the industry. Please stop spreading false information.

Example, a very large organization updated their Drupal 6 to 7, in three months, updating all their custom codes and their theme templates. Doing the exact same task to Drupal 8 took them 18 months.

I don't see anyone stepping up to maintain the Omega theme.

Why would anyone maintain the Omega theme whereas the request is only for Drupal 7 to be maintained indefinitely?

The goal here is to postpone EOL of Drupal 7 (including testing bots and modules/themes access from their repositories). If a maintainer does not want to continue fixing security issues, he can move his project to unsupported. No one will force them to support their D7 projects if they do not want to.

The main concern is Drupal 7 EOL.

Upgrading from Drupal 5 to 6 and Drupal 6 to 7 was in an order of magnitude considerably easier that upgrading from Drupal 7 to Drupal 8.

How much is being rearchitected in these upgrades?

Example, a very large organization updated their Drupal 6 to 7, in three months, updating all their custom codes and their theme templates. Doing the exact same task to Drupal 8 took them 18 months.

In the D6 -> D7 upgrade did they need to change their site architecture? How about their D8 site? Did they change their output architecture, e.g. switching to a component-driven system? Did they leverage Migrate Upgrade (or core's Migrate Drupal UI) or build the migration from scratch? The projects I've seen take a long time went through major changes that weren't strictly necessary, e.g. the migration was built from scratch rather than leveraging existing tools, the output was built using a component architecture and they ditched a lot of output modules necessitating reworking everything.

I don't see anyone stepping up to maintain the Omega theme.

Why would anyone maintain the Omega theme whereas the request is only for Drupal 7 to be maintained indefinitely?

The support life of D7 contrib was brought up.

In the D6 -> D7 upgrade did they need to change their site architecture?

Same architecture, same theme.

How about their D8 site?

Same architecture, new theme. But creating a new theme was already planned and the theme alone did not take 18 months; the theming was only a couple of months. The rest did. Migrate UI does not migrate everything (in fact, only a small part was with the UI) so a lot of custom migration had to be written.

Joseph brings is a very good point. Multilingual sites were easy to upgrade from 6 to 7. But they are considerably harder to update to Drupal 8.

Serious question: Has there been polling or market research as to how naming Drupal 7 "Drupal Classic" would attract maintainers? It's been said here as if it is the truth.

The market research is here:
https://www.drupal.org/project/usage/drupal

I am supporting the idea of a "Drupal Classic" as my own personal opinion. There is still so much life in Drupal 7 and it's a fantastic and proven, stable platform.

Also, drupal.org is still running on Drupal 7, although there is work being done to upgrade it. Drupal.org would be a great sponsor and contributor to “Drupal Classic”.

Stability-wise Drupal 7 is not dependent on Symfony and does not require removing deprecated code each time Symfony changes. For Drupal 7, EOL is an artificial concept based only on train push that is Drupal/Symfony.

Drupal 7 can live an indefinite life without artificially cutting its lifeline.

And dreaming ahead, perhaps one fine day in the future, the upgrade path from Drupal Classic to Drupal 11 could become GUI-based like a D6 -> D7 upgrade (for less customized sites) and not require a comprehensive migration effort.

Being able to get content types and data transferred would be a huge win in itself, even if for example Views and other components need to be rebuild.

Support from the DA is basically required for this, because they maintain the infrastructure with their funds. Everything has a cost in this domain. But I don’t think a DA team member has commented. Have any of the interested parties on this issue reached out to anyone at the DA about what would essentially be their new business plan?

@cilefen I suspect that the DA already sees a decline in their funds as Drupal overall usage is in decline. And if they cut support for D7, which still accounts for 53% of Drupal websites, they may have even less funds in the long run.

I agree with @joseph.olstad about creating a separate fund for Drupal 7.

Finally, DA is not able to successfully fund Drupal.org to move to Drupal 8 or Drupal 9. Drupal.org is still using Drupal 7 (and now Gitlab, as some pages built in Drupal 7 are not gone; their link pointing to Gitlab).

So I fail to see Drupal 7 development being drop while drupal.org uses it. Does the DA plan for D7 to be changed to an internal development tool only for the usage of drupal.org?

If I can put my two cents. There is still more than 0,5 milion of sites using D7. Nine months before EOL. This is a huge number and this number is not exact - there are thousands of sites with update manager turned off in production.

I am pretty confident that a big number of these sites does not plan to migrate to D9/10/11... We have an experience with not a small percentage of our clients who do not have interest in investing lot of resources and funds to this upgrade process. As @xmacinfo pointed out, the migration between D6 and D7 was generally easy. Migration between D7 and D8/9/10 is generally very tough, time and money consuming (rewriting the whole codebase, themes, ...). If needed, these sites will most likely jump to another frameworks, which is not the best message for DA.

So I would be very happy if Drupal 7 would survive even further - maybe as a remarketed product like "Drupal Classic". That would be great, because it is stable and robust platform.

On the other side, I understand some concerns raised here about the current D7 core/contrib maintainers. But if the product will be remarketed I think that there would be maintainers willing to support these modules. Now they are seeing EOL period and does not have motivation to continue with the work.

Extended for one year: https://www.drupal.org/psa-2022-02-23

Nice, thanks! These are good news for the community. Hopefully there will be enough time now to consider what to do next with D7 (instead of just extending the support +1, +1, ...).

Btw I have run into a similar duplicate issue here: #3132897: At D7 EOL, Rename Drupal 7 to Drupal Classic

psa-2022-02-23 is sensible to all and welcome.

Leaving the status of this issue as is, as we can still discuss the long term plan, even if the security teams will reevaluate Drupal 7 EOL extension yearly.

Product management decisions are made in the ideas queue.

I would also pledge financially for ongoing D7 security management.

I'd happily pledge at least $10,000 a year if I knew it was being converted to Drupal classic and maintained long term.

I'm sure there are plenty of other organisations like mine that use D7 as the backbone of our architecture and an upgrade to D9 is out of the question.

It is great news to hear that a decision has been made to delay Drupal 7's EOL to November 2023 and re-evaluate annually, https://www.drupal.org/psa-2022-02-23

There are many arguments to support this decision and rejoice in the success of Drupal 7 that is still used by more than 550,000 sites including many extensive, ambitious sites.

I'm not sure about the merits of changing the version numbering system to minor and major versioning as this may again give rise to the constant buzz of EOL in the air, as we have seen with D8 and D9, which can be confusing and does not inspire confidence in clients building ambitious systems with Drupal. Those with sizeable investments of time and resources want a foundation they can rely on. Dropping support for php 5.3 or even 5.6 as time goes on may not be a big pain point.

FWIW, here's my train of thoughts (sorry for the lengthy post):

• The extension of the D7 EoL for another year is a good thing for site owners - it gives them a little bit more time to consider what to do.
• It is also a good thing for the Drupal community from a "customer retention" point of view - it may provide enough time to polish and automate the D7 -> D9 or D10 migration, and generally make it faster/easier, and in general less costly.
• With such a huge list of things to be done in the D9 and D10 space (initiatives or general tasks and feature requests on top of bugs), is there really time/energy/interest to do that though? The fact that we have left this discussion till "last minute" doesn't make things any better either. I feel that the people that could possibly work on this have already moved away, mainly due to the constant "D7 is dead" bombardment from all sides over the past years.
• Although extending security support for D7 core for +1 year (with the possibility to perpetuate that) is good, certain contrib maintainers seem to be marking the 7.x branches of their projects as unsupported. It will be very hard to convince them to reconsider I think. Not looking good, and I expect more and more contrib to drop 7.x support. I'm sure that we all agree that Drupal core alone does not build a site - there's 12s of contrib being used on even the most average of sites, so this is a serious issue. I'm sure that D7 site owners will simply have to "bite the bullet" and move from D7, whichever solution they decide to go with - Drupal/Backdrop or otherwise.
• The current D7 user base has not seen any value return from sticking with D7 all these years. No new features, unless these were coming from contrib or custom code. Without any improvements in the API, this makes it a harder job to do too.
• If I were a D7 site owner, I would appreciate the extension of life (gives me more time to budget etc.), but I'd still be looking for a way forward. If the D9/10 path was costly, I'd most likely move away from Drupal entirely. If the developer or the agency that's been looking after my site came to me with an alternative proposal to move to Backdrop, chances are that I would take their advise and do that. Here's why:
  • It'd be familiar. Content editors wouldn't have to relearn how to use the product - the same would be true for any in-house system administrators and IT departments in larger organizations.
  • It'd cost less. Sure, Backdrop is not an 100% drop-in replacement for D7, but it would be done faster than having to rebuild and migrate to D9/10.
  • I wouldn't have to move to more expensive hosting because of system requirements.
  • I wouldn't have to move to a system that has its lifecycle dictated by multiple external libraries. That'd be less ongoing upgrade cost (and before anyone rushes to throw "upgrades are easier now" at me, please have a look at the 115k sites still in D8.9 - https://www.drupal.org/project/usage/drupal).
  • Ongoing maintenance would also cost less - no complex workflows means less developer time/effort to get things done. At the same time, I would get config management, which streamlines the workflow for developers even further.
  • I would get return of investment (new features added every 4 months in minor releases - UX improvements added even more frequently with bug fix releases).
  • Ported contrib modules have a much better, crowd-sourced maintenance process (they do not become "the baby" of any single person or a couple of them), and they are backed by a Bug Squad (which may now be only 3-people strong, but looking to expand as the community grows). See https://backdropcms.org/leadership/bug-squad
• The best thing is that when it comes to it, moving from Backdrop to Drupal 9/10 will not be any harder than having to move from D7 to D9/10. That means that as a community, we'd be providing a perceivably smoother path for current D7 site owners to move from the "classic" (or whatever we end up calling it) version to the "professional" or "enterprise" version of the product - at their own pace.
• This would also be a good thing for the developers and smaller digital agencies in our community:
  • They need not lose their existing D7 customer base to other systems.
  • Their existing Drupal developers would reuse the expertise they've acquired over the years of working with D7 - it'd be a breeze for them to now be working with Backdrop instead.
  • They are given more time to convince the portion of their customer base for which the enterprise version of Drupal is a good fit, to eventually move to that.

I'm genuinely interested in helping move these discussions along. There's two opportunities I see:

• The 5th Backdrop LIVE event is scheduled for March 11-12 (see https://events.backdropcms.org). There are still slots available and we could even shuffle existing sessions to make room for a discussion on this matter during a more "favourable" time slot. I'm sure that the Backdrop community would be more than happy to have any of our Drupal brethren join us in live discussions on the subject. This is an unconference event - sessions are not recorded, so people can more freely "speak their minds".
• DrupalCon Portland is on April 25-28. Sessions must be locked by now, but there can be BoFs on this, with an eye towards having dedicated session(s) during DrupalCon Prague in September.

Please keep in mind that the BackdropCMS dropped PostgreSQL support, which is (according to my info) still widely used especially in corporate installations, where MySQL is a no-go. These sites are not going to migrate to another database engine (PostgreSQL => MySQL database conversions are really pain).

And also you need to look up on this from the Drupal Board point of view. How will they "benefit" from abandoning all sites on D7 and recommend them to migrate to the BackdropCMS? Drupal 7 is robust, fast and working platform and it is ideal for users which wants stability, no backwards incompatible changes/deprecations each release cycle, etc... However it is possible that you meant your post only as a recommendation for site owners/developers, so thats OK.

But I think the main goal here is to find a way how to keep the Drupal 7 live as long as possible to benefits from its market position / usage and current stability. Only if this goal fails (and it will be clear, that Drupal 7 IS going to die), then we can check what next...

I look after quite a few D7 sites. I have a couple of D8 sites... and while I did try to migrate/convert a site or two to D8 it was a nightmare... So I gave up on D8... I will at some point try D9/10.

I look after small to medium sites for customers who really don't care what CMS I use, it's a matter of getting the best solution for my development needs without having to reinvent the wheel or spend another couple of years getting proficient in another CMS.

I was reluctant to go the WordPress route but was quite prepared to do so (reluctance would be an understatement).

Then I came across Backdrop CMS and it is a perfect fit for my business model.

So with the postponement of D7 EOL, I will still be moving my sites to Backdrop. With the EOL being extended it will make my life easier and I won't have to panic as much because I still have nearly 30 sites using D7, the EOL extension just means less pressure.

Even if D7 was kept indefinitely, for me it wouldn't matter I will still be moving to Backdrop.

I run a huge SAAS company which uses Drupal 7 multisites as its base.

I want a platform that is secure, robust and doesn't have constant updates and new features to mess with. For me, that is Drupal 7.

I personally don't care about contrib modules as we run our own custom code on top of core - the only contrib modules we use are views, date, and a couple of other very robust widely used ones.

I like the idea that Drupal classic just becomes a simple base product without additional complexities - and I'm happy to pay to keep it that way.

Delaying the EOL for another year is a sensible decision for at least two reasons:

• For site owners and small agencies: they get a little more time
• For Drupal as a project: dropping support for a version that the majority uses would for sure be disastrous regarding reputation

However, IMO kicking that can down the road every year also isn't the best way to handle things.
Not only because of the uncertainties for community members, but because that might also hurt Drupal's reputation (long term).

And enhancing support for core doesn't mean that contrib maintainers will also do.
Too many already left, and those who are still here for sure mostly focus on D9+ (which is understandable).

One hard truth for enthusiastic Drupal 9+ promoters: the big run from D7 to 9 (or 10) will probably never come.
I'll not waste any time here to explain again, why. It has been explained so many times already (and often happily ignored).

Drupal 7 is still a cool product, but it stands still. It may be the best choice, if one plans to never substantially change the site(s) anymore.
For this use-case a "Drupal Classic" absolutely makes sense.

But is that the case for all these 552,430 sites still reporting to use D7? Honestly, I doubt it.

And what about new sites? There are still the same reasons to neither choose D7 (too old, site needs new features) nor D9+ (too high cost and effort).

So if a site owner (admin / agency / service provider) can neither use D7 nor D9+, what should they choose?
Guess what: Backdrop CMS!

You might have misunderstood Backdrop as a "drop in replacement for D7", but it goes beyond that.
It does provide new features, but in combination with backwards compatibility, and flexibility regarding (shared) hosting.

This is where I see the strengths of the projects:

• Drupal 7 - stability (close to near-death experience ;-) )
• Drupal 9+ - for projects with higher budgets and very special requirements
• Backdrop - for websites with smaller budgets, yet special requirements (things that WP could never fulfill)

@poker10 I hear you re db support - if that's what people need, then there's https://www.silkscreencms.org

Silkscreen CMS is a fork of the Backdrop CMS, adding the ability to use additional database, cache, and configuration management backends to the base Backdrop system.

...it's a drop-in replacement, and a "friendly" fork that follows our releases (think PressFlow).

The recommendations in my post were meant towards a) current D7 site owners and b) the Drupal community in order to help developers and small(er) agencies retain their customer base. They would move to a "friendly" product. Backdrop is being developed by people that belong to and still love the Drupal community. We still work with Drupal 8/9/10 - Backdrop is just a solution for those customers that do not want to be "rushed" into an enterprise/costly solution, yet want to have the power/flexibility that comes with a CMS that is data-structure-centric. Working with either Drupal or Backdrop should not need much time/effort for site owners, content authors, or developers. It would be similar products geared towards different audiences (with different budgets really). That gives Drupal/Backdrop freelancers and digital agencies the flexibility to suggest solutions to their customers that meet their budget, while for the developers that will work on these sites it should more or less be the same (just have to get used to the quirks/differences between the two systems, which are very small compared to having to invest time learning another system).

@Collins405 I hear you too. Staying indefinitely in D7 in your case seems a perfectly valid business decision (I wouldn't personally do that, but I see your point as I said). Not sure how many other D7 site owners have managed to "decouple" themselves from contrib though. It would be great to get an idea (have metrics) on that, so to be able to make informed decisions.

Disclaimer: I have absolutely 0% monetary interest in Backdrop - my day job and what puts food on the table is D9. I'm employed by one of the "big players", which work with enterprise customers and government that have HUGE budgets. All my comments here and my countless contributions to Backdrop are all because of love for the community ❤️

Thanks @klonos, but the Silkscreen is just another fork. The strenght of the product is defined by the community. As far as I can see the Silkscreen has none (there is only a mostly empty simple website). Drupal 7 has still 550.000+ websites running right now (with superb documentation, rich stack overflow archive, ...). These are big advantages and guarantees what others can hardly give you right now.

I understant that there have been a need of creating fork from D7 to start putting more new features, but I can think about sites which could prefer stability over many new features (see also Debian vs Ubuntu). Actually this is also our case (although I do not say that this cannot change in the future).

So it is good that there is also this alternative to consider for all D7 sites and that you have presented it here. But hopefully we do not get overcrowded with the posts about Backdrop right now, as this discussion from @joseph.olstad was intially about how to keep D7 alive (where no changes for sites/developers would be needed) :)

Some external (and usually quite accurate) data regarding where former Drupal projects are moving to by w3techs.com It's not astounding that it's Wordpress.

And one of those depressing stats in their historical trends: Drupal loses market share

I'm not sure if a "Drupal Classic" could really reverse that decline, but at least it's worth a try.

The benefit of a clearly defined state like "supported long term, at least until [higher number here] years": that would give more confidence than this half-hearted extension year by year, which rather concerns people.

I'm still convinced that most of these D7 sites will never get migrated to D9+, putting more pressure on site owners to enforce migration to D9 will not lead anywhere.

And again: D7 is no real option for new sites, D9+ is only for a small part of projects. However, keeping those D7 sites alive (and supported) might help to stop the current migration to (mostly) Wordpress. But IMO that needs a clear commitment that D7 will not just get dropped. A "Drupal Classic" product could be such a commitment.

I wonder, what that would mean to the commercial Drupal 7 Vendor Extended Support, though.

Again and although I'm aware that people here don't like to read that: Backdrop CMS is a valid alternative. People seem to leave Drupal, and nobody seems to be able to stop that. So it's just a matter of where they go. Honestly, wouldn't Backdrop be preferable?

Regarding collecting donations for the "infinite" support: I bet more people would want to contribute, but the first thing it needs is a clear commitment. I've read similar suggestions before, but nothing happened so far. Let's hope, this discussion isn't just another one ending up nowhere.

Hi everyone, thanks for your thoughts and comments.

As indicated in the Announcement extending the Drupal 7 end-of-life to November 2023, the plan is to re-evaluate Drupal 7's eventual end-of-life date annually. So, it's probably not beneficial to have an ongoing discussion here at this time -- a commitment has already been made to look into this again next year.

There aren't any plans for Drupal 7 to be supported permanently. Migrating to Drupal 9 is still the recommended course of action overall and is the best way to ensure a site will receive security fixes in the longer term. Drupal 7 will eventually reach end-of-life.

The decision to extend the end of life of Drupal 7 is also not made lightly, as providing security coverage for Drupal 7 core and contributed module versions requires significant work from the volunteer Drupal Security Team, from core release managers, and from contributed project maintainers. Dries, the Drupal Association, and the Security Working Group are doing their best to balance these issues with the needs of Drupal 7 site owners impacted by COVID-19 and by the comparatively late release of the Drupal 7 to 8/9/10 migration path.

For those offering to pledge money to Drupal 7's ongoing maintenance, consider making a financial contribution to the Drupal Security Team to help support Drupal 7's security coverage through the new end of life date. You will also have the opportunity to pay for Drupal 7 security coverage after Drupal 7's eventual end-of-life by contracting with a Drupal 7 Extended Support Vendor.

I'm marking this as "Fixed" because the date of ending support is an undefined amount of time in the future. Thanks, again for your thoughts, comments, and offers of support. In any future threads, I hope that as this topic becomes important, we can keep them focused on Drupal.

This comment was co-authored and reviewed by many members of the Drupal Security Team.

Thanks, everyone!

edited for readability

@greggles With respect, marking this as fixed, because Yet Another Decision (YAD's) will be made next year, is overlooking the points others are making related to the issue summary and title that specifically include "indefinitely" and while I appreciate that it is a rather expansive word this thread is a community discussion of some of the pain points with drupal policy. I would suggest the issue remain active with respect to anyone who chooses to add their thoughts. Is it too little, too late?

Unless of course you are saying a Symphony of John Lennon's "Give Peace a Chance" :-)

@greggles This is far from being fixed. At best, we can mark this issue as “postponed” until January 2023 where we need to know if we need to extend once more EOL, forked D7, or any other solution that will rise until then.

Drupal 7 core and contributed module versions requires significant work from the volunteer Drupal Security Team, from core release managers, and from contributed project maintainers

We all agree and many users are willing to fund Drupal 7 specifically. Instead of marking “fixed” this issue, the Drupal Association should start setting up Drupal 7 specific tools to start making Drupal 7 a full project in maintenance mode (no new features) without any EOL, or with a clear multi-year target.

Furthermore, moving to Drupal 9/10 for developers still on Drupal 7 also “requires significant work”.

Statu quo is not something that will help Drupal grow. We need long-term commitment, or a real “Drupal Classic” product (again D7 in maintenance mode with no new features).

Drupal 7 support MySQL 8 and PHP 8.1, so as is, it is perfectly viable for a very long time.

Drupal 7 support MySQL 8 and PHP 8.1, so as is, it is perfectly viable for a very long time.

Exactly. It seems crazy to want to shelve a project that still works perfectly, and is considered very stable.

Drupal classic could continue to be a stable platform for developers to build new products on that need something that isn't going to require constant feature updates, only bug fixes and security patches. That is hugely attractive to me.

What are the rules regarding a fork?

Does anything stop me taking the code base, calling it DrupalClassic.org, then charging a low monthly fee to people who want to use it as a completely seamless drop in replacement for their Drupal 7 website, with all proceeds being completely transparent and only used to fund a security team?

There's nothing stopping you cloning the codebase as it's GPL2. The name, on the other hand, is trademarked, so you couldn't just call something "Drupal Classic" without running into legal problems.

I want to address something in #63 quickly.

Furthermore, moving to Drupal 9/10 for developers still on Drupal 7 also “requires significant work”.

There's 2 kinds of work here that are pretty different and I think we need to keep them separate when talking about them.

The comment I posted said: " requires significant work from the volunteer". That is volunteer labor done for the benefit of all Drupal 7 sites. Many of the volunteers doing that work no longer do work on Drupal 7 sites. So their work is altruistic, it is for the benefit of others only and not for themselves.

Comment #63 talks about significant work of site-owners of a Drupal 7 site in maintaining the site and perhaps migrating to another platform. That is indeed significant work. However, it is not volunteer work done altruistically for the broader Drupal community.

Maybe you already knew that distinction. I can understand a perspective of global efficiency, thinking about total world effort expended. In this specific case, though, one of the constrained resources is the time of volunteers of the Drupal Security Team, from core release managers, and from contributed project maintainers.

You're offering to pay in a specific way for a specifically named product with specific commitments, but from what I understand the DA is not interested in that. Switching the issue status isn't going to change their minds or increase the volunteer effort available on those teams I mentioned above.

Whether this issue is marked as "fixed" or just "postponed" is a bit of a labeling argument and probably not a valuable thing to debate. I think it would it would be a bit cleaner in this queue to keep it fixed so have done so again. Some things may change by January of 2023. It seems best to open a new issue then that is aware of the context of the world then.

You're offering to pay in a specific way for a specifically named product with specific commitments, but from what I understand the DA is not interested in that.

Yes, but what is the official viewpoint of the DA? We only have the viewpoint of the Drupal Security Team.

I find it very strange to see an association begging for money and at the same time refusing funds.

Well, let’s keep this conversation closed, but as Drupal 7 still powers more than 50 % of all Drupal installations, and that Drupal.org runs on Drupal 7, we can be assured that this conversation is far from being over.

I find it very strange to see an association begging for money and at the same time refusing funds.

I don't represent the DA, but one guess at a reasonable explanation for the seemingly contradictory behavior: They are requesting money for sustainable operation of projects that match their mission based on the advice of their leadership and board. They are not accepting offers of donations that would require them to do things outside their mission and/or that are not sustainable.

@greggles I know that you do not represent DA. But the standard business process is to reevaluate a redefine project goals regularly, according to the real development of the situation. I am sorry to say that, but someone from DA board should finally look into the reality. Yes, it was correct to set these goals and direction in the past, but we are in the present right now. They must respond to the market. There is still more than 50% of the Drupal websites (including Drupal.org) running D7. I don't really think it needs further comments.

StackOverflow is doing annual surveys about technologies and unfortunately Drupal is among the last frameworks in the table: https://insights.stackoverflow.com/survey/2021. This will not strenghten the Drupal reputation for sure.

Actions needs to be done ASAP, because it is easily possible that from the remaining 550k+ sites on D7, only minimum (50-100k) will upgrade to D9/10 and others will stay on D7 until the last possible minute and then they will migrate to another framework. Which could be a huge loss. It completely makes sense to keep both Drupal Classic and D9/10 live to satisfy both market segments - hardore developers / large companies, but also common users who wanted simply to dowload, copy, install and run the website (which is not possible with D9 right now without the composer, etc.).

I'd like to cast a vote in favor of quicksketch's proposal, that Backdrop become the de facto LTS version of Drupal 7, in perpetuity. I recently joined the Backdrop community, but have been a Drupal community member for years. Both projects have their merits, and both have a future (but would be stronger together). I think that there are fundamental attributes of small non-profits and many higher ed institutions (with limited resources) that will make the D8/9 gulf just too wide to cross, and the Drupal community may lose them for good if we don't provide a cost effective alternative. (Sorry for commenting to a thread marked "closed", but I don't think this conversation should be over just yet)

@joseph.olstad my team converted 2 extremely complex D7 sites to Backdrop as it was a fit for our needs, and in the process converted 18 contrib modules ... can I convince you to convert the ones that matter to you? No project needs 2,000 modules ... the same 100 seem to be reused over and over, and you will find that most of those are already available in Backdrop.

Backdrop is basically Drupal 6 with updates. Backdrop was forked from Drupal 6, not 7.

@joseph.olstad with all respect, you couldn't be more incorrect!

Backdrop has been forked from Drupal 8!

I'd never try to convince someone to switch to Backdrop, who points so inflexibly at one or two modules and states that it won't work for them without even trying. :-D

I do respect your decision to stick with D7 (Drupal Classic), but I'm a bit skeptical if you can achieve what you're trying here.
If it's about decisions made years ago, then keep in mind that dropping D7 is one of those decisions.
I think, many people here are aware that insisting on that decision will severely hurt Drupal as a project. Or should I say: it already does.

But among the people who decide, I also don't see any ambition to correct the direction. That's why IMO this discussion here is yet another one leading nowhere.

@zchandler I really appreciate your initiative to revive this discussion, but especially when it comes to things like "together Drupal and Backdrop could be stronger", there are lots of reservations - on both sides. It's not that I disagree, but I'm highly skeptical that this would work. For several reasons.

@joseph.olstad again, with all respect... I understand what you want: Drupal 7 forever. But I don't think you'll achieve that by disparaging Backdrop.

If you don't want to use it - don't use it. :-)
But if you don't actually know it - and that's obviously the case - please avoid to post misleading half-truths. It won't help you here with your request. And I also doubt that you'll appeal fellow campaigners for Drupal Classic with an attitude like that.

@indigoxela thank you for that feedback, I don't assume that my perspective is true for someone else, which is why I wanted to post here, to learn what others in the community think. Thank you for those insights. My desire to be one larger community may be wishful thinking, but I want to test to see what the reaction is. (Seems legit to me anyhow! :)

@joseph.olstad I completely get where you are coming from wrt certain contrib modules being so important for a given type of Drupal build that they become just as important as the core CMS itself. Loud and clear I get that. Your dedication and years of contribution to open source are awesome, and something I respect deeply. Mine is only one perspective on this issue; however, I do think it might resonate with many other end users (if not developers) in higher ed and non-profits.

I see someone positing that Backdrop should be Drupal classic? Its not Drupal. Don't do that. Drupal 7 works, its there. Just keep it working.

I'm sure Backdrop is a fine project .. but that doesn't change this fact:
Migrating from Drupal 7 to Backdrop will still require organizations to put in effort/ development work, and if going to put in work/effort, may as well put that effort into an upgrade to D9/10 .. and you have the same problem of losing userbase because of needing the effort.

@markusa that makes sense in a theoretical way, but in practical terms these are not comparable level of effort. A typical D7->Backdrop migration is likely 80% less effort (and therefore $$) than a D7->D9 rebuild. That is the only reason I am making this case, if that were not true, 100% of my web properties would still be on the D9/10+ track.

@joseph.olstad that's a great site! Excellent UX. What are the D7 elements that you are most proud of? I am always impressed by the commitment social good displayed by the Drupal community at large, often evidenced by the types of projects/clients you accept. I think these are shared values with Backdrop community ...

I don't think we can just EOL Drupal 7, and have the only option to be a complete rebuild, or complete renaming of all functions to move to Backdrop.

LTS for Drupal 7 is likely to go on for 6 years, probably even 9 years (3 year renewal cycles), and I for one will be contributing towards LTS financially as my entire business is so heavily invested into Drupal 7, that even updating everything to Backdrop would be years of work.

I would love to see Drupal 7 Simply renamed to classic, but even that would require core, and all module info files to be updated to read from the numbering system.

@joseph.olstad, saying "backdropcms is not good enough" is a patently false generalization. I think for your type of build that relies on specific contrib modules like entity_translation what you say may be valid (idk), so I get where you are coming from. But there are many cases where Backdrop CMS is absolutely good enough. Better than good. I have 2 business critical sites that my group's existence is tied to, that have been running on Backdrop + Pantheon since January. I can personally attest that Backdrop is legit.

Please be more specific in your assertions. Thanks. ... Wait, are you quoting someone else? If so, sorry for falsely attributing the quote!

Gotta admit, I am a pretty big fan of Merlin too. I tried to convince our biz school to hire him back when he was still working for Sony, circa 2010. Ironically, they (myopically) shut it down because he wanted to WFH 2 days a week! #facepalm. Looking at the world now, it's hard to believe that was a sticking point when comparing to the possibility of hiring such a monumental talent. Not our best decision.

@joseph.olstad while we're quoting Merlin:

I don't want to be responsible for saying "backdropcms is not good enough" -- that's not accurate.

It's not a drop-in replacement. It made decisions.

I haven't done a proper analysis of whether or not I'd go backdropcms route if Drupal 7 becomes untenable.

And as to your curiousity about "the very rich tools that Earl Miles (Mostly private) has developed" -- I'm curious too!

Just for completeness:

- @backdropcms is not good enough

I remember that post by DeVelCuy, please note what @merlinofchaos answered:

I don't want to be responsible for saying "backdropcms is not good enough" -- that's not accurate.

It's not a drop-in replacement. It made decisions.

^^ That's IMO correct. :-) Maybe he doesn't like these decisions, I do. It's not a drop-in replacement, it's better. And the effort for migrations is a fraction of a complete rebuild with D9.

@joseph.olstad it might be time to reach out for a bigger audience. 37 are following this issue here, let's say 7 of them are pessimistic like me. So 30 might be willing to do more public outreach tasks. 30 maybe isn't much, but could be a good starting point.

There are so many people out there who would be happy with a "Drupal Classic". But they have no voice in the Drupal ecosystem - I'm calling it ecosystem, not "community" for a good reason. The community still sticks with D7, the "ecosystem" insists in dropping it.
For Drupal as a project it seems important to me to bring these two parties back in touch with each other. But someone has to organize that.

The truth too often ignored: Of the 448,028 D7 sites currently reported in the stats, only a minimal amount will ever be migrated to D9+.
That's a fact. Drupal will either re-integrate this neglected part of the community or it will become a niche product for high budget business stuff. That's a hard market and if the "community bonus" is gone, it won't get easier.

I never understood the renaming of the APIs that happened with Backdrop but we should look at Backdrop for ideas and inspiration with compatibility as priority number one.

@joseph.olstad, if you read through https://github.com/backdrop/backdrop-issues/issues/1 it may help you understand. Backdrop forked from Drupal when some of the work towards Drupal 8 had already taken place, but before "PSR-0 started converting in earnest". Backdrop wanted to keep CMI but not include Symfony or other large changes. And then later it took Panels and used that as the main Layout.

It meant that the vast majority of the API did not change, but that there were a handful of core structure that needed to be converted:

• variable table converted to CMI
• Layout instead of the old theme regions
• Entities become "classed" and some of Entity API put into core

I've ported many modules and I've found most of them are quite reasonable to port. With Backdrop hosted on github and set up to use Tugboat and Github for automated testing, it is quite a nice setup for developers.

I personally don't see Drupal Classic going anywhere (I could be wrong), but with each Drupal 7 upgrade project I work on I find that I make a choice between Backdrop and Drupal 9 (mostly). Each Backdrop upgrade has been much simpler. Not to say that the Drupal 9 migrations haven't been a good choice for their use case.

I agree, the uncertainties about the fate of Drupal 7 EOL is causing weird Google search results:

In the Drupal universe, I see three products:

- Drupal 9 (or Drupal Symfony) with around 250,000 installs (progressing up)
- Drupal 7 (or Drupal Classic) with still more than 450,000 installs (still a very large amount, but on a decline)
- BackdropCMS with 2,000 installs (https://backdropcms.org/project/usage/backdrop)

Based on those numbers, which product should be ended? Probably Backdrop, since it failed to recover the hundreds of thousands of Drupal 7 sites.

But the discussion here is not about the fate of Backdrop, but the EOL of Drupal 7.

The push to end Drupal 7 comes directly from the Drupal security team (and probably Dries himself) and we will probably need to split that team in two, or create an entirely new security team dedicated to Drupal 7.

It’s not the Security team that should drive EOL of Drupal, by the way, but the strict number of installations.

Drupal 7 is an asset. It works with PHP 8.1 and has quite a large number of installations. With Drupal 7, there is no need to rebuild the site each time a new version is released. It is stable and is even considered LTS based on its stability, although not officially labelled as is.

If in 4 to 5 years Drupal 7 installations go below 2,000 installs, maybe by then we should consider it for EOL. But that's not for now, not with half a million installs.

We need to stop planning EOL for Drupal 7 and look instead to the future. Whether with the current security team or with a new one.

Based on those numbers, which product should be ended? Probably Backdrop

While I really understand the ambition to keep Drupal 7 (Drupal XP) alive, I'd like to note that the Backdrop community is (slowly) growing, while the Drupal community as a whole declines for years now. Again some external stats:

• Drupal: https://w3techs.com/technologies/details/cm-drupal
• Backdrop: https://w3techs.com/technologies/details/cm-backdropcms

Dissing Backdrop won't extend the D7 roadmap in any way.

It’s not the Security team that should drive EOL of Drupal, by the way, but the strict number of installations.

I belief, that's actually the case, this year-by-year evaluation will probably go on until the D7 usage falls under a certain percentage. I've no insight in how that decision is made - only assuming.

Many people here expressed concerns re the damage this strategy does long term. And I think these concerns are absolutely valid.

You may wonder, why I'm so pessimistic when it comes to "Drupal Classic". I am because Acquia has no need for it anymore, and it seems to me that nobody else comes up with a feasible plan to run it as an independent project along with Drupal Symfony. (Or can recruit enough fellow campaigners.)

The other thing of concern is that Drupal.org is still humming along using Drupal 7. We have heard that internally they have a Drupal Symfony version in development but we do not know how soon (or how far) Drupal.org will switch to Drupal symfony.

To that effect, Drupal 7 should not EOL before Drupal.org switches to Symfony. If ever Drupal 7 reached EOL before Drupal.org switches to Symfony, Drupal 7 will, at that time, effectively turn into an internal development tool used only by Drupal.org.

Some people here might be interested in today's Backdrop LIVE discussion about "Should Backdrop CMS be Drupal Classic?", which was inspired by this thread here.
You could ask questions and/or provide feedback from a Drupal user perspective. The discussion won't be recorded, but attending is easy - and it's not too late to register.

From #101:

The push to end Drupal 7 comes directly from the Drupal security team

That statement is not super accurate. And some conclusions based on it are also inaccurate.

The security team responds to what's happening with the community. The decision to set and extend an EOL date is made by a few folks representing different communities including Dries, the DA, core maintainers, release managers, product managers, and everyone is doing their best to balance the needs of all the Drupal site owners out there as well.

@indigoxela I think that Drupal classic should be something what approx. 500k sites are still running now and without any extra effort they should be able to do that also in the next years. Not something that is not a drop-in replacement, because it changed themes/layout system, dropped support for DB abstraction layer and other important language related features Drupal 7 has built for years.

#52
"I want a platform that is secure, robust and doesn't have constant updates and new features to mess with. For me, that is Drupal 7."

Like Adobe has several different branch for photoshop. why Drupal can't . maybe just the cost problem ? most of the users like D7, no way to abandon a system like this from the business point of view.

@freelylw With respect Adobe Inc has a 206.23 billion USD market capitalization and Drupal is maintained by volunteers, donated time, and monetary donations to the Drupal Association. They are not the same.

@cilefen yes, that's why I mentioned, is only the cost problem for the case ? if yes, then the discussion should focus on how to solve the cost problem then save the Drupal7.

But I guess there are some other small issues like :
1: Should drupal7 merge with backdrop ?
2: Should continue add new features to D7 or just keep it what it is now ?
3: Should keep Drupal7 branch forever or just keep it temporarily and then force users to upgrade to D9/10 ?

Finally I don't see there is even one saying we should discard D7. I think the future of D7 is clear. either keep developing it or merge with backdrop. the drupal team should decide this quickly, or will lose the users and community forever.

Acquia doesn't own the trademark, Dries does; this is mentioned on the bottom of every page of the site.

1: Should drupal7 merge with backdrop?
2: Should continue add new features to D7 or just keep it what it is now?
3: Should keep Drupal7 branch forever or just keep it temporarily and then force users to upgrade to D9/10?

1. That’s not the goal of this issue. Any D7 site owner can already upgrade to BackdropCMS.
2. That’s not the goal of this issue. D7 is feature complete. We can maintain it to support new versions of PHP and SQLs, but I am against adding features to its core.
3. That's the goal. We should keep the D7 branch alive, although not forever. The goal is to let the users choose where they want to go from there:
- move away from D7 and go to any CMS, including D9/10 or BackdropCMS when they are ready to do so.
- stay on D7 until support goes away.
And to continue on 3, Dries and the security team (along with proper funds from D.A. and gracious developers as noted further above) should continue to support the D7 branch up until there are less than 25,000 active monthly installations, down from 467,389 on July 31, 2002.

Just for reference, Acquia has nothing to do with any of this. Acquia is a private Drupal company like any other and is not responsible for D7's maintenance (nor had anything to do with the community decision in 2012 to adopt Symfony; that was driven by community volunteers). This is about community governance and resourcing. Please leave Acquia out of it because that creates a lot of confusion.

@xmacinfo "3. That's the goal. We should keep the D7 branch alive, although not forever. The goal is to let the users choose where they want to go from there:"

I don't think this is the best option, its an option but not positive. users will know its temporary, developer won't continue develop modules for it. those 460k users are a piece of cake waiting there that everyone want to cut a piece for themself.

I guess one of the reason Drupal move to upper level to D8/9/.. because Drupal lose the competition to wordpress in the entry level market. but from what I can see, Drupal7 is much better than wordpress, so if we continue developing Drupal7 for the entry market, keep expanding the ecosystem for it, I believe drupal7 can go much much bigger, I guess this is the advantage of Drupal7. but not just a middle system between the drupal9 and backdrop. that's why I asked the question whether should merge with backdrop or keep develop the system for a bright future.

Joseph: Drupal 7 and Drupal 9+ are not competitors in the way you portray, one is the evolution of the other over time as core maintainers realized that to bring the codebase changes they wanted they should stop writing 100% of the software and leverage what was available elsewhere. This is a ten+ year old discussion that doesn't need to be dug up out of its grave.

Outside of the giants in the industry that have tens or hundreds of millions of dollars to fund their work, open source always as a problem both funding long term maintenance and getting people to do the work. Supporting a single version of a complex software project for 10+ years is rare, if not unheard of - how many people support Joomla v2.5 which was released a year after D7?

@joseph.olstad for the EOL problem, it's the problem the team want to abandon Drupal7, they probably don't see the value of it. from what I can see there is a clear problem when they move up to D8/9/ , they want every user to follow up to become those 10% at the top of the mountain, this is clearly not possible, but this is what they asking, that's why those D7 users won't follow, the team is feeling the pain now for the decision. so its not about how to call EOL, its about once they start to respect the value of D7, there will be a different vision for it.

"we're merely another player and are controlled by outsiders." I been thinking about the same before, Drupal is control by outsiders now, from the business point of view, who want your own business control by outsiders ? at least its not the perfect way to run the software.

"we're merely another player and are controlled by outsiders." I been thinking about the same before, Drupal is control by outsiders now, from the business point of view, who want your own business control by outsiders ? at least its not the perfect way to run the software.

But that's the point of open source - anyone can contribute to it. You're saying that you as a business owner want someone else to fund maintenance of an eleven year old OSS project in perpetuity without coming up with a solid financial plan of funding that immense volume of work, while at the same time saying you don't want someone else to be in charge of your software. These are diametrically opposite positions.

@DamienMcKenna

But that's the point of open source - anyone can contribute to it. You're saying that you as a business owner want someone else to fund maintenance of an eleven year old OSS project in perpetuity without coming up with a solid financial plan of funding that immense volume of work, while at the same time saying you don't want someone else to be in charge of your software. These are diametrically opposite positions.

There are always different angle to look at things. I will ask 2 questions for your point :

1: Are all open source projects need to be in such way that "controlled by outsiders" ?
2: Is the financial reason that makes Drupal want to stick with symfony ?

I don't know how much times will save the drupal development by stick with symfony, but I can see what the permanent trouble that symfony bringing into the operation. I am not saying that's bad, but clearly its not the perfect option. lets back to the topic how to keep the D7 running.

This conversation already happened, there's no point in repeating it - see Catch's comments about support times: https://groups.drupal.org/node/167299

That 11-year-old conversation relates only to Drupal 8/9/10 and release cycles.

The issue here is to remove for good the EOL for Drupal 7 or at least postponed it by 4 to 5 years.

When discussing Drupal 7, we need to take into account the actual facts (facts that were not existing in 2011).

• Drupal as a whole is losing market share at a quick rate
• The first few results on Google say that Drupal is discontinued or on the decline
• There are still more than 465,000 active Drupal 7 sites
• Although Drupal 9/10 is gaining share compared to Drupal 7, overall Drupal 9/10 is now a speck in the sky
• Drupal.org is still running on Drupal 7

Personally, I prefer building all new sites with Drupal 9/10. But the fact is that I still have to maintain Drupal 7 sites and those sites will probably stay on Drupal 7 even after the EOL, and, for many more years after that.

It’s time to reevaluate decisions that were made in 2011 and later about Drupal 7.

• We should have a clear plan to support both Drupal 7 (100% controlled by insiders) and Drupal Symfony.
• Readjust the marketing efforts to give back to Drupal the image it had in the past.
• Accept funds from people who specifically want to support the Drupal 7 infrastructure including hosting, testing, marketing, etc.

..at least postponed it by 4 to 5 years.

Who will be the winner for this ?
1: Users are not the winner, they know its temporary here, they will still looking to go away.
2: Backdrop won't be the winner as well, the community won't shift to backdrop
3: Drupal9 won't be the winner as well, they will still lose most of those 460k users in few years time

Respect the value of D7, find a way to continue developing it or merge with backdrop to make D7 a permanent project which I think its the positive option.

Anytime you want to draw up a solid business plan and have some major companies commit to funding it, I'm sure there will be ears willing to listen. Without that it's back to asking someone else to foot the bill and do the work.

whether we can solve the bill problem by merge with backdrop ? I tried the backdrop, its the same like D7 and has some D8 feature which is a step forward than D7. for D7 users can almost start to use it directly. my question is what will be the problems if merge with backdrop ? the only I can see is the Drupal brand will lose half of their users. but the users and community will be the winner to continue the project.

---or let's say merge backdrop into drupal7, probably this will be more acceptable for drupal community.

@freelylw Unfortunatelly, this is not correct:

I tried the backdrop, its the same like D7 and has some D8 feature which is a step forward than D7.

for D7 users can almost start to use it directly.

Backdrop renamed some internal APIs, changed theming and layout system, dropped PostgreSQL support and more. It is not a drop-in replacement for D7 and there is considerable work needed to move existing project from D7 there. It was already discussed in some posts above.

@poker10 I know they made some small change. but will merge "drupal + backdrop" be a bottom card if finally the drupal team still decide to abandon the D7? It's better to have a deadline for this, the user is losing quickly now, I can see this is disaster to abandon the most successful project. so I guess to set a deadline to see if the team can have response for this and after that you know what card can be play to save the D7.

I am not sure anyone care what we talking about here, this topic was closed few months ago, am sure the D7 won't be killed, if the team don't want to continue, then the backdrop will be the winner to take over everything. and those 460k users probably won't upgrade to D9/10 because the symfony and composer are totally unnecessary for mid level business. btw, can this topic re-open again ?

... It's just too bad that Backdrop did not see drop in replacement compatibility with Drupal 7 as a priority.

@joseph.olstad Again, Drupal is a registered trademark of Dries Buytaert. Renaming everything was necessary to not violate that. Backdrop is a fork of an early Drupal 8 - at that time many changes from D7 have already happened.

I get the sense that Backdrop executed an ambitious but misguided business plan on a shoestring budget.

It's a community fork. No big budget, no big companies on board. But why would that be a problem? It's an advantage that it's purely community driven. See its philosphy.

Drupal in contrast, moved to a "developers first" and "business first" philosophy. We all wanted Drupal to prosper and become one of the "big players" - well, in a way it is now. But for high cost. There's now a risk that it splits the user community, leaving big parts behind.

... try to get Dries onboard if possible and allow Drupal Classic to govern ...

I think, as long as the name has to be "Drupal Classic", you can't do anything without Dries - who owns the trademark.

RE: Dries, I have my doubts that he'd be interested in this concept of "Drupal Classic" but it was interesting to hear him describe/acknowledge Backdrop as being part of the Drupal family the other day:

- https://twitter.com/nonprofitbkdrop/status/1557746312103268352

It's getting clear now, there are only 2 options here:

1: If Dries approve the concept of "Drupal Classic" or "Drupal xxx", then someone will start to draw up the plan and the roadmap for D7.
2: If Dries insist to abandon the D7, then backdrop will take over.

I guess they are waiting for the D10 autoupdate to see if those 460k will follow, it may probably wait for another 1-2 years...then 460k will become 360k...

@joseph.olstad

maybe Dries would come around

without Dries, the title of "Drupal" can't be used. Dries either has to say yes or no, or the community will go for the third option to create a new product call " ABC " whatever name but not breaking compatibility with Drupal7. I guess the first job will be to get a clear answer from Dries for yes or no.

Yep, so we've looped back around to the original proposed steps.

I have already said I'll contribute to this idea financially, minimum $10,000 USD a year if D7 reaches EOL.

Without Dries giving us the go-ahead, our only option is to rename it, and do a complete find & replace on core, and all top contributed modules.

This would look like...

1. Come up with a new name
2. Create website and host the latest D7 core with all functions renamed
3. Add top 200 contrib modules with all functions renamed
4. Hire a security team to constantly keep the code base secure
5. Work on splitting the community and bringing all D7 uses over to the replacement

OR With Dries' approval....

1. Keep the website the same
2. Remove scary EOL articles and warnings
3. Benefit from a large community that isn't shrinking out of fear

1: Get response from Dries for yes or no first
2: "...leadership candidates, a committee of representatives to elect a direction/leader..."

the problem is I guess Dries won't give a clear answer for yes or no, that's why I mentioned in previous post its better to have a deadline for this ( maybe 1-2 months ), otherwise can wait forever.

Déjà vu: This here discussion has already happened before :-)
https://www.drupal.org/forum/general/news-and-announcements/2015-11-09/d...

Don't panic: The main rhetoric and arguments for dropping the EOL tag - it seems to me - are already eloquently and clearly captured by the original Backdrop CMS post:
https://backdropcms.org/news/dont-panic

Why fork Drupal: Ditto, shorter and more concise than the previous one:
https://backdropcms.org/why-fork-drupal

Disclaimer:
I haven't used Backdrop so far and have no bonds to the project or community; only trying to facilitate the discussion

My 2 cents:
Technicalities like s/drupal/el-classico/ are not the core of the discussion IMHO; Backdrop offers three options to the people that are affected by D7's EOL "threat":

1. A possible technical alternative (unless support for PostgreSQL or some other technical difference is a blocker)
2. A possible community alternative if the current Drupal community's decision making is not working for you
3. Most importantly, a solid example of how to fork out from the mother-project in a structured and planned way

@stefanos.petrakis

As mentioned in #122, do not bring in very 7 years old discussion when the situation was different.

7 years ago the facts were different.

• Drupal as a whole is losing market share at a quick rate (7 years ago, it was gaining market share).
• The first few results on Google say that Drupal is discontinued or on the decline (7 years ago Google did not show that nonsense).
• There are still more than 465,000 active Drupal 7 sites (7 years ago, we taught that D7 usage would be much smaller by now).
• Drupal.org is still running on Drupal 7 (7 years ago, we all taught that Drupal.org would have been switched to Drupal 8/9 by now).

Instead of bringing in old decisions, discussions and threads, look at the current facts.

Reasons to continue with Drupal classic and not migrate to Backdrop ... entity translation ... abstraction layer

@joseph.olstad repeating your complaints about Backdrop again and again won't help you in any way with your Drupal Classic campaign. If your only argument for Drupal Classic were that Backdrop is so bad - your initiative would be doomed, anyway. Start doing the right thing, stop agitating against solidary projects (and people).

Edit to clarify: We (Backdrop) are not the enemy. ;-)

First off, I understand that people which have lots invested in Drupal 7 are not at ease and I don't intend to increase their frustration or angst. My intention was to point out that from a historical POV there is a very good and sustainable example of how things could play out if EOL stays; it's not the end of all things, let's stay positive.

But I do like a good public discussion and I have to protest: "do not" does not work in such a discussion.

Facts have sources and references that everyone can access, otherwise it's fiction and lacks credibility.

1. Drupal as a whole is losing market share at a quick rate (7 years ago, it was gaining market share). What is the source of this information? And is market share always a good measure for the health of an open-source project?
2. The first few results on Google say that Drupal is discontinued or on the decline (7 years ago Google did not show that nonsense). But what is the search used? And are Google search results a reliable or even desirable metric?
3. There are still more than 465,000 active Drupal 7 sites (7 years ago, we taught that D7 usage would be much smaller by now). Who is "we" and what does that expectation have to do with anything? D6 had 115,531 installs (February 28, 2016) when it reached EOL, how is this discussion with the one back then not relevant?
4. Drupal.org is still running on Drupal 7 (7 years ago, we all taught that Drupal.org would have been switched to Drupal 8/9 by now).Again, how is it relevant what CMS Drupal.Org is running on? What if it changes to Drupal 8/9/10 tomorrow, will that affect this discussion here?

Moving to Backdrop CMS is neither the best nor the only solution, it is one feasible technical possibility.

Most importantly and Backdrop's most valued legacy is IMO not their technological choices as much as a very clear documentation on how they want(ed) to differ as far as governance, decision making, release cycles and target audience goes.
If Drupal 7 keeps its EOL label, even if it gets postponed a year or more, it may prove a useful guide.

Further facts regarding Entity Translation: it currently reports 31K installs, not a whooping number and it keeps dropping.

Who is "we" and what does that expectation have to do with anything? D6 had 115,531 installs (February 28, 2016) when it reached EOL, how is this discussion with the one back then not relevant?

Just a quick note - please keep in mind, that the situation with D6 was different. I have personally upgraded a large amount of semi-complex D6 sites to D7 and it cannot be compared with D7 -> D8/9 upgrade in any way (by the effort needed). So today the situation is completely different. On top of that, D7 still has more sites live than all D8+D9 together. Decisions were made in the concrete time in the past (based on facts) and I do not dispute them, but the situation has changed and the standard business process is to reevaluate project goals (in this case D7) when situation changes. There is nothing wrong about that.

That's a good point.
When I mention that number of installs it is to point out that there were a lot of people back then that had not upgraded on time, and having to face an EOL for functioning software they had invested on doesn't feel different. Even if it is easier to move from D6 to D7 for you in comparison to D7 to D8/9/10, it was not equally easy for others. And that's the relevant part. And they talked about that frustration in a very similar way.

As for the re-evaluation of project goals, full on agreed, this is a legit invitation. Maybe it's time the D.A. steps in to coordinate discussing this point, unless this is already happening on other channels.

Underneath the bottom line, it boils down to the money and the time to continue to support D7, right? Everything else is noise

The market has already decided what they want, 450K sites still choose Drupal 7.

If every D7 site chipped in $10, wouldn't be a problem, right?

If the DA could setup a way to specifically contribute money for the maintenance of D7, would that help get the ball rolling and the necessary actions started?

@stefanos.petrakis

The facts are easy to find here:

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

- From 2013 to 2015 Drupal 7 increased in usage by 200,000 installations each year, clearly gaining market share.
- From 2016 to 2019 overall Drupal installations reached a plateau
- From 2016 to 2019 overall Drupal 8 installations took over Drupal 7 in a normal replacement pattern (new sites were built on D7, and a number of D7 sites were moved to either Drupal 8 or moved away from Drupal.
- From 2020 to now, the total number of Drupal 8/9/10 sites did not increase at all. In fact, removing D7 from the chart, Drupal 8/9/10 reached a plateau

If Drupal did not lose market share, there would be about 3,000,000 installations nowadays, which is not the case.

As for Google, just use Google and look at the results.

Drupal 6 to Drupal 7 versus Drupal 7 to Drupal 8/9/10 cannot be compared. It is and it is still considerably easier to upgrade from Drupal 6 to 7 and migrate from Drupal 7 to 8/9/10.

To know which platform uses Drupal.org is relevant. It proves that it is a considerable task to update to Drupal 8/9/10.

So, market share means Drupal.Org's own reported statistics using the "Update status" module. Thanks for answering that question.

Assuming this is a reliable and complete metric and assuming that the community behind Drupal has an interest in increasing its "market" share, I may be able to see what you are arguing for.

Or not. I personally don't think that this metric should be the driver for decision making, it's a volunteer-powered, not-for-profit, open-source project at the end of the day, people don't gather up and plan world market domination.
Are people stressed they won't manage to finance a migration to another system if D7 reaches EOL? I am listening with compassion.
Are people worried about "market" share dropping? I don't know why this is part of this discussion at all.

And facts are our friends, let's stick to them. I had a quick look regarding this sentence:

From 2020 to now, the total number of Drupal 8/9/10 sites did not increase at all. In fact, removing D7 from the chart, Drupal 8/9/10 reached a plateau

D8/9/10 #installs
Aug 7 2022: 388'650
Aug 9, 2020: 348'845
Total increase is about 40K

Drupal 6 to Drupal 7 versus Drupal 7 to Drupal 8/9/10 cannot be compared. It is and it is still considerably easier to upgrade from Drupal 6 to 7 and migrate from Drupal 7 to 8/9/10.

No comment here, every project is a unique journey and comes with technical debt, budget limitations and so on. I am sure there is room for improvement regarding tooling, I am aware there has been considerable effort invested in improving those tools, we could be thankful and stay positive about the state of things.

To know which platform uses Drupal.org is relevant. It proves that it is a considerable task to update to Drupal 8/9/10.

Again, if D.O. switches to D9/10 today, would that prove it's an easy task? For every website ever built on D7? Every project is a different story, D.O. seems to be integrating a bunch of different services in one place for a lot of users.

And finally, again for facilitating the discussion, one could always consider running a petition, e.g. "Drop EOL for Drupal7 for 10 years" or something like that and see how much support one can gather.

This: Are people stressed they won't manage to finance a migration to another system if D7 reaches EOL? I am listening with compassion.

This is exactly the problem.

There is definitely a stress that organizations that need a massive D7 to D9 (or 10!) upgrade will evaluate other options and not choose Drupal. It is happening more often.

The question they have to justify is "Why should I pay a bunch more money to get a website that basically works and looks the same as what I have now. What I have right now is good, I like it, why do I need to spend lots of money or time? If I have to pay a bunch more money, I should look around and evaluate ALL options"

In many cases, significant sums were invested into D7, often over many years .. to have to invest another significant sum can be a difficult ask. This is especially true for non-profits, who have to fund from donors or grants, which go down in bad economic times, and may have taken a big hit with Covid wrecking event driven income models.

@joseph.olstad I agree! And those organisations (not only that higher education institution) will probably fork Drupal 7 just to make sure that they can continue working even if Drupal 7 reaches EOL in the future.

Overall, though, it will be better to have a Drupal “Classic” in good hands rather than have each of those organisations left alone with their fork.

If Drupal did not lose market share, there would be about 3,000,000 installations nowadays

I am sure the D7 can go even bigger than this if we start to keep this project permanent now and let the community to build up the ecosystem like wordpress is doing. but I don't see the passion from the community for D8/9 for this, time has been wasted... btw, anyone close to Dries can get a clear answer first ? we need to push for this. I can see he is in difficulty to make this decision, but the D7 users still occupying the most of the users, so the decision shouldn't be too difficult to make ( no one can afford to abandon most their users from the business point of view...)

"Whether Backdrop Is Welcome at DrupalCons?"
https://www.thedroptimes.com/9414/whether-backdrop-welcome-drupalcons

Dries is waiting for the D10 to "solve" the problems and to see if those D7 users will follow.. guess this will be another 2 years time, he is kind of stuck in the middle now, more than half of the users don't like the way of D8, but accept the idea of "Drupal Classic" probably will weaken the development of D9, if you are Dries, how will you solve this problem ?

Another Drupal7 fork https://yad7.org/

by looking at the future plan for D11, the selling points is module browser and autoupdate , means there will be no big plan to change or improve for the current pathway for the next 4-5 years. obviously those 400k d7 users won't follow, am wondering if the total usage drop to less than 400k after 4 years, will they start to consider the D7 again or just insist to abandon the d7 ... the backdrop probably will be the winner at the end.

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.

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.

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 ?

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 fork 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)

.

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....

@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 fight 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.

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.

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.

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 #3408125: Proposing a Drupal 7 Security team on Gitlab 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 end of incompatible function names for it to work. (Adding to the end of the function name so it doesn't hurt the hook_ system).

So, to port over contrib modules that call node_load(), you'd simply find & replace it with node_load__d7b(). 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.

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.

Drupal.org not secure after January 5, 2025

It was written in the sky. The most important pages of Drupal.org will not be secure after January 5th, 2025.

Drupal.org pages related to modules and accounts are still using Drupal 7:

If the security teams abandons support for Drupal 7 January 5th, we should not trust using Drupal.org, even tough the login process migrated away from Drupal 7. The most important pages of Drupal are still on Drupal 7, including user profiles.

If the Drupal 7 used on Drupal.org gets security fixes, those fixes should be offered for free and a new version of Drupal 7 should be released.

New.Drupal.org

Note that this does not affect the new pages built for the https://new.drupal.org running on Drupal 10. Those pages are mostly hosting a new site running on Drupal 10 with many redirections to the Drupal 7 site.

In other words, a new frontend built on Drupal 10 with a new theme with a not secure Drupal 7 backend.

Still on Drupal 7

https://jobs.drupal.org will not be secure after January 5th, 2025.

<meta name="Generator" content="Drupal 7 (http://drupal.org)">

Secure

https://api.drupal.org/

Drupal 7 has extended support options and one of them is through Tag1.

Correct. Also (see the bottom of almost any page on d.o):

Infrastructure management for Drupal.org provided by [Tag1 logo]

Tag1 may also provide security support for d.o. I think it is fair to say that d.o will be less secure after EOL, supported (perhaps) by Tag1 instead of being supported by the Drupal Security Team. OTOH, it is still possible that the transition to the D10 site will be complete by then. I am not sure of the schedule, but I know that the Drupal Association (DA) is working hard on the migration.

If the Drupal 7 used on Drupal.org gets security fixes, those fixes should be offered for free and a new version of Drupal 7 should be released.

I disagree. The DA is not the Drupal Project. The DA maintains d.o. and has no obligation to share improvements they get through their contract with Tag1 (or any other provider).

OTOH, according to https://d7es.tag1.com/faq,

... you can share the security updates provided through Tag1 D7ES, as they are open-source software under the GPLv2+ license.

I expect that, one way or another, security updates will be shared publicly. (That is my personal expectation, not official policy of the Drupal Security Team nor anyone else.)