Automatically remove manage_display_fix_title on Update to 2.x

Unfortunately in Drupal composer is totally unaware of sub-modules.

We could try to have an update hook that removes the sub-module - provided that it gets to run before Drupal crashes.

Perhaps ensure that version 2.0 can only be installed in 9.4 and above and push an update to version 1 that limits it at 9.3.*.

Then in 2.0 you could empty the module, but keep the info file and mark it as deprecated or hidden?
I suppose it could then uninstall itself in an update hook?

Perhaps ensure that version 2.0 can only be installed in 9.4

Already done in info.xml

push an update to version 1 that limits it at 9.3.*.

I reckon that composer is "too smart" for that to work. It could find a "solution" using 9.4 and the existing beta. So we could instead push 1 1.x that works with 9.4. This IS says "it crashed" - please can someone add the actual error message?

Then in 2.0 you could empty the module, but keep the info file

Good idea - if the update hook doesn't work on its own that's the solution.

Patches welcome - I've not had time yet to try 9.4.

I think adding an uninstall in an update hook will fix everything.

Great patches welcome

I just updated a site to D9.4 and it worked fine.

The described step to reproduce is this

composer update --with-all-dependencies

Which I guess has also caused an update of manage_display to 2.x. That would make much more sense to explain the reported symptoms. I updated the title and IS. If anyone does not agree then please comment to explain.

I added an instruction to the release note to explain the need to remove manage_display_fix_title manually. Definitely would still be good to have a fix here.

Won't you run into these issues then? https://www.drupal.org/node/2487215

I think a decent uninstall is still a better solution then just deleting it (could be in the main module as well though).

Taking the direction from #5, MR for review.

Thanks for the patch. For me it reports an error, which I can ignore and continue.

 [error]   (Currently using Missing or invalid module The following module is marked as installed in the core.extension 
configuration, but it is missing:
 * manage_display_fix_title

Options I can see

1. Use this patch - it's definitely an improvement on what we have now.
2. Use this patch and put back the manage_display_fix_title.info file. However when can we safely delete it??
3. Put something into 1.x that uninstalls manage_display_fix_title if Drupal version is >=9.4.

Comments anyone?

Read the link in #9 ;)

Read the link in #9 ;)

OK I read it😃. Please can you explain in more detail what you mean by "a decent uninstall "?

Let me start by saing that I don't have any experience with this either. All I know is that Drupal really does not like it when an installed module's files are suddenly missing.

What I meant is also listed as the preferred solution in the above link. Restore the files to their original location and have Drupal uninstall the module. That basically would result in option 2 from the above post. Hide the info file as explained in #3. It can then be dropped on the next major release at the soonest I think...
Option 3 can (and perhaps should) be done regardless of all this. And should mitigate the issue for most users.

For the 33 (registed, but could be more) users that installed this module I am wondering what would be neat. Theoretically it is an alpha relaese, which also suggests that some issues can be expected
All users that upgraded to an alpha release perhaps should be prepared to run into some issues... ? That would be options 1 and 3.

I have been thinking if something with hook_requirements could work. Maybe you can detect if the title fix module is installed during update and runtime. But then instruct the user to first downgrade and then uninstall the submodule before updating again is also a bit silly I guess.

I think we can use hook_requirements to remind folks to uninstall the module if they somehow reinstall it (warning at runtime).

We could honestly just turn the submodule into a stub (that doesn't do anything) in the 2.0.0 branch, then have the 2.0.0 update hook remove it if it's enabled, and remove it entirely in a future update. That way, more users have the likelihood of uninstalling the module prior to it vanishing into the sunset.

Thanks for the comments. So it seems like we should put back the info file, marking the module as hidden. In addition to that I made some minor comments in the MR.

I'm not so worried about the 33 sites on 2.x alpha already as most likely they solved the problem and it's anyway an alpha. Also I'm not so worried about people who reinstall the hidden module again after the update hook removed it as I feel they created their own problems.

Assigning to myself.

I actually wonder if lifecycle: obsolete will do everything we want (show error and push people to remove it)?

Great thanks for the new patch.

I actually wonder if lifecycle: obsolete will do everything we want

Sounds like a good idea however lifecycle_link is required also - tests are failing.

I feel we might as well keep the update hook now that it's already been written.

There was a mixup on one of my comments in the MR - I made a new comment there.

Added lifecycle_link here to link to the removal of the submodule in 2.x - should be for review.

No idea why the extra line comments in the MR were showing that way - I undid the original interpretation and I think went in the route you want. Feel free to go in there and adjust as needed if I'm not reading that correctly.

For review.

Great thanks. The obsolete method works really well.

I am bit late to comment, but shouldnt we only automatically uninstall on >D9.4 systems? Or update the minimal version to 9.4?

Theoretically this sub module is still relevant for 9.3 systems because there the fix is not yet in core right?

Update, nevermind the module is empty anyway.

This fix is only in 2.x which already requires minimum D9.4