- Issue created by @nicxvan
- πΊπΈUnited States dww
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 theirhook_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. ;) - Only needs
- πΊπΈUnited States dww
Opened π [pp-3] Split up and refactor system_requirements() into OOP hooks Active to track it. Adding to summary.
- πΊπΈUnited States nicxvan
Yeah that split was my real plan, glad to see some momentum here!
- πΊπΈUnited States nicxvan
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
- πΊπΈUnited States nicxvan
There is literally one implementation in core that only interacts with update, we should just convert all requirements unless they interact with install.
- πΊπΈUnited States dww
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 ActiveThat 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,
-Derekp.s. Also wonder why we're marking child issues as related. π
- πΊπΈUnited States dww
Minor edits to the summary to reflect reality, and converting this meta into a plan.
- πΊπΈUnited States nicxvan
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.
- πΊπΈUnited States dww
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. π
- πΊπΈUnited States nicxvan
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!