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.Follow-up to:
- #1324618: Implement automated config saving for simple settings forms
- #1696224: Remove system_settings_form()
- #1653026: [META] Use properly typed values in module configuration
Problem
- Module settings forms were converted to the configuration system, but $form structures haven't been changed, since it was unclear whether there would be an automation.
Goal
- Update all module settings forms to use appropriate $form array keys for configuration setting keys.
Proposed guideline
Given:
- A module settings form; e.g., PerformanceForm
- A
system.performance.ymlconfig object containing (among other keys):
cache: page: enabled: '0' - And a $form definition of:
$form['caching']['cache'] = array( '#type' => 'checkbox', '#title' => t('Use internal page cache'), '#description' => t("If a reverse proxy cache isn't available, use Drupal's internal cache system to store cached pages."), '#default_value' => $config->get('cache.page.use_internal'), );
Then:
- Update the $form array key to equal the config object key in dot-notion:
- $form['caching']['cache'] = array( + $form['caching']['cache.page.enabled'] = array( '#type' => 'checkbox', '#title' => t('Use internal page cache'), '#default_value' => $config->get('cache.page.enabled'), '#weight' => -2, ); - Update the form submission handler to look for the changed key in the submitted form values:
public function submitForm(array &$form, array &$form_state) { [...] $this->config('system.performance') - ->set('cache.page.use_internal', $form_state['values']['cache']) + ->set('cache.page.use_internal', $form_state['values']['cache.page.enabled']) ->set('cache.page.max_age', $form_state['values']['page_cache_maximum_age']) - Determine which data type(s) is expected for the configuration object value:
enabled: '0'Original report by @sun
Comments
Comment #1
mtiftThe casting part of the original report is handled, but the form array part is not, so I updated the summary.
And just to clarify the tags:
beta target == "we'd like to have this in some beta"
beta deadline == "if we don't do this by beta1 we don't do it in 8.0.x"
Comment #2
catchAdmin configuration form array structures aren't a critical API, so this can still be beta target or possibly even minor version target.
Comment #3
xjmComment #16
catchWe did this (and related issues) instead: #3398982: ConfigFormBase + validation constraints: support non-1:1 form element-to-config property mapping again.