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.
If path-field is hidden in form display, in sidebar navigation it still displayed on node add/edit form.
Screenshot 2275463_field-enabled.png shows the node/add/page form as by default. After hiding the field in the default form display, the form is shown as 2275463_field-disabled.png. Notice the empty 'Url path settings' section. This patch fixes this issue, as shown in 2275463_field-disabled-patched.png.
Comment | File | Size | Author |
---|---|---|---|
#21 | 2275463-21.patch | 3.04 KB | SpadXIII |
#17 | 2275463-17-test-only.patch | 1.57 KB | SpadXIII |
#9 | 2275463_field-disabled-patched.png | 59.79 KB | SpadXIII |
#6 | 2275463_field-disabled.png | 62.24 KB | SpadXIII |
#6 | 2275463_field-enabled.png | 70.47 KB | SpadXIII |
Comments
Comment #1
andypostComment #2
SpadXIII CreditAttribution: SpadXIII commentedJust ran into this issue myself and made a small patch.
I looked at the node module and saw it was doing an isset($form['uid']) there, so I applied the same style of logic in the path module's form alter. It now only adds the details-fieldset if the field already exists in the form.
Comment #3
andypostComment #4
andypostComment #5
SpadXIII CreditAttribution: SpadXIII commentedI've written a test that, with a bit of help from chx. :)
It first asserts if the details-tag id and the field exist. Then removes the path alias field from the form display and checks again if they are gone.
Comment #6
SpadXIII CreditAttribution: SpadXIII commentedComment #7
SpadXIII CreditAttribution: SpadXIII commentedComment #8
SpadXIII CreditAttribution: SpadXIII commentedComment #9
SpadXIII CreditAttribution: SpadXIII commentedComment #10
filijonka CreditAttribution: filijonka commentedgreat work spadXIII, no problem this one.
Comment #11
alexpottThe test does not fail when the changes to core/modules/path/path.module are not applied.
Comment #12
SpadXIII CreditAttribution: SpadXIII commentedAlso added the test in a separate file for easier testing.
Comment #14
alexpottThanks @SpadXIII for proving me wrong!
Comment #15
alexpottSo thinking about this issue has led me to file #2378947: Hiding a field using form modes should not remove it from the form object - we should just be setting #access to whatever the path field has here (once that lands)
Lol so this is why I thought the test passed with the patch... I copy and paste this to run the test from the command line... and here we have a copy and paste error!
Comment #16
SpadXIII CreditAttribution: SpadXIII commentedIndeed a copy-paste error. Next to that, if a field is not removed from the form object but access-false, my patch won't fix anything. Will update tonight!
Comment #17
SpadXIII CreditAttribution: SpadXIII commentedChanged the module to account for the #access false, by doing an !empty() check.
Also fixed the file-comment :)
Comment #18
SpadXIII CreditAttribution: SpadXIII commented*note to self* don't forget to change status to needs review when adding new patches....
Comment #20
alexpottActually this condition should be done with a #access too... ie.
$form['path_settings']['#access'] = $node->hasField('path') && $node->get('path')->access('edit') && !empty($form['path']['#access']);
This means that your element can be altered by any other module without having to check it is there.
Comment #21
SpadXIII CreditAttribution: SpadXIII commentedI think I understood what you were saying, changed that in the patch. The fieldset is always added in the $form, with the if-statement for the #access.
I also changed the order of the checks; the cheaper empty-check first.
The test is unchanged.
Comment #22
SpadXIII CreditAttribution: SpadXIII commentedComment #23
chx CreditAttribution: chx commentedLooks good. Please post an interdiff next time.
Comment #24
alexpottRegardless of what happens in #2378947: Hiding a field using form modes should not remove it from the form object this looks good. This 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 821a9ce and pushed to 8.0.x. Thanks!