Problem/Motivation
The calculated machine is not synced when the source value is defined and the machine name is empty.
Steps to reproduce
- Enable the
form_test testing module.
- Visit
/form-test/machine-name in your browser.
- Check the third text field on the page which is labelled "Machine name 3 label". This machine_name+textfield pair has render arrays similar to those shown below where the textfield has a default value, but the machine_name does not. Notice how the machine is set and correct.
- Change the title and machine name is not updated.
$form['id'] = [
'#type' => 'machine_name',
'#default_value' => $webform->id(),
'#machine_name' => ['source' => ['title']],
];
$form['title'] = [
'#type' => 'textfield',
'#title' => $this->t('Title'),
'#default_value' => 'A default title',
'#id' => 'title',
];
Proposed resolution
Adjust the machine_name.js to properly sync the calculated machine name,
Remaining tasks
Determine a solution
Create MR
Commit MR
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
Comments
Comment #3
jrockowitz commentedI created an MR. I don't do any core development, so forgive me if I do something wrong.
The fix could be as simple as looking at the initial machine name and not the calculated machine name.
In 10.1.x, the code worked because the machine was being calculated via transliterate Ajax request which would set the target value after the event handler was initialized.
https://git.drupalcode.org/project/drupal/-/blob/10.2.x/core/misc/machin...
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/misc/machin...
I hope this helps.
Comment #4
xjmThanks @jrockowitz! The only thing is that we need the MR to be created against 11.x, since issues are committed there first and then backported. Trying to switch the target branch can get really messy, so sometimes it's best to close the previous MR and re-create it against 11.x with a cherry-pick or whatever.
This also seems like a bug that should get some FunctionalJS test coverage, if it's a JS bug.
Thanks!
Comment #7
dcam commentedI added an assertion to
MachineNameTestin a new D11 branch. I haven't added the fix created by @jrockowitz yet. That new assertion failed as expected. I'll commit the fix and see what happens.Comment #8
dcam commentedAdded info to the steps to reproduce. This is reproducible out-of-the-box with one of core's testing modules.
Comment #10
dcam commentedComment #11
smustgrave commentedManually tested this following the steps.
Went to /form-test/machine-name
Changed the label and machine name did not change
Applying the MR and repeating
The machine name is changing
Summary seems to match the solution and has test coverage.
LGTM
Comment #12
quietone commentedComment #13
nod_This is a feature, not a bug.
Check out the 3 lines of comments just before the code change:
You want to be able to change the label without changing the machine name. Happens all the time that some vocabulary is renamed to be clearer to end-users but you want to keep the machine name to not mess with config export and custom code.
Comment #14
xjmSaving credits according to our core issue credit guidelines. Thanks!