Error when project name and module name don't match

I have added a patch for the changes, please review
Thanks

@viren18febS
The change only for the specific case mention. I was looking for a more generic solution to cope with all cases.
Thank you for the patch, I will use that until the generic solution is available. and a modified version of it for the other instance.
The another peice of information that could be helpful is that $variables['directory'] is set to the custom theme directory and not the base theme govuk_theme that it extends.

I didn't know there could be a difference between the module name and info file, but that seems to be a thing. In general, Composer Deploy should probably just bail out in edge cases like this (and maybe log the exception). Something like:

try {
  $projectData = \Drupal::service('extension.list.' . $project_type)->getExtensionInfo($variables['project']['name']);
} catch (Exception $e) {
  // Log the exception somewhere?
  return;
}

We've run into a related issue with CKEditor 5 Plugin Pack → . The Plugin Pack depends on code from CKEditor 5 Premium Features → , which must be present in the codebase, but isn't (usually) enabled/installed as far as Drupal is concerned.

In this setup CKEditor 5 Premium Features actually appears in the list of installed modules on the Update Report (even though it's not installed — weird, I know). When Composer Deploy comes along, it fails because the call to $projectData = \Drupal::service('extension.list.' . $project_type)->getExtensionInfo($variables['project']['name']); throws and exception for ckeditor5_premium_features, since it's not actually installed.

MR prevents a fatal error in these edge cases. Static patch attached.

Hmm, that last patch in #7 seems to have the lines out of place.

Anyway, I've just written something more generic to actually load the info, rather than just skip. Patch attached.

The code could be simpler if only sort() is replaced with asort() in function template_preprocess_update_project_status() in core.

sort($project['includes']);
// Change to:
asort($project['includes']);

If i have the time later today I might create a patch for that.

That seems to apply to Drupal core: there is no drupal module name and indeed one gets that kind of error

webflo → changed the visibility of the branch 3412035-fix-project-update-status to hidden.

webflo → changed the visibility of the branch 3412035-fix-project-update-status to active.

webflo → closed merge request !7

New attempt, the explanation is in the code docs. Please review https://git.drupalcode.org/project/composer_deploy/-/merge_requests/9

@khaled.zaidan Sorry, I overlooked your patch, I ended up with the same solution. Thank you!

Automatically closed - issue fixed for 2 weeks with no activity.