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.
Updated: Comment #0
Problem/Motivation
Vertical tabs currently save things such as visibility__active_tab
as form values, which corresponds to open tab when pressing the save button. This is semantically wrong and can cause problems when we iterate over all form values to save them, such as in settings_form for example.
Proposed resolution
Add $form_state->valuesCleanKeys. Any values added to that array will be unset by form_state_values_clean(). Update vertical tabs to set it's items to be cleaned using this.
Remaining tasks
Review
User interface changes
None
API changes
Adds $form_state->valuesCleanKeys. Any values added to that array will be unset by form_state_values_clean().
Comment | File | Size | Author |
---|---|---|---|
#44 | drupal-1805254-2-D7_44.patch | 1.14 KB | frankcarey |
#7 | drupal-1805254-2-D7.patch | 1.14 KB | frankcarey |
Comments
Comment #1
tstoecklerComment #2
webchick+1, this is probably a better approach. :)
Comment #3
XanoNot to sound ignorant, but why would we ever want to iterate over form values and save those? We should be iterating over what we know can be saved, and then get the values from the submitted form data instead, so things don't break like they do here, or when people alter forms to add new elements.
Comment #4
markhalliwellClosed these related issues as duplicates of this one.
Comment #5
markhalliwellForgot tag
Comment #6
frankcarey CreditAttribution: frankcarey commentedThis is a patch (for D7) which adds $form_state['values_clean']. Any values added to that array will be unset by form_state_values_clean(). Seems like a clean and intuitive way to do it instead of creating another element just for vertical tabs. I wonder if the button logic could be greatly simplified as well in form_state_values_clean() using this technique? Looking for feedback on this approach before I port to D8.
To be clearer about the issue, the results of this bug is that **__active_tab variables show up in the variables tables and can cause features that export them to be considered overridden unnecessarily. They aren't even used when you return to a page or anything. This most likely happens on settings_form forms since they blindly save all values as variables. (< @Xano this is why it's an issue.)
Comment #7
frankcarey CreditAttribution: frankcarey commentedComment #8
frankcarey CreditAttribution: frankcarey commentedComment #10
markhalliwellUntil the version field is switched to 7.x, this patch will fail testing. Hiding the file for now, 8.0.x will need to be fixed first regardless.
Comment #11
frankcarey CreditAttribution: frankcarey commentedRoger, porting the D7 patch to D8 now while I have it in my head.
Comment #12
frankcarey CreditAttribution: frankcarey commentedHere is the D8 patch which does things very similarly. I searched around for the special code that was added in #2035725: Remove visibility__active_tab from block.schema.yml but it looks like it was refactored out in commit 1228438e65d [1228438e65d].
Comment #14
frankcarey CreditAttribution: frankcarey commentedOops, can use 'string' for php type-hinting.
Comment #15
markhalliwellAwesome, this looks good to me. Just setting to CNW since this will also need additional tests (may already have some similar existing ones somewhere).
Comment #16
tim.plunkettSome of the old property names are snake_case due to since-removed ArrayAccess, but all new properties should be lowerCamelCase
These aren't the values themselves, they're the keys.
missing a space
Comment #17
frankcarey CreditAttribution: frankcarey commentedCool, here it is with tests and tim's suggested fixes. Names now are like addCleanValueKey() instead of addCleanValue().
Comment #18
frankcarey CreditAttribution: frankcarey commentedI assume we should add the new methods to FormStateInterface as well? Here is a patch that adds that. FYI, I think this would actually be my first core-commit ..kinda long overdue :P
Comment #19
frankcarey CreditAttribution: frankcarey commentedMore functional tests, including for vertical tabs itself.
Comment #20
frankcarey CreditAttribution: frankcarey commentedComment #21
idebr CreditAttribution: idebr commentedI think this should be
@param string $key
Suggestion: The form value key to be cleaned.
Comment #22
tim.plunkettThis is really close!
Here, and elsewhere, please use [] instead of array()
Might as well flip the order of these, to match the order in FormState.
@return array
@param string $key
@return $this
Here, and elsewhere, use String::format() instead of format_string()
Please split these into four test methods, one for each @covers
Consider using @depends to build from one method to the next.
new FormState()
Also, please include interdiffs when making changes between patches. Thanks!
Comment #23
idebr CreditAttribution: idebr commentedI believe the feedback in #22 means this issue needs work :)
Comment #24
frankcarey CreditAttribution: frankcarey commentedHuh, I thought I'd updated this :/ I have all the fixes and just needed to upload the diffs I think.. @todo
Comment #25
frankcarey CreditAttribution: frankcarey commentedHere are the files w/ the interdiff
Comment #27
tim.plunkettSorry, I wasn't specific about the String::format thing, fixing for you just to get this done.
As that's my only contribution here, I feel comfortable RTBCing this.
Thanks @frankcarey!
Comment #28
markhalliwellMinor nit pick, but shouldn't the manual unset that was introduced in #2035725: Remove visibility__active_tab from block.schema.yml be removed here since it's already removed from the array by this patch?
This patch:
From other issue (which has the @todo this patch fixes):
Comment #29
tim.plunkettThat hack was removed in #2278541: Refactor block visibility to use condition plugins.
Comment #30
alexpottThis is a bug.
Comment #32
tim.plunkettYay, the automated @covers checker works!
Comment #33
alexpottThis issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed 1218fdf and pushed to 8.0.x. Thanks!
Comment #37
markhalliwellAwesome :)
@frankcarey, I've re-queued #7, but figured you may want to revisit the 7.x patch so it's a little more inline with the final patch that got into 8.x?
Comment #43
frankcarey CreditAttribution: frankcarey as a volunteer and at DEVINCI commentedComment #44
frankcarey CreditAttribution: frankcarey as a volunteer and at DEVINCI commentedRe uploading the same D7 patch to try to get tests running for it again (old one doesn't seem to work anymore)