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.
Problem/Motivation
As per #2183983: Find hidden configuration schema issues several system module tests are failing due to config schema errors. This issue is to make those tests use strict schema checking and fix the issues in schemas and/or the tests.
Proposed resolution
1. Add strict schema checking to the the affected tests.
2. Fix schema/tests to pass.
Remaining tasks
Resolve. Review. Commit.
User interface changes
None.
API changes
Schema fixes as needed.
Comment | File | Size | Author |
---|---|---|---|
#10 | interdiff.txt | 2.21 KB | Gábor Hojtsy |
#10 | 2390445-system-config-schema-10.patch | 10.57 KB | Gábor Hojtsy |
#7 | 2390445-system-config-schema-7.patch | 10.57 KB | Gábor Hojtsy |
#7 | interdiff.txt | 1.13 KB | Gábor Hojtsy |
#6 | 2390445-system-config-schema-6.patch | 9.69 KB | Gábor Hojtsy |
Comments
Comment #1
Gábor HojtsyPatch to fail.
Comment #3
Gábor HojtsyImprovements based on fails:
1. seven.settings has a dependency on shortcut module. This actually fails on all kinds of other tests too. Themes cannot depend on modules for now. We could make this setting exempt from schema checking but then that is not a solution for contrib themes that may have similar settings. Looks like the way to solve this is to have runtime code that ensures that setting is present. Contrib themes / contrib modules only have this way, they cannot make their stuff exempt from schema checking when eg. all default config is tested for example. We need to use a pattern in core that contrib can use.
2. ThemeSettingsForm kept the favicon_upload file upload key if that file was not used, which ended up in config. It should always be unset. A derivative is saved in favicon_path.
3. BreadcrumbTest incorrectly sets a 'machine' key on a system menu block, with the machine name that is already part of the key.
Comment #4
Gábor HojtsyComment #6
Gábor Hojtsy1. So its pointless to try to have a seven_install() hook install does not seem to be run for themes (ref. ThemeHandler). We need to react on themes_installed in shortcut module instead.
2. We run into an RDF mapping issue here too due to system EntityViewControllerTest. The types on the RDF mapping entity is initialized to NULL (AKA not initialized), so if the types are never set, its attempted to be persisted as NULL. It should be an empty list instead.
Comment #7
Gábor Hojtsy1. form_test module lacked schema for its form_test.object.
2. The logic to decide if favicon file upload is provided had the wrong logic accidentally due to operator precedence. If we fix that with always requiring file module then it becomes the intended logic and the favicon_upload element will not end up in the form if file module is not enabled (like in PageTest). If it is enabled, it is removed later on from the form values before the settings are persisted.
Comment #9
Wim LeersLooks fine except for:
s/Themes/Theme/
s/module specific/module-specific/
This is extraordinarily ugly :(
Shouldn't this live in
seven.theme
, as ahook_modules_(i|u)nstalled()
implementation?Comment #10
Gábor Hojtsy@Wim: re 3. no, this should work both if seven theme is enabled AFTER shortcut module or before. If Seven theme is uninstalled, seven.settings will naturally go away, so that is covered. So we need to cover the case if Seven is enabled after shortcut, which is shortcut_themes_installed() and then if shortcut is enabled after seven (shortcut_install()) and shortcut uninstalled but seven still there (shortcut_uninstall()). Themes don't support hook_install() so the code to run after seven is installed needs to be in a module. Then it is simpler to do all the management in the module.
Comment #11
Wim LeersDiscussed with Alex Pott. This is ugly and unfortunate, but accepted as the only possible solution.
Comment #12
Dries CreditAttribution: Dries commentedCommitted to 8.x. Thank you.