Settings that interact with regional settings and date formats should be converted to the new configuration system.
With this issue we seek to modify all system_date variables and other variables that can be found on the admin/config/regional/* pages.
- Create the system.date.yml file
- Convert system_regional_settings in system.admin.inc to use these configuration settings.
- Search through core for any other place that use these variables and convert the CRUD syntax to use the new config system
- Revamp the handling of date formats so that it uses the config system.
- By using config files we no long need seperate type data handling functions
- As a result remove all date_type functions
- Remove database tables that previous persisted date format information.
- Ensure no feature loss through new handling of date formats
- Ensure translation of date formats is not regressed.
One feature that's added is that we're using CMI to store the configuration for data formats. As a result, we're getting rid of the tables that previously handled that task. That's a pretty important feature as developers can now modify a configuration file when they want to provide new date formats.
We also provide a place where future work can provide custom date format patterns (specifically thinking about IntlDateFormatter). We namespace the current date format patterns to php so that we can store multiple patterns for the same format. For example:
formats: system_short: name: 'Default Short Date' pattern: php: 'm/d/Y - H:i' locked: 0
In addtion, we introduce
system_get_date_format_pattern to allow the system-driven logic to retrieve the right pattern. This allows us to rework that function and this config file in the future if we want to support IntlDateFormatter.
Questions and Answers
- What does the "system_" namespacing of certain date format patterns mean to the developer?
Using 'system_' to namespace the date formats patterns for short, medium, and long provides developers who are reading the configuration a clear separation between date formats that were created by hand or through the UI and the ones that were initially installed.
True, there is nothing within our implementation that demands these configurations to be named in this way. It's a carry-over from the previous generation of this system where short, medium, and long date formats where hidden by the system so that developers would have to work harder to change them. Screwing up these formats results in system instability as they are used throughout a default Drupal installation to output dates.
So, it's one part tradition and one part a name-spacing the config to indicate that it belongs to the system.
Also, if it's still in the patch, I modified the admin pages for date formats to use the new dropbutton.
The maintenance mode settings at admin/config/development/maintenance need to be converted to use the new configuration system.
- Create a default config file and add it to the system module.
- Convert the system_regional_settings in system.admin.inc to read to/write from the appropriate config.
- Convert any code that currently accesses the variables used to use the config system.
- Write an upgrade path from D7 -> D8 to migrate existing data to the new system and drop the appropriate variables.
This would be a good task for someone wanting to get up to speed on how the new config system works. Feel free to ping me on IRC if you need help.
Follow up issues
PASSED: [[SimpleTest]]: [MySQL] 48,839 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: failed during invocation of run-tests.sh. View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1571632_301-fixed.patch. Unable to apply patch. See the log in the details link for more information. View