Problem/Motivation
Many hook_requirements implementations have dependencies that are not explicit, and are difficult to test due to a lack of dependency injection.
These issues provided OOP replacements for the procedural hook_requirements():
- #3490841: Create hook_runtime_requirements() and hook_runtime_requirements_alter()
- #3490842: Create hook_update_requirements() and hook_update_requirements_alter()
- #3490843: Create class to replace hook_requirements('install')
This plan is for converting all of core to use these OOP replacements.
Steps to reproduce
N/A
Proposed resolution
See child issues for each part of the plan.
Remaining tasks
Already converted
- file
Runtime phase only
#3500632: Convert hook_requirements() that do not interact with install time
- image
- jsonapi
- locale
- mysql
- navigation
- node
- search
- update_test_schema
- update
- user
- demo_umami
Update phase only
#3500632: Convert hook_requirements() that do not interact with install time
- update_script_test
Includes install phase
#3513410: Convert hook_requirements() that do interact with install time that are not system
- layout_discovery
- media
- package_manager
- pgsql
- requirements1_test
- workspaces
- testing_requirements
Experimental Module Requirements Test
- experimental_module_requirements_test #3513879: Convert experimental_module_requirements_test_requirements to new Class
mysqli
System
User interface changes
N/A
Introduced terminology
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
Comments
Comment #2
nicxvan commentedComment #3
nicxvan commentedComment #4
dwwFor 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()?hook_runtime_requirements()hook_update_requirements()hook_install_requirements()classI 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. ;)Comment #5
dwwOpened #3493718: Convert system_requirements() into OOP hooks and install time class to track it. Adding to summary.
Comment #6
nicxvan commentedYeah that split was my real plan, glad to see some momentum here!
Comment #7
nicxvan commentedI 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 #3490843: Create class to replace hook_requirements('install')
Comment #8
nicxvan commentedComment #9
nicxvan commentedComment #10
nicxvan commentedThere is literally one implementation in core that only interacts with update, we should just convert all requirements unless they interact with install.
Comment #11
nicxvan commentedComment #12
nicxvan commentedComment #13
nicxvan commentedComment #14
nicxvan commentedComment #15
nicxvan commentedComment #16
dwwRemoving duplicate related issue
Comment #17
nicxvan commentedComment #18
nicxvan commentedComment #19
dwwThese are now committed to 11.x:
#3500632: Convert hook_requirements() that do not interact with install time
#3513410: Convert hook_requirements() that do interact with install time that are not system
That leaves these as the only blockers to #3490846: Deprecate hook_requirements, right?
#3513879: Convert experimental_module_requirements_test_requirements to new Class (trivial and RTBC)
#3493718: Convert system_requirements() into OOP hooks and install time class (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. 😉
Comment #20
dwwMinor edits to the summary to reflect reality, and converting this meta into a plan.
Comment #21
dwwComment #22
nicxvan commentedI'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.
Comment #23
dwwIs 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. 😉
Comment #24
nicxvan commentedComment #25
nicxvan commentedWell it turns out system_requirements got in first!
Here is the meta you asked about: #3504381: [meta] Convert Template Preprocess hooks to OOP equivalent
All hook_requirements in core are converted, I'm going to wrap this!
Thanks!
Comment #26
xjmGo team!