Retire Ludwig?

Thanks for ticket @DamienMcKenna.

The Ludwig usage record is not dipping ever since it was created. 9.5k users at the moment.

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

There are two kinds of Ludwig users:

1. Those who are not familiar with command-like tools like Composer yet
2. Those who want to avoid Composer for other reasons.

As long as we have an option to install currently supported Drupal Core versions without Composer - there will be Drupal users who will need to install contributed modules without Composer as well. Ludwig is created for them.

@DamienMcKenna
BTW... do you know is there any plan or active issue request to abandon Drupal vanilla installations for good in the near future? And what would be the Drupal community reaction to such idea?

@bojanz
Maybe Drupal Commerce team and @bojanz can give their opinion as well... they have created Ludwig 7 years ago to solve numerous "How can I use Drupal Commerce module without Composer" requests.

plan or active issue request to abandon Drupal Core vanilla installations for good in the near future?

Installs not using composer are already deprecated via the D.O. UI, manual downloads all include the warning "Downloads are for manual installation, which is not recommended when using Drupal 8 or later."

🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active is the relevant meta for core removing all support for non composer installs. The issue is tagged for formal deprecation in D10 and removal with the D11 release.

I'll note from 📌 Update the docs for installing via Ludwig Fixed that the commerce project has stated that composer is the only official install method.

Sorry, while we don't mind alternatives like Ludwig existing, we don't intend to recommend it. From an official project standpoint, you should only be using Composer, and we can only really support users who are using it.

Thanks for link @cmlara. I read through it.

As much as I understand... when Automatic Updates will be ready for use many other things will follow swiftly - like Deprecating tarballs, Removing the in-place updater UI for contributed modules that downloads tarballs etc.

That moment looks good to me to retire Ludwig as well.

IMHO, immediate retire of the Ludwig module would cause problems right now. However, once automated updates are available it'll be significantly easier to get beginners (people not comfortable with the command line) to go away from Ludwig.

Proposal

What do you think about an idea that we add a "Ludwig end of life" notice to Ludwig users now (to the main project page) that the Ludwig module retirement is going to happen soon (once the tarballs are removed from drupal.org)? So that everyone gets ready for that moment in advance.

Any other suggestions?

immediate retire of the Ludwig module would cause problems right now. However, once automated updates are available it'll be significantly easier to get beginners (people not comfortable with the command line) to go away from Ludwig.

Your proposal is great in my opinion, just once aspect seems to be missing WRT that: users better start learning to set up Drupal sites with composer now, especially new ones. Because their disappointment might be huge, if they get started with alternative methods only to learn pretty soon, that they have to start over when they want to use the fancy stuff.

So, declaring Ludwig deprecated now sounds like the right way to go, combined with a section on the project's page which helps people to find the documentation and tutorials on how to get started with modern Drupal.

This is what you proposed with a "Ludwig end of life" notice, I guess. So, I'm +1 for that. Ideally combined with the links mentioned above and an explanation why it's a good thing to get used to composer.

I think that Ludwig usage shows that any decision to deprecate the module is premature.

There is a significant number of people who will download Ludwig from a warez site if they have to, just to have a way to fetch libraries via UI and not via command line. No argument apart from a new UI (which I understand Automatic Updates will eventually be) will be enough.

Thanks @bojanz. I agree. To retire Ludwig before new UI solution is launched would be harsh to all Drupal users who are not command-line friendly yet.

I have added a note about Ludwig EOL to the project home page with link to this discussion.

Let's postpone this issue until a new UI (which we understand Automatic Updates will eventually be) will be around the corner.

However, feel free to post more comments, or even reopen this issue if needed.

I really would like for Drupal to continue an automated process like Ludwig - implementing it into their core.
After all - updating is why mere mortals like me nearly dropped using Drupal - this would make a huge difference for Drupal to be more user-friendly.

So giving it a shot (due to my hoster not providing composer), I downloaded the Ludwig tar, uploaded it and it instantly was available for activation.
After that I was asked to update the database - so I clicked my way through it (without having to change anything),
and - like a miracle - I automatically now seem to have updated to Drupal 10.4 which is great.

The only problem so far I see is when I change theme settings:
I can change the theme and it works, but after chaning anything (in 3 different themes),
I am directed from ...en/admin/appearance/settings/myTheme to
...en/admin/appearance/settings/myTheme again, but
with a long waiting time after which the browser said:
" Hmmm… can't reach this page - The connection was reset."

So it seems the update work like a charm with Ludwig, but not everything works as expected.
Does anyone have any idea why this could be the case?

Re: #8

Hi @true pal. The second part of your post with a question is off-topic here. To get a proper help it would be better to delete that part from this closed issue and post it as a new issue (support request).

Thanks for your reply, devad, which I just saw a week later.

For anyone with Drupal update problems I would like to point out here that my impression as a Drupal-layman is that the Drupal community seems to live in their own high castle - maybe even deliberately.
After months of trying to install and update Drupal tediously with composer on a local xampp-apache to then upload the thousands of files manually in vain - and after trying a multisite finally having given up on Drupal alltogether
I installed wordpress, phpBB-forum and prestaShop
and the first mail I got a second after the wordpress installation was:

Howdy! Your site has been updated automatically to WordPress 6.3.2.
No further action is needed on your part.

If Wordpress can do it fully automatically even in the background I see no reason for Drupal not being able to do the same.
Yes, there are Drupal-dependencies, but so are there in wordpress.

Re: #10

If Wordpress can do it fully automatically even in the background I see no reason for Drupal not being able to do the same

It's work in progress. Called Automatic Updates. Not ready for use yet (Alpha release only) . You can take a look at:

https://www.drupal.org/docs/8/update/automatic-updates →
https://www.drupal.org/project/automatic_updates →

Not deprecating now, and waiting for an alternative UI solution makes sense.

But we could add an "Upcoming EOL" warning at the top of the project page, recommending new Drupal users to use Composer in new projects? Like @jurgenhaas suggests, with "... with the links mentioned above and an explanation why it's a good thing to get used to composer."

So, basically combine the two "Switch to Composer!" and "Ludwig EOL?" sections, and place them at the top.

Thanks @ressa and others.

I have changed the first two sentences at the top of the project page to reflect your idea.

Thanks @devad, that looks great and will help people decide whether to go ahead with Ludwig, or use Composer.

Hi, I actually just found out about this module, or maybe I forgot about it

I am one of the maintainers of the Automatic Update module and tech lead of the initiative to get it into core. We have now had a stable release for a while. The main module just updates Drupal core(because that is the core MVP) but we now also have a sub-module that updates contrib modules and themes

Some thoughts on:
#7

Let's postpone this issue until a new UI (which we understand Automatic Updates will eventually be) will be around the corner.

and #11

Once the fully functional Automatic Updates module will become the part of Drupal Core - the Ludwig module will retire.

Getting into core is very, very slow process 😢

One of the main blockers is getting the The Update Framework implemented on Drupal.org. But this is above and beyond what virtually any site using Composer has now and I assume the level of security Ludwig itself has.

So as a replacement for Ludwig I think the contrib Automatic Updates is ready. The MVP version of Core Automatic Updates won't have contrib updates anyways.

Automatic Updates does not support installing new modules but Project Browser → does and it leverages Package Manager which is a sub-module of Automatic Updates(will be its own module in core)

Package Manager is really a Composer API module that can be used other composer operations.

Another module that might be of interest is Automatic Updates Extras → which I created as place for update/composer related things that are not likely for the Drupal core path. If there are features that the main Automatic Updates and Project Browser don't have but are needed by users of Ludwig that could be place for them.

For example we could add a "convert to composer" feature to Automatic Updates Extras. Or you could add that to Ludwig itself using the Package Manager API.

Anyways let me know your thoughts or you have questions about the state of the Automatic Updates initiative. I assume there might be a lot of overlap between Ludwig users and the intended users of Automatic Updates/Project Browser.

If you want to you could be link to these projects on our project page under Switch to Composer! letting users know these provide a UI so for the most part they won't have to deal with Composer directly. Right now it is only linked under Ludwig EOL? with a mention of it getting into core

@tedbow

I think it would be a great solution to add the Ludwig file.json in the Automatic Updates module. This would be the first step towards a smooth and painless transition.

Re: #15. Thank you @tedbow.

I have added a recommendation for Ludwig users to switch to Automatic Updates contrib module at the Ludwig project page.

I hope this helps.

It would be nice to hear the experiences of Drupal UI oriented users who are using Automatic Updates already. If it works nice for them I believe we can put Ludwig EOL even before Automatic Updates push itself into the Drupal Core.

What is your current experience? Is using Automatic Updates module (for updating both Drupal Core and contrib projects) now nice and smooth or not so convenient yet? Is there any reason to keep Ludwig active still from your point of view?

Module needs new issue to deal with 11.2 upgrade which gonna remove authorize.php route #3491731-35: Remove the ability to update modules and themes via authorize.php →
Guess moving route should not be a blocker

package_manager, which is the underlying API used by both automatic_updates and project browser, is now in core as an alpha experimental module.

Once it reaches stable, automatic updates and project browser will be able to depend on the core code directly which will make the contrib surface area smaller.

We're also talking about the best way to get automatic updates and project browser into core - however now that both are included in Drupal CMS, they'll be getting a lot more exposure/testing soon anyway.