[pp-3] Convert hook_requirements to new classes or hook_runtime_requirements

For scope, wondering if we really need separate issues for all of these. E.g. the one for update (status) will be a simple move to an OOP hook_runtime_requirements(). Maybe we should group by all modules that only implement a single phase in their hook_requirements()?

• Only needs hook_runtime_requirements()
• Only needs hook_update_requirements()
• Only needs the hook_install_requirements() class
• Separate issues for each module that implements more than 1 phase

I can't wait to see system_requirements() refactored. That's going to help so much. I might even be inspired to raise my hand to at least start on that one. ;)

Opened 📌 [pp-3] Split up and refactor system_requirements() into OOP hooks Active to track it. Adding to summary.

Yeah that split was my real plan, glad to see some momentum here!

I think this is no longer postponed, but we should only create three children for now.

1. Convert all hook_requirements that only interact with phase update
2. Convert all hook_requirements that only interact with phase runtime
3. Convert hook_requirements that interact with both runtime and update if any.

Discuss here any that interact with install in any way. Discuss whether we convert those phases or wait on 📌 Create class to replace hook_install_requirements Active

There is literally one implementation in core that only interacts with update, we should just convert all requirements unless they interact with install.

Removing duplicate related issue

These are now committed to 11.x:
📌 Convert hook requirements that do not interact with install time Active
📌 Convert hook_requirements that do interact with install time that are not system Active

That leaves these as the only blockers to 📌 [pp-many] Deprecate hook_requirements Postponed , right?

📌 Convert experimental_module_requirements_test_requirements to new Class Active (trivial and RTBC)
📌 [pp-3] Split up and refactor system_requirements() into OOP hooks Active (massive and NW)

Wonder if it's possible to finish #3493718 in time for 11.2.0-beta, which would allow us to deprecate hook_requirements() still in 11.2.0 for removal in 12. Otherwise, I think that'd be a disruptive enough change that it'd be a 11.3.x deprecation for removal in 13...

Thanks,
-Derek

p.s. Also wonder why we're marking child issues as related. 😉

Minor edits to the summary to reflect reality, and converting this meta into a plan.

Also wonder why we're marking child issues as related.

I've never been super clear on the difference so I usually default to related.

As for system_requirements, I'd love to get that in, but it's massive, and I feel like the template preprocess conversions will be easier to get in.

Is there a meta or plan for template preprocess conversions? I haven't been following those. Happy to try to help if I can.

Re: child vs. related, there's no hard/fast rule. But generally, if something is a "follow-up" that'd be a child issue. Especially for meta/plan issues, all the steps in the plan should be child issues. Related is for exactly that: related. It's not directly a "descendent" or "ancestor" of the issue, but it's somehow relevant to also consider for whatever reason(s).

For this plan, removing all the related issues that are already children so they're not listed twice. The remaining two are "siblings" of this issue (other children of the same parent). 🤓 But for better visibility, might as well leave those. 😉

Well it turns out system_requirements got in first!

Here is the meta you asked about: 📌 [pp-1] Convert Template Preprocess hooks to OOP equivalent Postponed: needs info

All hook_requirements in core are converted, I'm going to wrap this!

Thanks!

Go team!