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.
Create a Boolean field on the Page content type, with name "field_test".
Then go to admin/structure/types/manage/page/fields/node.page.field_test/storage (which is the "Edit storage" page for that field).
You will see the on/off labels shown on this screen. But this page says "These settings impact the way that data is stored in the database and cannot be changed once data has been created."
Um. I don't think so? How are the on/off labels database storage settings? These need to be moved to the ordinary field settings that you can edit later.
Issue category | Bug because you should be able to change labels regardless of whether or not there is content in the database |
---|---|
Issue priority | Major because this doen't allow for boolean labels to be changed after content has been added. |
Prioritized changes | The main goal of this issue is fixing a bug. |
Comment | File | Size | Author |
---|---|---|---|
#38 | 2434745-38-complete.patch | 8.35 KB | geertvd |
#38 | interdiff.txt | 773 bytes | geertvd |
#31 | 2434745-31-test.patch | 1.02 KB | geertvd |
#15 | field_settings_boolean.png | 105.3 KB | geertvd |
Comments
Comment #1
geertvd CreditAttribution: geertvd commentedSeems weird indeed, fix is pretty easy.
This should probably break some tests.
Comment #2
geertvd CreditAttribution: geertvd commentedWoops forgot to add the patch
Comment #3
geertvd CreditAttribution: geertvd commentedThis should take care of the breaking tests
Comment #6
geertvd CreditAttribution: geertvd commentedComment #7
geertvd CreditAttribution: geertvd commentedComment #9
geertvd CreditAttribution: geertvd commentedComment #10
geertvd CreditAttribution: geertvd commentedComment #11
geertvd CreditAttribution: geertvd commentedComment #13
geertvd CreditAttribution: geertvd commentedShould we still write extra tests for this? I guess we could create a boolean field, add some content and then try to change the on/off labels or is that unnecessary?
Comment #14
jhodgdonIt looks like you already had to update several tests in your patch, so the functionality of "change on/off text settings" looks like it's been adequately tested.
A screen shot of this working might be good. :)
Comment #15
geertvd CreditAttribution: geertvd commentedJust added a screenshot of the settings page.
Comment #16
jhodgdonLooks good!
- I tried this out on simplytest.me. I added a Boolean field to the Article content type of the standard profile. Checked the Manage Form Display page and Manage Display. Created some content and looked at the form and the output. It is all working fine. @geertvd also added a screen shot.
- Since this patch had to revise tests, I think the functionality has been adequately tested.
- The code in the patch looks good. I grepped for "off_label" in Core (on_label gave me a bunch of button_label hits, oof!) and it looks like the patch is covering most everything... but there were a few missed, which is a concern:
And in addition to the two spots that were fixed in core/lib/Drupal/Core/Field/Plugin/Field/FieldType/BooleanItem.php there were two other spots that were not touched.
So can you explain why these 3 places in the Core code do not need to also change? I think they might... happy to be wrong but I think they at least need an explanation.
We'll also need to add a Beta Evaluation to the issue summary.
Comment #17
geertvd CreditAttribution: geertvd commentedI think
$this->getFieldSetting('on_label')
doesn't care whether this is a setting on field storage or on the field instance.It just points to
$this->fieldDefinition->getSetting($setting_name);
which just returns any field setting.The 2 other spots in core/lib/Drupal/Core/Field/Plugin/Field/FieldType/BooleanItem.php, i'm assuming you're talking about
This is the same explanation as above.
I don't know if that answers your question?
added Beta Evaluation
Comment #18
geertvd CreditAttribution: geertvd commentedComment #19
jhodgdonAh, you're right. Thanks for increasing my knowledge of the Field API. I took a closer look at those 3 spots and I agree with your analysis. I think this is ready to go -- great work!
Comment #20
amateescu CreditAttribution: amateescu commentedThis part of config schema seems to be unnecessary now because there are no storage settings to save in config.
Comment #21
geertvd CreditAttribution: geertvd commentedRemoved that bit.
Comment #22
geertvd CreditAttribution: geertvd commentedComment #23
amateescu CreditAttribution: amateescu commentedAwesome! Let's hope the testbot agrees :)
Comment #24
tstoecklerPatch size is a bit big for my taste ;-)
(And it reverts the latest core commits...)
Comment #25
tstoecklerAlso, since we are already changing this, why don't we move this to a widget setting directly? The boolean formatter recently gained the ability to configure the labels so it's really only relevant for widgets. That would also solve #2428087: Boolean field formatter - default choice appears in list twice more elegantly and also the weird UX fail that of the two labels you currently have to enter in the field settings only one is ever used with the CheckboxWidget and it's not inherently obvious which one.
Thoughts?
Comment #26
geertvd CreditAttribution: geertvd commentedwoops :)
Comment #27
geertvd CreditAttribution: geertvd commented#25 Sounds like the right approach, I'll look into to this tomorrow.
Comment #28
geertvd CreditAttribution: geertvd commentedComment #29
jhodgdonRE #25 - no. It cannot be a widget setting, because it is used in more than just the widget. The formatter also looks at this field setting, because one of its options is to display with the field settings strings. Also there is a method on the field class called getOptions(), or something like that, which returns options that can be used for a Select or Radios widget, and that also needs something to return (which should be settable by the user and therefore needs to be on the field settings).
So. The approach here is correct. Do not move this setting to the widget.
The patch in #25 looks good. No extra pieces. It looks like the patch I approved in #11 with the changes suggested/approved by amateescu.
Comment #30
webchickNice catch.
Only issue is I don't believe I see any explicit test for the STR in the issue summary? (All the test hunks seem to simply be updating based on the changes this patch introduces.) Would be really nice to not ever break this again.
Comment #31
geertvd CreditAttribution: geertvd commentedThis tests if we can change the label after creating content.
Comment #32
geertvd CreditAttribution: geertvd commentedComment #35
geertvd CreditAttribution: geertvd commentedComplete patch in #31 failed because some new boolean tests were added in
BooleanFormatterSettingsTest.php
Comment #36
geertvd CreditAttribution: geertvd commentedComment #38
geertvd CreditAttribution: geertvd commentedComment #39
jhodgdonThe latest patch looks good to me, and to the testbot. The new test appears to be sufficient to test the new functionality. Thanks again!
Comment #40
catchCommitted/pushed to 8.0.x, thanks!
Retrospectively tagging 'D8 upgrade path'.