Problem/Motivation
I'm porting a module to D8, leveraging the ThirdPartySettings goodness on config entities. Un fortunately there is no way to retrieve all third party settings a module has stored. There is only a method to get a single setting, but you have to know its key.
Proposed resolution
Add a method to get all third party settings stored by a module.
In the future, modules may even want to retrieve all third party settings, regardless of the module that stored it. While we're at it, we can make that possible too.
Remaining tasks
I'm adding a first patch, but there are some details I'm not sure about, mainly because I wonder what is most consistent with the rest of Drupal core, and OOPHP at large. ToDo:
- Decide on the method name: donegetAllThirdPartySettings
(does not start with "getThirdParty..." like the others) / getThirdPartySettings
(only 1 charachter difference from "getThirdPartySetting") / getThirdPartySettingsByModule
(makes less sense if we allow $module to be empty)
- Decide if we also want to add a way to retrieve all third party settings, not filtered by module. done
- If yes, decide if that should be a separate method or simply the return value if the module name argument is empty. n/a
- Tests done
User interface changes
none
API changes
Addition of one method.
Comment | File | Size | Author |
---|---|---|---|
#9 | third_party_settings_get_all-2345879-8.patch | 2.19 KB | marcvangend |
#9 | interdiff-2345879-6-8.txt | 893 bytes | marcvangend |
Comments
Comment #1
marcvangendPatch attached.
Comment #2
Gábor HojtsyYeah I think this was an oversight that we don't have this method. Needs unit tests for the new method like the old ones have. Also:
Not true if the module name was empty.
Do we say on other comments that this deals with a config entity? I think it was meant to be a very generic trait.
Comment #3
yched CreditAttribution: yched commentedDo we really want to support that case ?
Comment #4
marcvangendRe #2:
You're right. That's a good reason to separate the get-all-settings-of-all-modules method from the get-all-settings-of-one-module method (if we want the latter at all).
Good point. The inline docs for the $third_party_settings property does say "Third party entity settings", but there are no explicit references to config entities. I'll remove it.
Re #3:
I don't know, that's why that decision is one of the remaining tasks. I couldn't think of a good use case, but that doesn't prove anything. If we do not support that use case, one could still loop over the result of getThirdPartyProviders() and call getAllThirdPartySettings($module) multiple times.
Comment #5
yched CreditAttribution: yched commentedYes. The "third-party settings" API is oriented towards "by module", so I'd vote for just getThirdPartySettings($module != NULL), and keep leave hypothetical / weird uses of "get all settings across all modules" resort to the above.
Comment #6
marcvangendThanks Yves. How does this look?
Comment #7
marcvangendComment #8
yched CreditAttribution: yched commentedNitpick :
Phrasing could probably be enhanced.
Other than that, looks ready to go :-)
Comment #9
marcvangendFollowing up on suggestions by yched, this patch improves the wording of the inline docblock and uses a ternary if-statement.
Comment #10
yched CreditAttribution: yched commentedThanks !
Comment #11
alexpottCommitted 15cc5bd and pushed to 8.0.x. Thanks!
Comment #14
swentel CreditAttribution: swentel commentedThe interface is missing the new method, needs a follow up issue.
Comment #15
swentel CreditAttribution: swentel commentedFollow up at #2367661: Follow up: ThirdPartySettingsTraitInterface missing getThirdPartySettings() method