The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Right now, if Package Manager is available and UI install is enabled, Project Browser will always validate the current system state on every Project Browser page. This is both wasteful and too much of a sledgehammer; for example, when viewing local recipes, you don't need Package Manager at all.
Proposed resolution
This is a really dirty hack, but for now, in \Drupal\project_browser\Element\ProjectBrowser::getDrupalSettings(), we should skip doing the Package Manager install readiness checks if $source === 'recipes'.
In another issue, we should do a more detailed and permanent fix, which is that the readiness checks should only ever be done for projects whose activation status is ActivationStatus::Absent. Package Manager is not relevant in any other circumstance.
Issue fork project_browser-3494506
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:
changes
Comments
Comment #4
shalini_jha commentedI have attempted to add a check to skip the Package Manager install readiness checks specifically for recipes. However, I am unsure if this is causing the Nightwatch failure
Comment #5
shalini_jha commentedI believe this failure is not related to the changes I made. I am moving this for review. Please take a look and let me know if this aligns with the expectations of the ticket or if any updates are required.
Comment #6
phenaproximaThe Nightwatch failures are preexisting; not your fault.
I think that doing a skip if the source is
recipesis a completely legitimate workaround.I kind of wonder, though, if it would be relatively easy to move the install readiness checks to
\Drupal\project_browser\Controller\InstallerController::begin(). Because that is the only time Package Manager will ever be invoked. The only thing the Svelte app would need to know is whether Package Manager is present at all. It wouldn't have to care about the validation results or anything like that.Maybe we can try the deeper fix in another branch of this issue fork, and then commit the quick fix if it turns out to be a bugaboo? Or, hell, we could commit the quick fix but keep this issue open and work on the deeper fix in another branch.
In either case, though, this branch needs to be synced against 2.0.x HEAD due to merge conflicts. :(
Comment #7
shalini_jha commented@phenaproxima Thank you for the review & feedback. i am fixing this conflict issue till then.
Comment #8
shalini_jha commentedFixed merge conflict , as mentioned in #6 not moving this ticket.
Comment #10
narendrarRe #6, The problem with moving the install readiness checks to
\Drupal\project_browser\Controller\InstallerController::begin()is:sveltejs/src/Project/ActionButton.svelteuses this value to work/display the button based on errors or warnings.Comment #11
phenaproximaThanks for looking into that, @narendrar. If that's the case, let's proceed with the quick-fix for now but open a follow-up (linked in a comment above the fix) to improve this.
Comment #12
narendrarComment #13
phenaproximaA fine workaround, in my opinion; ship it.
Comment #16
chrisfromredfinThanks Naren for bringing up those points, which are important. So, this is a good workaround for now in order to get Drupal CMS out the door.