Up to this point I have succesfully used the following:
function hook_form_config_split_edit_form_alter(&$form, &$form_state, $form_id) { // Support both old and new versions of the module if (isset($form['blacklist_fieldset']['theme'])) { $form['blacklist_fieldset']['theme']['#access'] = TRUE; }else{ $form['complete_fieldset']['theme']['#access'] = TRUE; } }
This no longer seems to work after I followed the upgrade path to Drupal 10.2 and version 2.0 of config_split.
I am not sure whether this broke due to the updates that have been applied to the database, or because the code works differently now.
The patch of the merge request also still applies, so I don't know what is wrong, but all sites in the multisite system now no longer seem to understand that a different theme should be used.I am investigating this, but maybe some one already knows the answer / has a solution?
- First commit to issue fork.
- πΊπΈUnited States dasginganinja Bethlehem, PA
I used the code from @Paul Dudink above with Config Split 2.0.2 to enable the theme box that there is support for? This was hidden behind an access false and it worked fantastically for our use case.
/** * Implements hook_form_FORM_ID_alter(). */ function hook_form_config_split_edit_form_alter(&$form, &$form_state, $form_id) { // Support for version 2 of the module. if (isset($form['complete_fieldset']['theme'])) { $form['complete_fieldset']['theme']['#access'] = TRUE; } }
For Paul's issue above I'd be curious if his theme issues are due to a weighting of the theme names. My assumption would be that your base theme should be lexicographically sorted first before your other themes to avoid issues.
theme_base before theme_subtheme sort of thing, ya dig?
If you have a situation where you have `subtheme` and then `theme_base` I'd try to avoid that based on my past experiences with Drupal module default weight ordering.Good luck all.