Thread for feedback about D6 LTS and how to structure D7 LTS

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
greggles's picture

There is an announcement thread for D7 LTS that recently got a comment that seems to propose some changes for how D7 LTS is managed.

I'd like to split that discussion off of the issue on drupal.org and into the context of this group where it is more appropriate.

Joseph Olstad said:

It is of my opinion and of many of my pears that Drupal 7 LTS support should remain 'open source' and free. The community will come together and make this happen. Any attempts to thrwart this effort will result in forking. We're better off keeping our efforts as a community. Thousands of very large institutions are heavily invested in Drupal 7 and will want to keep it going for a very long time much like Cobol is still used in Banks, Drupal Classic will be in use for decades to come.

I would call it 'Drupal Classic' , Drupal Classic would be Drupal 7 without the constraints of the D8/D9 backport policies. Since D8/D9 is such a radical departure I think it no longer makes sense to constrain Drupal Classic to D8/D9 backporting policies.

Merge every compatible piece of Backdrop into Drupal Classic, and continue active development. D8/D9 may never reach the popularity of Drupal Classic, no sense in holding it back.

More generally, let's discuss what people do or don't like about D6 LTS program and how it might change for D7.

Comments

It is of my opinion and of

greggles's picture

It is of my opinion and of many of my pears that Drupal 7 LTS support should remain 'open source' and free.

The D6LTS program is open source and free. All clients who pay for D6 LTS are basically guaranteeing that core and the contrib that they use will get coverage from the LTS providers. However, the providers of D6 LTS release patches publicly for free at the same time their clients get the patches.

Anyone who wants to attempt to backport random patches that are in modules not covered by the LTS program can certainly do that in an open source, free manner.

Regarding incorporating Backdrop code into Drupal 7 and drupal.org, that feels to me like a different topic/proposal beyond LTS and I'm interested to hear other's thoughts on that.

What do you think of D6LTS?

dsnopek's picture

@joseph.olstad I'm curious your opinion of D6LTS. Have you followed D6LTS? If so, do you consider that effort to be 'open source' and free?

Speaking as a D6LTS vendor, we've contributed all the security AND bug fixes we've done in Drupal 6 core and contrib back to the community, and have taken patches/PRs from the community.

Due to the license and the fact that all the code is in the open, I think it technically qualifies as open source. But I just wanted to see if the community has seen it as 'open source' or not, and if a similar model would be acceptable for Drupal 7 or not?

Apples to Oranges

joseph.olstad's picture

Drupal Classic development should continue indefinitely with the main goal of high levels of compatibility with new features added as the community wishes. The market justifies it (and it does IMHO), development will be accelerated by making it unconstrained from D9/D8 forward porting policies. Also, by rebranding D7 as Drupal Classic, will remove the stigma of a number somehow determining value. Many people value compatibility and simplicity in favour of a version number, building on their existing investments.

I didn't pay attention to D6LTS because all my D6 clients upgraded fairly easily to D7 as it was virtually the same platform with some relatively minor changes to core and the apis with the exception of the database abstraction layer. So I don't have an opinion on D6LTS however I've heard from others who would have rather preferred D6 to continue on with Drupal.org as community supported open source as was before.

It would be easy enough to finance this, ask people using Drupal Classic to make donations to the Drupal Association to pay for keeping it going on Drupal.org.

Set a financing target on Drupal.org , and if that target is met, Drupal Classic continues on.

Also, by rebranding D7 as

rahim123's picture

Also, by rebranding D7 as Drupal Classic, will remove the stigma of a number somehow determining value.

Extremely important point. As proof of this, I've had a few users on my D7 site who like to think they're more technically illuminated that started complaining about how "our admin is too lazy and unconcerned to upgrade to Drupal 8 after all these years, which is why he's running an ancient and unsupported Drupal release that's probably full of security holes". (I religiously and urgently apply all security fixes for D7, usually within minutes of their release.)

joseph.olstad's picture

Drupal Classic, Carpe Diem, sieze the day!

the opportunity is now, must act now!

Can I just say as a

awebmanager's picture

Can I just say as a non-technical sitebuilder who has invested countless hours into building Drupal 7 sites that this sentiment is extremely welcome. Many small businesses use D7 and it will be hard for many of them to find the money to upgrade to D8. Certainly the main D7 site I manage, with a lot of customisation and integration with external packages, will cost into the hundreds of thousands to be updated, since in my experience an entirely new website will have to be created. D7 has been an absolutely fantastic platform and it makes no sense for it to be left to die. I accept of course that platforms have to move on, and you could argue that following the above logic 10 years ago we would all still be using D5 or earlier, but I started with D5 and for me D7 has been by far the best version of Drupal, so I don't think it compares to older versions and is definitely vital to maintain.

agreed

joseph.olstad's picture

I very much share this sentiment!

To me it makes sense to take D7 and rebrand it as 'Drupal Classic' , build on it's strengths and bring the strengths of Backdrop into it, bring the Backdrop people back in. I would like to hear what someone like Quicksketch has to say about this , see if he's interested in leading such an effort? Focus on compatibility but forward thinking.

I have a feeling that Quicksketch will say...

dsnopek's picture

I have a feeling that Quicksketch will say you should just switch to Backdrop :-)

Ya he might say that

joseph.olstad's picture

But I think one of the reasons why he created Backdrop was because of this predicament. Maybe under the right circumstances he and his Backdrop team could be put into the drivers seat of a Drupal Classic on drupal.org , be enticed to move forward Drupal classic in a way that works for both Backdrop and "Drupal Classic" as I call it.

Reminds me of New Coke, which became CocaCola Classic, and then back to Coke again.

Everybody loved CocaCola Classic, that is what they wanted, eventually Cocacola saw the light and now it's forever Classic.

Backdrop is like your Cherry Coke.

It's based on CocaCola Classic, but it's got Cherry's in it, some people are allergic to Cherries.

dsnopek's picture

I think the main difference is: Backdrop is continuing to innovate and add stuff (it's kind of like an "alternative reality Drupal 8"), whereas Drupal 7 Extended Support will just be about keeping Drupal 7 going as-is, with security updates, minor bug fixes and probably upgrading to PHP 8 once that's a thing. :-)

It's easier to migrate from Drupal 7 to Backdrop, than it is to go from Drupal 7 to Drupal 8, but it's still a migration because it hasn't stood still, it's continued to change and grow.

What you're describing with "Drupal Classic" actually sounds a lot more like Backdrop, because you're including active development of new stuff.

And, in that case, Backdrop exists and is usable, so why not just use that? In fact, if a sizeable portion of the community makes that calculation and moves to Backdrop, that will finally prove out the premise of Backdrop. :-)

However, I think there would probably still be a demand for Drupal 7 Extended Support (in the mold of D6LTS), because some organizations might not want all the disruption of migrating to Backdrop - they might just want to pay some money to keep their Drupal 7 site going with as few changes as possible.

Drinking some D8 coolaid now

joseph.olstad's picture

I'm drinking some D8 coolaid, took a while to get over the initial shock of D8.

D8 is pretty good. I still think that a 'Drupal Classic' makes sense

Backdrop doesn't work for me, all my clients use entity_translation.

Drupal 7 has the goods. Pol and FabianX are doing a good job of maintaining Drupal 7 core, would be good if the Drupal gods would slack off on the policies holding back Drupal Classic from acheiving what I think it should acheive.

There's enough market share for both Drupal Classic and Drupal 8/9/10

all this doomsday talk about EOL is really short sighted.

The EOL doomsday is a slow doomsday :-)

dsnopek's picture

all this doomsday talk about EOL is really short sighted.

Well, looking back on D6LTS, and making inferences about what will happen with Drupal 7 Extended Support, I think there is a "doomsday" in there, but one that arrives relatively slowly.

It wasn't until 2 years after Drupal 6's EOL, that Drupalgeddon 2 happened. In a world where there was no D6LTS, it would have been a lot longer after the Drupal 7 & 8 fixes were released that a Drupal 6 one was released too. However, the D6LTS vendors had a release for that out immediately (minutes after the D7/D8 one), so folks could patch before they were hacked.

There is no major PHP 5 security vulnerability... yet. But as soon as there is one (maybe a year or two from now?), folks on Drupal 6 will be happy that they have the option to update to PHP 7. Without D6LTS, I don't think there would have been a concerted effort to get Drupal 6 working on PHP 7.

Things like both of those WILL happen after Drupal 7's EOL too. There WILL be a Drupalgeddon 3, and eventually PHP 7 will be EOL'd and we'll be updating Drupal 7 and all it's contrib to work on PHP 8. Those things might not happen for several years after Drupal 7's EOL, but we need to have some kind of extended support in place to be ready for them.

And, well, the best way to make sure they are in place is to fund them somehow. It's hard to generate community enthusiasm around updating a contrib module that hasn't had a new release in 10 years to a new version of PHP. :-)

I feel like D6LTS is working pretty good, and feel like a similar model could work well for Drupal 7 too.

For Instance

joseph.olstad's picture

For Instance, I just got an offer from a big company to do Drupal Classic development for them. They are accustomed to very long software life cycles. Web technology and development has matured enough that I think Drupal Classic must live on for decades to come.

D7 contrib modules

rahim123's picture

I own/administer what I believe is one of the largest and most active forums running on Drupal 7. Basically as it stands now, Drupal 8 is completely unsuitable for use as a forum. I'm not good at coding, so I don't have a lot of custom integration that depends specifically on the D7 core. But I do depend on a bunch of contrib modules for important forum functionality, and most of them are not being ported to D8. So I'm really glad to see this initiative!

My question is: Since I mainly depend on the functionality provided by D7 modules and not so much on the core itself, what about security review of those modules? Even if the community maintains the "Drupal Classic" core, how could we avoid the risk of old but necessary modules and themes with undiscovered and unreviewed vulnerabilities hanging around?

How contrib modules are handled in D6LTS...

dsnopek's picture

Drupal 7 extended support (when it comes around) is likely to be very similar to D6LTS.

And in D6LTS, the individual support vendors decided which contrib modules they would support. In our case (mydropwizard.com) we support the modules used by our paid customers.

So, if we have a paid D6LTS customer that uses the Advanced Forum module, for example, then we'll monitor its security issues in the private issue tracker used by Drupal Security Team, so we can make a security release, or do some small bug fixes, or (as we did recently) update the module to work with newer supported versions of PHP (ie. adding PHP 7.2 support for Drupal 6).

For us, Drupal 7 extended support will work the same way! If we have a paid customer using a particular module, we'll support it, and of course, release all the work we do back to the community. But if we have no paid customers using a module, we won't do anything with it.

How the other support vendors decide which contrib modules they'll support is up to them, but I imagine it will be similar.

I see. That's a cool business

rahim123's picture

I see. That's a cool business model, thanks for the explanation.

keep it open source and free

joseph.olstad's picture

Dries should send out an email to all Drupal.org members asking to contribute 5$ to fund a "Drupal Classic" initiative. Divert the funds to the Drupal Association and some for hacker challenges. Optionally allow members to donate more money to this initiative.

Modify the core policies to allow Drupal Classic to do semantic releases like D8 does now but without having to always wait on D8 to do it's thing for a backport.

D8 is doing fine, going to be great, Drupal Classic should be branded and marketted positively, remove this EOL completely. Doesn't make sense to kill a perfectly good race horse.

^ This.I understand that

rahim123's picture

Dries should send out an email to all Drupal.org members asking to contribute 5$ to fund a "Drupal Classic" initiative. Divert the funds to the Drupal Association and some for hacker challenges. Optionally allow members to donate more money to this initiative.

^ This.

I understand that Drupal 8/9 is technically far superior to Drupal 7 and that's why the decision makers are basically trying to force us all to upgrade... But it's kind of like the Windows vs. Linux debate. I strongly prefer Linux for all my day-to-day desktop/workstation needs, and I recommend it to a lot of people, because I think it's technically the superior product. But if a certain user makes a living with a specific Windows program that absolutely does not have a Linux equivalent, it would be just plain stupid to suggest that he switch to Linux.

That's the predicament that I'll be in once D7 is no longer supported, as my site literally will not be perform the job it exists for (wouldn't even be able to render nodes, since a major input filter I use is not supported in D8) due to a lack of contrib modules for D8. I would like to be optimistic and hope the D8 contrib module situation will improve as we get closer to D7 EOL, but a comparison of the available modules that I depended on in D6 vs D7 doesn't support that hope. And as @dsnopek very appropriately reminded us, Drupalgeddon 3 is not a question of "if" but "when". So simply hoping for the best or relying on "security by obscurity" is not an option. Yet, I'm sure many admins will do just that.

So why kill D7 just for technical bragging rights?

agreed

joseph.olstad's picture

very good points made

Efforts to kill D7

joseph.olstad's picture

I saw the recent announcement
https://www.drupal.org/psa-2019-02-25

I'm disappointed that after all the hard work and collaboration working on a noble vision such as ours that a few people are attempting to cash in on our efforts for self gain.

I hope that Acquia reconsiders it's role in this.

There's other ways to keep things open.

Again, relating this to Drupal 6 LTS...

dsnopek's picture

As one of the vendors (myDropWizard) primarily responsible for maintaining Drupal 6 as part of D6LTS, it doesn't really feel like cashing in for self gain. We're doing work that no one wants to do, and most of the people who take advantage of that work don't pay us anything (because all our work is also released publicly for everyone).

I know that right now there is still plenty of interest in working on Drupal 7, and maybe at the moment it would be possible to rally a pure community effort to maintain it and fund it. And there might even be a fire to do so right around the EOL date too: the community did a ton of last minute Drupal 6 work right before and after its EOL date too.

But I have a feel that in 2025 (~3 years after Drupal 7's EOL - close to where we are now with Drupal 6) that it's going to be hard to find people to work on Drupal 7 and to fund it. How many people are currently interested in working on Drupal 6? How many people would respond to a call to fund Drupal 6 now? By 2025, Drupal 7's probably gonna feel a lot like Drupal 6 does today.

And, ironically, the more time that goes by, the more essential an extended support effort becomes to the people still using Drupal 7, because it's likely a couple years after EOL when all the really serious problems will start happening.

So, of course, I'm biased because I work for one of the companies that will be providing Drupal 7 extended support, but it doesn't really feel like a pure cash grab.

JordanMagnuson's picture

I just want to add my voice to this conversation and say that I really hope a workable LTS plan is put in place for D7.

I've been using D7 for years now (as well as D5 and D6 previously), and have many sites on the platform. Several on a multisite installation, that are all working just fine, as well as a very large and complex mission-critical site that has been on D7 for five years now, and again: working just fine.

Upgrading all of these sites to D8/9 would likely take me years of individual work (something > 12 months for sure), or cost > $100k to have others handle. I've always attempted to follow best practices, but still have many custom modules in use, and many of the contrib modules I rely on still haven't made it to D8.

I'm certainly not against new technology, but as others have pointed out, there's really nothing wrong with D7 at this moment in time: it works as intended. It works with the latest versions of all the technologies I care about (LAMP, Varnish, Memcached, Solr, etc.), and I don't see any reason why that should change any time soon (esp. now that Drupal 7 is running great on PHP7).

For most of the sites I run, I see no reason why they couldn't continue happily on D7 for many years as long as it was supported. And when the alternative is spending lots and lots of time/money just to get the same sites functioning in the same way that they are currently... you can see why I'm not keen to migrate.

So I think the "why kill a good racehorse?" question is rather apt.

Thought experiment: imagine if Facebook had to upgrade to a new platform every few years that effectively required it rebuilding the site from scratch and migrating all user content. I think this is a relevant thought experiment, considering that Drupal bills itself as a content management framework, not just a blog CMS. But if we're talking about a framework for building truly complex sites, we need more care given to backwards compatibility, and longer timeframes, IMHO. Core technologies like LAMP tend to have the kind of long-term perspective that I'm talking about: even an upgrade like PHP5 to PHP7 was relatively straightforward to deal with. But Drupal upgrades between major versions are a different beast entirely. I guess this is why people typically roll their own frameworks if they want to make a complex site like Facebook?

IMHO, any change to a framework that does not provide a truly viable upgrade path should not be billed as a new "version" of the framework: it should be spun off as its own project. Consider MySQL: it's not the new fancy kid on the block, but it works. If someone wanted to drastically change it in a way that would break every site using MySQL with no easy upgrade path, it wouldn't be a new version of MySQL--it would be spun off as a new database system.

Anyway, I've loved, supported, and defended Drupal for a long time (over ten years now), but I've also had a perpetual knot in my stomach counting down time to when I was going to be stranded between major versions again... if I had to do it all over again, I think I would have opted to use a more bare-bones framework with a longer-term perspective.

Very well expressed. Your

rahim123's picture

Very well expressed. Your "perpetual knot" comment is exactly what I feel, and it really tarnishes the otherwise good Drupal experience.

I also am regretting my choice of Drupal due to the hellish upgrades between major versions, which really are effectively equivalent to re-creating the entire site from scratch, with the additional complication of migrating existing content. I know that D8->D9 is supposed to be much smoother, but I'm still gun-shy after the absolutely dreadful experience I had with D6->D7, also motivated purely by the support lifecycle, not out of functionality concerns.

Thanks for sharing your perspective!

dsnopek's picture

Thanks for sharing your perspective!

So I think the "why kill a good racehorse?" question is rather apt.

After listening to lots of folks articulate their feelings about the Drupal 7 End-of-Life, this question is proving to be a great way to sum up what is bothering most people.

I think this is also where many other projects that went through a major rewrite have gotten stuck. For example, the transition from Python 2 to Python 3, which the Python community still hasn't completed even after 11 years.

Part of this, though, I think centers around what End-of-Life (EOL) really means in practice. It isn't necessarily killing Drupal 7: the D7 code will always be available, and D7 module maintainers are free to continue to make releases and support their modules (some maintainers have actually continued to make D6 releases!).

The main changes with EOL are:

  • Messaging: Drupal 7 won't be listed as a "supported" version
  • The Drupal Security Team won't spend resources on it. (The Security Team is a group of ~25 volunteers supporting all of Drupal core and contrib - we are dramatically understaffed)
  • There won't be an official Drupal 7 core team making new commits or releases to the official Drupal git repo

However, with Drupal 7 Extended Support, there will be vendors taking the place of the Drupal Security Team and Drupal 7 core team, doing similar work, and making it available to the whole community, just through different channels.

If you look to what happened with Drupal 6 Long-Term Support, we (I work for one of the vendors) have made over 100 release of Drupal 6 core and contrib, which included both security releases and bug fixes, including updates for PHP 7.2. We've also taken a few contributions from the community and rolled them into our releases as well, with all of this released publicly, just a like a normal Open Source project. :-)

The plan is for something similar to happen with Drupal 7, which means you could just keep using Drupal 7 after its EOL!

Or is there something missing from that vision that would still prevent you from continuing with Drupal 7?

if I had to do it all over again, I think I would have opted to use a more bare-bones framework with a longer-term perspective.

Drupal 7 was released in 2011, and will reach EOL in 2021: that's 10 years of official support from the upstream project.

Is there a framework that has had significantly longer upstream support? Looking at the major low-level frameworks (ex. Symfony, Ruby on Rail, Django, etc), are there ones that provided >10 years of support without having to do a major rewrite at some point? I'm not sure that there has been, but if someone knows of an example, I'd love to learn about it!

And with Drupal 7 Extended Support, it's possible that Drupal 7 could be supported for another 3 or 6 or more years after that. (The D7ES rules require the vendors to make 3 year commitments, so that's why it's in groups of 3.) We've already done D6LTS for 3 years, and have committed to do it until at least 2022 - I wouldn't be surprised if D7ES went on for at least as long or longer. :-)

Thanks for the explanation,

rahim123's picture

Thanks for the explanation, dsnopek. Are the "public releases" of D6LTS available as regular tarballs, or only from a version control system? Is there a common LTS repository, or does each vendor integrate their own patches?

D6LTS

dsnopek's picture

We (myDropWizard) make public releases:

https://github.com/d6lts/drupal/releases

Acquia participated in the "d6lts" group on GitHub a little too, when they were still a D6LTS vendor, but ultimately that ended up being just ours.

And we have our own update status data, that you can get your site to use via the mydropwizard module, so the "Available updates" report will reflect D6LTS releases (most importantly security release) and allow drush to pull in those releases too.

Those things are just myDropWizard, however, the D6LTS vendors do collaborate on the security patches which get published here:

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

So, those are all shared between the vendors. That project, its repo and its issue queue are the official "vendor neutral" place for D6LTS.

The vendors actually work together on the patches initially in private on security.drupal.org, where we have access to the same reports that the Drupal Security Team gets, and can have the D6 patch ready in advance to be released at the same time as the D7 or D8 patch.

So, in summary, some parts of D6LTS are separate for each vendor, and some parts are shared - but it's all ultimately released as Open Source as mandated by the D6LTS program. :-)

Thanks for your helpful

JordanMagnuson's picture

Thanks for your helpful replies, David: they are much appreciated.

How will the pricing work to get LTS vendors to support a D7 site, specifically in terms of potential contrib module vulnerabilities? (And also with regards to core vulnerabilities, I guess). How has that been handled for D6 LTS?

Pricing and contrib

dsnopek's picture

No problem :-)

Pricing and what all is included in a vendor's support offering is up to the vendor. For our (myDropWizard's) part, our D6LTS support plans are about more than just security patches - they mirror our support plans for D7 & D8, but are a little more expensive to account for the extra work.

You can see our D6LTS pricing here (we expect D7ES to be similar, but haven't decided on the details yet):

https://www.mydropwizard.com/drupal-6-lts

Basically, the way it works is that we'll fix security issues for Drupal 6 core, and any of the contrib modules used by our customers. So, if you're a customer, all your contrib modules are covered. We still release the updates publicly, so if you're not a customer, you can use them too, but it's possible that you have some contrib modules that aren't covered.

I don't know exactly how the other vendors offerings work or are priced, but that's at least one real world example.

I was not aware that you

onejam's picture

I was not aware that you release security fixes for D6 core to the public as i have not seen the security update files published anywhere? Your D6LTS support has always been advertised as paid support. But then again, I guess we don't check since we do not use D6 anymore. Just surprised to hear that it is also released to the public free of charge? I mean as a business how do you operate given away your services for free?

You can find the updates here...

dsnopek's picture

You can find the updates in the D6LTS project (the patches are committed to the Git repo):

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

... and we also make releases on GitHub:

https://github.com/d6lts

... or if you install the 'mydropwizard' module, it will put our releases on your "Available updates" report:

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

I mean as a business how do you operate given away your services for free?

That is the classic Open Source business question. :-)

People still do pay, and our services include more than just module updates. I don't know if we'd make more money if people were required to pay, but we believe in Open Source, and think this is the best way to do it for the Drupal community.

Thanks. It's also published

onejam's picture

Thanks. It's also published on your website's daily blogs. I should have checked your site before asking such silly questions regarding security updates for outdated core versions.

Handling of unsupported projects

ciss's picture

How are/were security issues for contrib projects handled that are not covered by any of the LTS vendors? I assume they're still documented in the security issue queue, but never fixed and never made public?

Those issues would be made public

dsnopek's picture

Those issues would be made public, either by making a public issue in the modules queue (if it only affected D6LTS), or via the SA and release for D7/D8. While I haven't really followed any of the unfixed issues that were made public, I'd assume that most weren't fixed after becoming public, unfortunately.

drush make

joseph.olstad's picture

I seriously hope that Aquia doesn't cut off the drush make system that relies on drupal.org.

I have a client that uses aegir and drush make. Relies on drupal.org to provide tar.gz of core and contrib modules (releases or dev) as well as patches.

dsnopek's picture

I don't think Acquia could do this -- it'd have to be folks at the DA -- but if the update status data on Drupal.org went away or became unusable for some reason we could work around it. In fact, we did this for Drupal 6 already! :-)

When the D6 EOL came around, the update status data was changed to make all projects unsupported and not show when security releases were missing. (This was actually later improved to still show security update information, so that folks wouldn't miss the Drupal 6.38 update, but I think that was like ~2 weeks after.)

Anyway, we (myDropWizard) made an alternate source of update status information which was basically a copy of the original data from Drupal.org, modified to not have everything be unsupported, and with our additional LTS releases added. If you install the mydropwizard module (or copy it into ~/.drush for drush make support) then your site will use this alternate information for the "Available reports", drush up, etc.

As far as I know, this works fine with Aegir too! Omega8.cc (an Aegir-based hosting provider) includes the mydropwizard module in their platform for Drupal 6 sites.

So, if something like this happened for Drupal 7 Extended Support, we'd be able to handle it ;-)

LTS should be postponned

joseph.olstad's picture

10 years still too soon. another 5 years, THEN LTS.

Is there any other CMS or web framework ... ?

dsnopek's picture

Is there any other CMS or web framework that had 15 years of full upstream support before switching to LTS?

Drupal 4.4.0 was tagged 15 years ago (April 1st 2004):

https://git.drupalcode.org/project/drupal/commits/4.4.0

So, that'd be like if we were still supporting Drupal 4.4 :-)

Anyway, if there's any existing projects that provide that kind of length of upstream support, I'd love to learn about it!

Biblical proportions

joseph.olstad's picture

The difference between 4.4 and 7 is a million installs or so not including the ones that have the update module disabled.

The number 7 is a biblical number as well. Php is version 7, not 8. Windows 7 outlasted Windows 8 and still in use.

2021 is premature retirement for lucky 7.
Biblical numbers stick in ppls heads. I upgraded to 7 because I didnt like the number 6 , despite immature D7 at the time .

Drupal 7 > Drupal Classic

Collins405's picture

All I can say, is yes please.

I maintain 200+ Drupal 7 website for clients.

I also have a massive saas software built on D7, which is built up of 15 server "clusters" - all with their own multisite code base, with 200 clients per server - all using 40+ custom built modules. The idea of ever upgrading that project to D8 or D9 honestly makes me feel sick. It would be a year of development, or hundreds of thousands to make it happen.

I will of course be signing up for D7 extended support, and love the idea of the rebrand to "Drupal Classic".

I think D7 will be the furthest I ever go with Drupal. I've tried D8 and just did not get on with it - its such a radical difference from everything we've learned and built - I might as well learn a completely different framework If I am ever forced to move from D7.

Thank you to those offering D7 LTS, i look forward to giving you my money!

Yes Drupal Classic should be unchained

joseph.olstad's picture

A few policy change from up top and marketting in this sense would be some welcome fresh air.

Drupal Classic

Collins405's picture

Has there been any progress on this? Is Drupal Classic a thing now?

joseph.olstad's picture

The silent majority will not even take the time to squeak.

The "Classic" initiative would be a great way to re-invigorate the Drupal brand as a whole.

As for progress, it seems that the people at the very top of the Drupal hierarchy are bound and determined to continue immutably with what worked "in the past".

Things changed, so to reinvigorate the Drupal brand I think that something has to be done and I've made my voice very clear about this.

https://www.drupal.org/psa-2020-06-24

rahim123's picture

https://www.drupal.org/psa-2020-06-24
Does this change anything for us? Thanks, hope you're all doing well.

Summary or official statements? Bad for Drupals reputation.

Anybody's picture

Hi all,

I clicked through the various discussions and issues linked here and there, but didn't find any "final" words, what will happen concretely after Drupal 7 EOL 2022-11.

It would be really nice and helpful, if there was an official FAQ page for that from the Drupal Association, Dries or whoever on Drupal.org. I'm looking for information like:
- Where will Security Updates be available (Git Repo?) and how to contribute individually?
- Will there be a module like "mydropwizard" for Drupal 6 showing the update information like it was possible in Drupal 6?
- What about the "Drupal Classic" discussion and Backdrop CMS?

There are still lots of really well working Drupal 7 Websites out there, which will not receive a lot of future additions, but are worth to live some more years...

It's still a problem for Drupal's reputation to tell customers, their site has to be upgraded, while it's still working and looking well... OR WILL DIE. Our experience shows that many of these customers are very disappointed of "Drupal" and are afraight of having the same problem again in some years with Drupal X ... so switch the Agency and use a different CMS... so from my perspective, that's also a problem for the Drupal brand!

The problem wouldn't exist if their page was already old and ugly and the customer can understand that the expensive Drupal X upgrade is needed... without technical knowledge ;)

Some more years of security updates (and clear information about that for the techies) would help a lot! Not only for the community members still loving Drupal 7 with its lightweight benefits, but also for the Drupal brand...

Julian

rahim123's picture

Thanks Julian for reviving this thread. Unfortunately I'm in the same situation, basically feel like I'm at the mercy of the Drupal community at this point. I'm going to repost some comments I made in the Advanced Forum module issue tracker, which is at the core of my problem:

I run one of the largest Drupal powered online forums, started on D6 and currently on D7, but as it currently stands it will *not be possible* to continue operating it with D8 or D9, nor will it be possible to continue running Drupal 7 after security support ends. The basic functionality provided by Advanced Forum is not available, and most of the contrib modules that it depends on for other basic functionality are also not available. Drupal has turned into a completely different monster than it was when I started with it in 2009. It used to provide almost turnkey functionality with the use of a plethora of high quality contrib modules. But now it seems to be turning into just a framework for techies and web developers, which I most emphatically am not.

But the thing is, I already have a huge Drupal forum with hundreds of thousands of nodes and millions of comments. Third-party forum integrations don't help at all because that would require migrating all of my forum posts to a new platform, at which point there's not much point in using Drupal.

Of course the Drupal code and even some of the core backend mechanisms have changed over the years. But the thing is, it appears that Drupal is taking 8/9 in a completely different direction in terms of goals and functionality. It appears that many former developers and contrib project maintainers for Drupal 6/7 don't like the direction it's heading and have moved away from it, hence the fact that so many contrib modules are no longer available for Drupal 8/9. But it's not because that functionality already exists in the 8/9 core.

I'm not referring to the functionality offered out of the box in Drupal. It's always been a "framework" in that sense, which I like and appreciate. I'm already heavily invested in complex custom systems based on Views and Rules for major portions of my forum's functionality, so I'm not asking for a free lunch served on a silver platter. But what I mean is that Drupal used to be highly extensible with high-quality and extremely abundant third-party modules, some of which covered very specific needs and small tweaks in functionality, and others that implemented entire chunks of website functionality. But now, with Drupal 8/9 the answer to specific requirements is usually "go code it yourself". So the existing core building blocks in Drupal 8/9 like Views and Taxonomy are great, but there inevitably comes a point that requires large chunks of PHP code and Javascript and CSS, which is where my skills fall short, and which used to be handily covered by contrib module creators that were happy with the former state of Drupal.

recent initiatives

joseph.olstad's picture

The new D7 core maintainer @mcdruid has led and driven a lot of great work lately for Drupal 7 including MySQL 8 support, php 7.4/8.0/8.1 support and much more including improved sqlite support and fixing long standing issues and improving performance in new core versions (we're at 7.83 now).

I applaud the recent initiatives and hope that they continue. We've still got a good thing going. Lets keep it up!

recent initiatives

rahim123's picture

Thanks @joseph.olstad for your reply. I also appreciate the efforts thus far to keep Drupal 7 alive and compatible with the modern server stacks. However, my understanding is that this has been done to fulfill the promise of maintenance during the defined D7 lifecycle, and that such maintenance by definition will officially cease in November of 2022.

LTS

joseph.olstad's picture

There's still many benefits to using a very stable platform like D7. The LTS support (while I disagree with the approach) will begin November 2022, it's not a total doomsday as there still will be security updates and it will be "open source".

I have already made recent copies of all Drupal.org contrib modules and core versions just in preparation for a possible forking of Drupal 7, have been debating possibly forking Drupal 7 into a new project however it would be lacking all of the current benefits of drupal.org and migrating all of drupal.org and reproducing the testing pipelines and patches would be a hurculean effort for one person.

It is my opinion that Drupal 7 should live on indefinately in some sort of a Drupal classic form. Drupal 7 being the most successful and most popular pre-symfony version of Drupal it has a lot of benefits that Backdrop is missing like entity_translation and compatibility with it'self whereas Backdrop is not compatible. The Drupal namespace is a trademark of Dries B. but I'm not sure if that would prevent us from using the Drupal 7 api with the drupal_ prefix.

With that said, I'm not in a rush to do such a fork as I'm hopeful that Dries himself will perhaps come around to the idea of keeping Drupal classic strategically and leveraging the full strengths of Drupal. I appreciate both pre-symfony and symfony based Drupals. I think both can co-exist.

So deep into D7

Collins405's picture

As I've said before, I am so deeply invested into D7 with a decade of custom development into it, there's no way I can ever upgrade without a full rebuild which is completely out of the question

I welcome, and would even fund a Drupal 7 Classic initiative, as I wil likely be employing a security team anyway when D7 LTS ends.

LTS

joseph.olstad's picture

There's still many benefits to using a very stable platform like D7. The LTS support (while I disagree with the approach) will begin November 2022, it's not a total doomsday as there still will be security updates and it will be "open source".

I have already made recent copies of all Drupal.org contrib modules and core versions just in preparation for a possible forking of Drupal 7, have been debating possibly forking Drupal 7 into a new project however it would be lacking all of the current benefits of drupal.org and migrating all of drupal.org and reproducing the testing pipelines and patches would be a hurculean effort for one person.

It is my opinion that Drupal 7 should live on indefinately in some sort of a Drupal classic form. Drupal 7 being the most successful and most popular pre-symfony version of Drupal it has a lot of benefits that Backdrop is missing like entity_translation and compatibility with it'self whereas Backdrop is not compatible. The Drupal namespace is a trademark of Dries B. but I'm not sure if that would prevent us from using the Drupal 7 api with the drupal_ prefix.

With that said, I'm not in a rush to do such a fork as I'm hopeful that Dries himself will perhaps come around to the idea of keeping Drupal classic strategically and leveraging the full strengths of Drupal. I appreciate both pre-symfony and symfony based Drupals. I think both can co-exist.

Drupal LTS

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: