Contrib.social

Move REQUIREMENT_* constants out of install.inc file

Open on Drupal.org →
Created on 17 September 2017, almost 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 about 15 hours 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.

  • Comment over 1 year ago →
    🇫🇷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

  • Comment over 1 year ago →
    🇺🇦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

  • Comment over 1 year ago →
    🇫🇷France andypost

    Looks yep!

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024