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.
While working on a patch for the Collections module, I could notice there's not currently a way to get the data that was passed to the override, e.g. the collection that was chosen in SPS.
Patch comming soon.
Comment | File | Size | Author |
---|---|---|---|
#1 | sps-access-to-override-data-2057223-1.patch | 5.3 KB | recidive |
Comments
Comment #1
recidive CreditAttribution: recidive commentedThis is useful for modules that want to do something with data, so they can call something like that and have access to the "conditions data" that was passed to the Override for generating overrides:
$override_data = sps_get_manager()->getSiteState()->getCondition()->getOverride()->getData();
Attached is a patch that adds a getData() method to the OverrideInterface and also does some cleanup on some Override implementations relying on an abstracted implementation of setData() and getData() methods.
Comment #2
indytechcook CreditAttribution: indytechcook commentedThis is interesting. I feel like there is an easier way to do this but I can't seem to remember how.
I"m changing the status to see if I can trigger the test bot.
Comment #3
indytechcook CreditAttribution: indytechcook commentedSetting back for testbot.
Comment #4
indytechcook CreditAttribution: indytechcook commentedI see you know what you are doing by this patch and the last one. I don't like pulling this data form the overrides though. The data property on the override is so inconsistent. For example, it could return an string as in the Collection Override or could be an array of overrides like the AggregatorOverride which is the default override you get at sps_get_manager()->getSiteState()->getCondition()->getOverride().
I agree that access to this data can be useful but I think it belongs in the condition and not the override. The override shouldn't really be relied upon to store anything non-mutable. By nature, overrides change information. That's the purpose of them.
I am in favor of putting something on the Drupal\sps\Plugins\Condition\WrapperCondition that returns what was set on the form. The object is already storing the form_state so it's accessible. This would probably be best delegated to the BasicCondition and do something similar to what submitElement() does in getting the values that will be passed to the override.