Problem/Motivation

Splitting this off from #3303900: Remove PreApply check in PackagesInstalledWithComposerValidator

This is because the Update module will only fetch the Update XML for projects that are in the active codebase.

This problem doesn't make Automatic Updates Extensions unusable because you can still update projects as long as they don't add new dependencies that are Drupal projects. But it will be problem that Project Browser has to solve.

Proposed resolution

Move \Drupal\automatic_updates\ProjectInfo into package_manager

Then in the follow-up #3307163: Add the ability to ProjectInfo handle projects not in the active codebase, add the ability to get information about projects that are not in the active codebase.

This will probably involve making calls to via the Update module services. We should be careful that we don't accidently add these projects to the stored projects info that Update uses which could result in projects not currently installed being displayed on the Available Updates page that the Update module provides.

Remaining tasks

Issue fork automatic_updates-3303902

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

tedbow created an issue. See original summary.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue summary: View changes
tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Related issues: +#3303900: Remove PreApply check in PackagesInstalledWithComposerValidator
phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

I think we might want to add, to Package Manager, the ability to scan for projects (not just extensions) in a given directory (we could do this by, for instance, instantiating new ModuleExtensionList and ThemeExtensionList objects).

Then, if my theory is correct, we can call \Drupal\update\UpdateProcessorInterface::createFetchTask() to add them to the queue when we next call update_get_available(). Even if they're not installed or physically present in the code base.

Thoughts?

dww’s picture

dww
we/he/they
commented

Re #4: Your theory sounds plausible. However, I'm not completely sure what happens when we fetch the requested projects -- would their histories and info get added to the giant Array of Everything, then start trying to appear on the available updates report, etc?

dww’s picture

dww
we/he/they
commented

Upon successful fetch, it's stuffed into update_available_releases via the availableReleasesTempStore world. However, so long as you don't mess with the \Drupal\update\UpdateManager::getProjects() logic, the available updates report shouldn't care, since it just means we'll have release history for more projects than we need for the report.

tedbow opened merge request !448

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Status: Active » Needs work

Just starting to move the class and see what else needs to move

trying to figure out locally how to make the changes so we can get the update xml for a project that is not in the active codebase.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented

I have a working version now that gets the XML for project that is not currently installed. I think maybe we should change the scope of this issue though to just moving the class to Package Manager and then do a follow-up to make ProjectInfo work for projects that aren't the code base too, now that we know there is way to get the info for new projects.

Just moving the class and not changing the functionality would make the scope much smaller.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented

re #9

  1. I created a new branch `3303902-add-new-project-functionality` that has both the moving of the class and the adding of new functionality.
  2. ON the merge request branch, 3303902-move-projectinfo-class, I removed the changes to the functionality of `ProjectInfo` so it will just be the namespace change
tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Title: Move ProjectInfo class into package_manager and add the ability to get info for new projects » Move ProjectInfo class into package_manager
Priority: Normal » Major
Issue tags: +Project Browser Initiative
tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue summary: View changes
Status: Needs work » Needs review
Related issues: +#3307163: Add the ability to ProjectInfo handle projects not in the active codebase
traviscarden’s picture

traviscarden commented
Status: Needs review » Reviewed & tested by the community

Approved. 👍

  • tedbow committed 991088e on 8.x-2.x 
    Issue #3303902 by tedbow, phenaproxima, dww, TravisCarden: Move...
tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Status: Reviewed & tested by the community » Fixed

Thanks everyone!

Status: Fixed » Closed (fixed)

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

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue tags: +core-mvp