Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
API page: http://api.drupal.org/api/drupal/modules%21system%21system.api.php/funct...
Return value
A keyed array of requirements. Each requirement is itself an array with the following items:
A keyed array, but keyed by what?
Comment | File | Size | Author |
---|---|---|---|
#8 | hook_requirements_documentation-1933954-8.patch | 829 bytes | toastieAlex |
#6 | hook_requirments_documentation-1933954-6.patch | 960 bytes | toastieAlex |
#2 | hook_requirements_description-1933954-2.patch | 731 bytes | toastieAlex |
Comments
Comment #1
jhodgdonI looked through all the invocations of this hook, and it looks like the array keys are arbitrary but must be unique across modules. This should be added to the documentation of the return value. Thanks for reporting this!
Comment #2
toastieAlex CreditAttribution: toastieAlex commentedI believe this reflects the intended key value for requirements.
Comment #3
joachim CreditAttribution: joachim commentedThanks for working on this!
That's not quite it, I'm afraid, as you might need to return more than one requirement in your module. Though it's certainly a good idea to prefix the key with the module name, to ensure uniqueness.
Comment #4
toastieAlex CreditAttribution: toastieAlex commented@joachim, I agree that it's not quite it, but the more I read the code that processes
requirements
the more it looks like it just doesn't matter what the key is. As near as I can tell it's there to separate therequirements
from one another, but otherwiseinstall_verify_requirements
andupdate_verify_requirements
do not use the key.I will post a new patch within 24 hours of the first one.
Comment #5
joachim CreditAttribution: joachim commented> it just doesn't matter what the key is. As near as I can tell it's there to separate the requirements from one another,
Yes, that's absolutely right! The key does not matter, but it has to be unique. Therefore, the best strategy is to prefix with MODULE_NAME and then add something descriptive, eg, mymodule_javascriptenabled, to make up a rubbish example :)
Comment #6
toastieAlex CreditAttribution: toastieAlex commentedExpanded description of the requirements array key.
Comment #7
jhodgdonWe normally say "associative array" rather than "keyed array" in documentation, and refer to the array values as "values"... and I think this wording can be made a lot more concise and clear, and maybe we don't need to be quite so prescriptive about how to compose the names... how about something like:
An associative array where the keys are arbitrary but must be unique (it is suggested to use the module short name as a prefix) and the values are themselves associative arrays with the following elements:
Comment #8
toastieAlex CreditAttribution: toastieAlex commented@jhodgdon, works for me, although as an old perl hacker I'd normally say hash instead of associative array.
Comment #9
jhodgdonYeah, well PHP isn't Perl (which has a different data type for hashes and arrays). :) I'll get this committed when I can. Thanks!
Comment #10
jhodgdonI'm going to wait on committing this until this "avoid commit conflicts" issue that touches system.api.php too is finished:
#1380720: Rename entity "bundle" to "subtype" in the UI text and help
Comment #11
xjm#8: hook_requirements_documentation-1933954-8.patch queued for re-testing.
Comment #13
xjm#8: hook_requirements_documentation-1933954-8.patch queued for re-testing.
Comment #14
xjmComment #15
jhodgdonThanks! Committed to 8.x and 7.x.