Move REQUIREMENT_* constants out of install.inc file

Created on 17 September 2017, over 7 years ago
Updated 20 March 2023, over 1 year ago

Problem/Motivation

Follow-up to πŸ“Œ Warn site admins when composer dev dependencies are installed inside of docroot Needs work where we have a test that is a kernel test only because KernelTestBase makes REQUIREMENT_OK available to the system under test.

Let's move the REQUIREMENT_* family of constants to a loadable namespace.

@alexpott on #50 said:

I feel this is OO-ification for OO-ification's sake. We're only moving the constants so they can be autoloaded. But a proper redesign of the requirements system might end up with Requirement value objects that makes these constants redundant - imagine $requirement->isError() etc...

If what we want to solve autoloadability of constants there's another way. We could add core/constants.php to our autoloader in the files section and repeating myself from the other issue the advantages are

  • there's no deprecation
  • the constants become available to autoloaded code
  • as constants.php grows it becomes a place to learn about all the core provided constants

The one downside is this approach is only available to core and not core modules/themes, or contrib or custom because they don't using composer to set up their autoloading. But I'm not sure that outweighs the advantages listed.

Proposed resolution

TBD.

Remaining tasks

Make a patch, or decide this is a Won't Fix.

User interface changes

API changes

Data model changes

πŸ“Œ Task
Status

Needs work

Version

10.1 ✨

Component
InstallΒ  β†’

Last updated 3 days ago

No maintainer
Created by

πŸ‡ΊπŸ‡ΈUnited States mile23 Seattle, WA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡«πŸ‡·France andypost

    Nowadays idea of discovery Requirement objects could use attributes to define title, value and description.
    Other similar kind of checks/tasks install system has, so approach from #50 sounds viable

    +++ b/core/lib/Drupal/Core/Render/Element/StatusReport.php
    @@ -35,13 +37,13 @@ public static function preRenderGroupRequirements($element) {
         $severities = static::getSeverities();
    ...
    -      $severity = $severities[REQUIREMENT_INFO];
    +      $severity = $severities[Requirements::SEVERITY_INFO];
    ...
    -        $severity = $severities[REQUIREMENT_OK];
    +        $severity = $severities[Requirements::SEVERITY_OK];
    ...
           $grouped_requirements[$severity['status']]['title'] = $severity['title'];
    
    +++ b/core/lib/Drupal/Core/Requirements.php
    @@ -0,0 +1,30 @@
    +final class Requirements {
    

    it could be enum but it actually used only to group requirements

  • πŸ‡ΊπŸ‡¦Ukraine voleger Ukraine, Rivne

    Seems like we have an issue that already has some work done in that way πŸ“Œ Add value objects to represent the return of hook_requirements Needs review

  • πŸ‡«πŸ‡·France andypost

    Looks yep!

Production build 0.71.5 2024