I have tested this item ✅ successfully on 84a7cfd

so if the other pr just unpublished the plugins, and we leave the module enabled, and this pr hides the module, does that make everyone happy or should I just abandon the other PR? I'm not invested in it, it was just requested by @dgrammatiko

I did another PR to make unpublishing sample data plugins easier. Personally I'd prefer my approach - but I have no say.

I did another PR to make unpublishing sample data plugins easier.

But the problem is that the UX is ruined whenever users need to manually complete tasks that should be transparent to them. Basically, this whole conversation just proves that the whole architecture (plugin+module) here is totally wrong. The sample data should have been a component (eg com_onboard) that will be the default route whenever a user installs something (and it provides an onboarding experience). Also, it would be nice because it would allow devs to do whatever they want there (SPA basically) and then just remove the routing (or even uninstall the component) so the default route defaults back to com_cpanel...

Feel free to rewrite and improve the whole thing for J5 ?
The current implementation never was proposed as a perfect solution. But even like this it is far better than the hardcoded, unmaintainable SQL files we had before ;-)

I have tested this item ✅ successfully on 84a7cfd

RTC

tks