Package Manager validation is only necessary if the project to install is not already in the filesystem

Bumping this to critical. In my testing, the 'Recommend' page in project browser spent 16 seconds just on this method, which makes it almost unusable - could potentially go past server timeouts on some setups.

You tested with alpha6, didn'tcha. ;)

In 2.0.x HEAD, which will soon be alpha7, we have a workaround for the Recipes (a.k.a "Recommended") tab which skips the Package Manager check: https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/src/Elem...

So, de-escalating this issue for now. I certainly think it should block a stable release of Project Browser, though.

kunal.sachdev → made their first commit to this issue’s fork.

What is the status on this issue? I see MR, but issue status is "Active".

This weekend (25-26 Jan), I am organizing a contribution weekend in Tbilisi and I am looking for issues to select to work on. If we can contribute here (review, test or code), we would be happy.

This is in progress, @kunal.sachdev is actively working on it. :)

Manually tested this at @kunal.sachdev's request.

What I found is that the performance problem is definitely solved -- the modules page loads immediately!

There is one major problem, which is that if max_selections is NULL (the default), and you start selecting projects to install, the bulk actions bar at the bottom of the page doesn't show up. That needs to be fixed, and we need a regression test added for that. I was able to work around it by setting max_selections to 1 globally.

I then created sites.php with some fake sites listed in it, to pretend I'm in a multisite, which Package Manager doesn't support. I went to the browse list and tried to install Metatag, and it failed exactly as expected with an error from that validator. Screenshot:

One thing we need to do, I think, is ensure the list of errors (and warnings) is formatted as HTML. If we just separate them by new lines, they all run together when you display them as HTML. So maybe format them as a ul.

Leslie reminded me today that if Package Manager validation fails at the page-load, we default to showing "View Commands" instead of "Install" or "Select."

If we move the readiness check to the beginning of install, that does push off when the error is being reported to the user. I think that's fine, BUT, if we then cache the PM validation check in some way, we'd be able to switch back to the 'View Commands' fallback. Is there any intention to handle this? It's kind of a nice feature now that we may lose... ?

I'm not sure that caching error conditions is a good idea at all. It's one thing in automatic updates, which is meant to operate continuously in the background, but Project Browser is entirely on-demand, and conditions could change quickly.

Regarding the comment #11 🐛 Package Manager validation is only necessary if the project to install is not already in the filesystem Active , I believe we already have a test for the 'selecting projects and install' scenario \Drupal\Tests\project_browser\FunctionalJavascript\ProjectBrowserInstallerUiTest::testMultipleModuleAddAndInstall , which was failing but is fixed now. So I don't think we need more tests.

Needs a rebase now that 📌 Refactor the Search component to treat filter changes generically Active is in.

Regarding #12, I like the idea of dynamically falling back to View Commands if there's an error at the server side.

That might be a fairly substantial change to the Svelte code, though, so probably best done in a follow-up.

Opened ✨ If Package Manager validation fails, fall back to "View Commands" Active to discuss what we should do if there is a validation failure.

Tentatively RTBCing it; I didn't make any substantive changes to the patch. I had previously manually tested it in #11 and I have no reason to believe the current changes have broken anything.

ship it real good

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