Motivation
There are some core modules that are using t() function inside conditional code to determine which button was pressed after a form is submitted. Problems:
- Checking against button caption is a bad practice.
- Changing the value of the button via alter hooks generates errors.
- Using t() when is not necessary.
If not defined, the default name of a button is 'op' and form api stores in this value the translated caption of the clicked button.
Example of problematic code: if ($form_state['values']['op'] == t('Save role'))
Proposed resolution
There are two proposed resolutions of this issue.
theborg proposed a resolution based on replacing the op checking by adding a #name value and checking that instead.Ex:
$form['actions']['submit'] = array(
'#type' => 'submit',
+ '#name' => 'create', <== switch on this
'#value' => t('Create new account'),
sun has proposed in #14 that this particular issue be "won't fix" because the cleaner solution here is to make this form logic broken out into custom submit handlers, and not switch on any
Most patches on this thread to this date (June 6, 2014) have been using theborg's solution of simple replacement logic, and have additionally focused on removing a lot of unnecessary calls of the t() function.
Further explanation of theborg's solution:
a) Add #name and use the $form_state['triggering_element'] that form api populates with values of the clicked button. That generates valid html that travels with form and can be used with $_POST.
b) Same as a) but adding a custom value like #op. Field_ui is using this method but can cause some problems when looking at $_POST['op'].
c) Alter form api to force storage of an untranslated string in$form_state['values']['op'] when buttons name is not using the default value:
$info = element_info($form_state['triggering_element']['#button_type']);
if (!isset($form_state['values'][$info['#name']])) {
$form_state['values'][$info['#name']] = $form_state['triggering_element']['#name'];
}
Remaining tasks
1. Create an updated list of affected files and update the below list on the issue summary accordingly.
2. Come to a consensus whether this issue should be addressed by moving from checking #op to #name on the button objects, or whether this logic should be rewritten in new form submit handlers.
3a. If checking #name, continue working on the patches in this issue (latest in #28 at time of this writing) and clean up these issues until all references are complete.
OR
3b. If rewriting to new submit handlers, then start writing new patches, using the list to find the files affected and adding custom submit handlers to the relevant buttons and adding those functions to the code.
Core files affected
1._ user.admin.inc
2._ node.admin.inc
3._ content_types.inc
4._ taxonomy.admin.inc
5._ locale.pages.inc
6._ dblog.admin.inc
7._ aggregator.admin.inc
8._ comment.pages.inc
9._ image.admin.inc
10._ forum.admin.inc
Original report by [ardas]
Issue: http://drupal.org/node/208790
"After I changed a text on "Create new account" button to any other text using form_alter hook (ex: "Register now") admin/user/user/create form stopped to function properly - it doesn't do anything. However, user/register form works"
"A button must have a permanent key (internal short name, no spaces, no capital letters, etc.) which should be used in the code."