Exclude Ludwig-managed modules from Update Manager

There is a way to do this.

It's convoluted, but

1. hook_batch_alter
2. Check for batch set in update_authorize_run_install
3. Add operation to download packages sent to update_authorize_batch_copy_project operation

Ok but now how do we know there are available updates?

Here is how I disable modules that I have patched (placed in /modules/patched) from the UI Module update form (admin/reports/updates/update) while still have them show up in the available updates list (admin/reports/updates)

<?php
use Drupal\Core\Extension\ExtensionDiscovery;
use Drupal\Core\Form\FormStateInterface;
/**
 * Implements hook_form_alter().
 */
function prevent_auto_update_form_alter(&$form, FormStateInterface $form_state, $form_id) {

  if($form_id == 'update_manager_update_form') {
    $scanner = new ExtensionDiscovery(\Drupal::root());
    $modules = $scanner->scan('module');
    foreach ($modules as $name => $info) {
      if( strpos($info->getPath(), 'modules/patched') !== false) {
        if(isset($form['projects']["#options"][$name])) {
          $form['projects']["#options"][$name]['title']['data']['#markup'] .= ' ' . t("PATCHED MODULE - AUTO UPDATE DISABLED");
          $form['projects'][$name]['#disabled'] = true;
        }
      }
    }
  }
}

Maybe you could just disable auto update of Ludwig-managed modules while still let us be aware of new available updates?

Created patch with @nicolas-bouteille idea.

Haven't tried this, so no idea if this is helpful, but in theory Ludwig could provide a replacement implementation of core/lib/Drupal/Core/Updater/Module.php that defines its own version of public function update() which does whatever you want after it unpacks the downloaded tarball. Or something. ;)

Otherwise, I'd be open to adding stuff to the core Update Manager to make this cleaner, if possible. The tricky part is that the Update Manager itself is running with a very stripped down bootstrap of Drupal, to try to minimize the footprint of stuff that can break if we're updating stuff out from under it. So I guess that makes my first suggestion unhelpful, since I don't think we'd load all modules to be able to find the replacement class. :( And it makes triggering an event that contribs can subscribe to useless, since none of the event subscribers would be loaded, either. :(

Bummer, I guess this is a thorny problem. Maybe the best I can offer is something akin to hook_update_status_alter() that lets you more cleanly alter what projects appear on the 'Update' form, independent of the 'Update status' report. /shrug

Patch #9 failed to apply due to newline at the end of file issue.

No interdiff since it's just a new line at the end of file.

Manual testing looks good as well. Image attached.

Very useful addition.

I was wondering for years why my update manager is skipping to check commerce/address... modules' updates. It never came to my mind that Ludwig has something to do with that. :)

Merging-in patch #2 from #3172544: Add Ludwig's hook_help() to avoid git merging during commit... since these two patches affect the same ludwig.module file.

Starting to look good, thanks! A few points on the latest patch:

1. +++ b/ludwig.module
   @@ -1,15 +1,41 @@
   +function ludwig_form_alter(&$form, FormStateInterface $form_state, $form_id) {
   

   This would be much better as hook_form_FORM_ID_alter(), not a generic hook_form_alter() and testing the ID manually. It's much more performant to have a separate hook for a specific form, so that we don't have to run ludwig_form_alter() on every form on every page load.

2. +++ b/ludwig.module
   @@ -1,15 +1,41 @@
   +        $form['projects']["#options"][$name]['title']['data']['#markup'] .= ' ' . t("(Ludwig managed module. Needs manual update.)");
   +        $form['projects'][$name]['#disabled'] = true;
   

   This form has support for a whole other "Needs manual update" section. Maybe it'd be better to move these projects to this other section, instead of doing this. See $form['manual_updates'] or core/modules/update/src/Form/UpdateManagerUpdate.php and search for "manual" for more. Happy to answer questions on the details, if needed.

3. +++ b/ludwig.module
   @@ -1,15 +1,41 @@
   +/**
   + * Implements hook_help().
   + */
   +function ludwig_help($route_name, RouteMatchInterface $route_match) {
   +  switch ($route_name) {
   +    // Main module help for ludwig module.
   +    case 'help.page.ludwig':
   +      // Return a line-break version of the README.md.
   +      return _filter_autop(file_get_contents(dirname(__FILE__) . '/README.md'));
   +    default:
      }
   

   This might be a good move, but it's definitely out of scope and should be in a separate issue/patch about rendering the readme into the help page.

Thanks!
-Derek

Re: #15

1. Good catch. Implemented.

2. I took a look. Although there is "manual" section in update form it is a bit hardcoded to be used for core updates only.

For example, if we move ludwig supported modules to this section... if core is up-to-date and one of ludwig modules is not - the subtitle of the section will still display: "Automatic updates of Drupal core are not supported at this time." which may confuse somebody since drupal core will not be listed for manual update below.

I just made a Drupal core task request to make "Manual updates required" section of update form more friendly to be used for other modules and not drupal core only. #3172953: Hardcoded Drupal core notice at "Manual updates required" section title

So, I would stick with "disabled" for now... if you agree...

3. Help part is removed and #3172544: Add Ludwig's hook_help() is reopened to deal with that issue.

Interdiff from #11 - last patch without help section in it.

Thanks all. Committed to 8.x-1.x-dev.

With #3177835: Add "Download missing packages" button to Reports > Packages page committed, we can allow automatic updates for Ludwig managed modules again.

The follow-up issue is here: #3183192: Allow automatic updates for Ludwig managed modules again