Create StageBase::stageDirectoryExists() for improved DX to see if stage directory exists.

OMG! This means that the documentation that was just committed in 📌 Update Package Manager event documentation in package_manager.api.php Fixed for StatusCheckEvent was wildly wrong, and neither @kunal.sachdev nor I knew, and @phenaproxima didn't notice!

This is what we added there:

 * \Drupal\package_manager\Event\StatusCheckEvent
 * Dispatched to check the status of the Drupal site and whether Package Manager
 * can function properly. These checks can be performed anytime, so this event
 * may be dispatched multiple times.

It's completely unrelated to the status of the Drupal site, it's completely unrelated to the status report, it is related to the stage life cycle even though I repeatedly told @kunal.sachdev it's not! 😳😬

I'll fix that as part of 📌 Define the Package Manager API (package_manager.api.php is outdated) Fixed then…

I guarantee that without a helper method on StatusCheckEvent and an improved class docblock, this will be implemented incorrectly by most consumers of this API.

* Dispatched to check the status of the Drupal site and whether Package Manager
* can function properly. These checks can be performed anytime, so this event
* may be dispatched multiple times.

Uh...this is all accurate. It's a little vague, but accurate. Status checks are meant to check that Package Manager can function properly given the current conditions of the Drupal site.

How is that wildly wrong? I agree it wouldn't hurt to add some specifics, but I don't see what's wrong about that paragraph.

status of the Drupal site and whether Package Manager
* can function properly.

The status of the Drupal is related to whether "Package Manager can function properly". You can't assess whether Package manager will work correctly without checking out certain stuff about the Drupal site. For example, is the code base writable, are there pending DB updates, is update_fetch_with_http_fallback set to the correct value?

Those are all checks that relate to the status of the Drupal site. But also what is not clear is that they can be used to check the status of the stage itself. Right now we use this less often, I would say most of our checks should be caught at PreCreate, and we implemented PreApply because it can't hurt and the status of the site might have changed.

I re-checked #2 again while working on 📌 Define the Package Manager API (package_manager.api.php is outdated) Fixed .

StatusCheckEvent is only dispatched in StatusCheckTrait and in ComposerPatchesValidatorTest.
StatusCheckTrait is only used in tests, and by the Automatic Updates and Project Browser modules — so in Package Manager it's used only by tests: StatusChecker is owned by Automatic Updates, not by Package Manager.

So the documentation added in 📌 Update Package Manager event documentation in package_manager.api.php Fixed was correct after all.

It's just that some validators react to both PreCreateEvent/PreApplyEvent (to interact with the stage life cycle) on the one hand and StatusCheckEvent (to be able to generate a status report) on the other. The only exception to this rule appears to be \Drupal\automatic_updates_extensions\Validator\UpdateReleaseValidator.

See #3318306-26: Define the Package Manager API (package_manager.api.php is outdated) → .

\Drupal\package_manager\Validator\SymlinkValidator::validate and \Drupal\package_manager\Validator\StagedDBUpdateValidator::checkForStagedDatabaseUpdates both still call

try {
      $stage_dir = $event->stage->getStageDirectory();
    }
    catch (\LogicException) {
      // Stage directory can't be determined, so there's nothing to validate.
      return;
    }

But they both aren't only dealing with StatusCheckEvent
So I think the Stage::hasStagedUpdate() would still be good.

Looks good 👍 , needs work for some doc nits and one suggestion where this new method could be used.

I think we could make this a little clearer. To that effect, we could also re-title this issue and rewrite the issue summary.

Also, this will need explicit test coverage before we can commit it.

I expect an update to package_manager.api.php for the tag 😊

Once that's done, I will RTBC!

Agreed. Looks great to me. Just needs a little docs update.

Updated doc + left two comments which need attention.

New issue for the problems @omkar.podey spotted (👏): 📌 StageBase documentation in package_manager.api.php is incomplete Fixed .

Did a small rephrase, but otherwise this looks great. +1 RTBC, will commit when tests pass.

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