mbaycura → created an issue.
I believe I understand now why this form is the way it is.
The 'insider' and 'outsider' scopes are meant to be 1-1 associations to a global role. When setting up 'insider' and 'outsider' group roles we saying all users with this associated global role will automatically be granted these group roles, and permissions. Therefore, there is no need to have the 'insider' and 'outsider' roles in the member edit form because that member already assumes this group role per their assigned global roles. Editing whether these 'insider' and 'outsider' roles are associated to the global role, and then a user's global roles is how one would manage these relationships.
However, if we want group roles that are group specific, that we do not want directly associated to global roles, we would then create a role with an 'individual' scope. Since there is no pre-existing global relationship with a user, these roles are then visible and assignable via the group member's edit form.
I'm not a contributor on this module, but I ran into the same issue and found that for Group 3.2.2 this is caused by:
web\modules\contrib\group\src\Plugin\EntityReferenceSelection\GroupTypeRoleSelection.php
line 32, in the class, `GroupTypeRoleSelection` filters for only individual scoped roles.
$query->condition('scope', PermissionScopeInterface::INDIVIDUAL_ID, '=');
I have no idea if this is intentional or a bug, but this is preventing visibility, and thus the ability to edit a member's roles, on the group 'member edit' form. Commenting this line out restores showing all available roles.
At this point the automated patch has only identified inconsequential syntax recommendations involving spacing and choice of semantics, no actual deprecated code related to Drupal 10 have yet been identified. Any semantic changes will be added with the next functional changes to code, but will not be made at this time.
The issue will be left open so that this project will continue to be assessed for future D10 deprecations.
Corrected typo in quick start composer command line text: composer require drupal/bootstrap_theme_toggler
Added link to SASS theme page at the end section referring to it.
Great, thanks, I verified the `import.scss` file in the sub-theme 5.0.10 is working as expected.
Just to have it recorded, the Drupal version I'm on is 10.1.4
I've finished building a theme mode toggler control, that can enable the integration of light & dark themes on a Barrio Bootstrap 5 theme, or theme built using the Barrio Bootstrap SASS Starter Kit.
Though this may not be the 'out of box' integration you are looking for, it will implement light & dark modes on existing Barrio themes.
Bootstrap Theme Toggler module →
module's documentation →
mbaycura → created an issue.
Added Getting Started and instructions for integration of custom color modes into the SASS pipestream.
corrected file path from 'custom' to 'contrib'.
Added instructions for using drush to enable module.
mbaycura → created an issue.
Adding instructions on overriding default Barrio component styling
Thanks so much Jaypan for the solution on the proper way to pass configuration data to the theme template. I've updated my code accordingly and no longer need to hard code the block id to get configuration to the template. I will also update my Drupal Answers question accordingly.
However, the nature of this block it's still best to limit the number of instances to just one, and though my validation check, effectively does this, it would be interesting to know if there is a more elegant way, as well as, if it is possible to determine the config form's nature as belonging to a 'new' or 'existing' instance of a block.
The sub-theme issue is due to the same setting mis-match inside `web\themes\contrib\bootstrap_barrio\subtheme\config\install\bootstrap_barrio_subtheme.settings.yml` where `bootstrap_barrio_enable_color` is set to zero instead of `false` in there as well.
My use case is to limit a custom block to a single instance, and my reason for needing to do that, is because I have not figured out how to programmatically retrieve a block's ID at the template rendering level. Which I posted a question about on Drupal Answers, but haven't found a solution, so the next best thing is to enforce a predictable block machine name.
With a predictable machine name I can then use `\Drupal::config('block.block.'.$defaultTheme.'_blocknameid')->getRawData()` to retrieve the blocks configuration data, within `custom_module_preprocess_block__customtemplate()`, then pass those variables on to the TWIG template the block is rendered with. If I allow more than one instance of the block then I can no longer predict what the machine name of the block is from within the template preprocess function.
My current work around to is to use a validation of the block submission on creation, in which I check the machine name and throw an error if it is not the prescribed default name, `default_theme_blocknameID`. This prevents duplicates and guarantees the name will be what is coded in the template preprocess function. This approach works overall and, at this point, works about as well as knowing if the config form is for a new or existing block, except that I can't pre-warn the user trying to implement a second instance before they try to submit it.
Regardless though, it would still be nice to know how to determine a block config form is for a new, or existing block for potential future use and improvement on my work around. It would actually be even better, to just be able to call a block instance's specific configuration to pass to a TWIG template, but that is better isolated to the other post.
Thanks, Jaypan → , that's very helpful and the type of information I was looking for. I tend to forget that Core is really just a group of modules and understanding the fundamentals of building a custom module apply to interpreting core modules. I'm also realizing that the raw source code sometimes has some more in depth commentation that doesn't get exposed on the API page description and usage notes. It's still easy for me to get turned upside down navigating through class properties and methods, services, traits, and the like, but they are slowly taking shape.
The root of this post was a desire to unload some component styling libraries used by Bootstrap Barrio Theme via a custom module. However, the purpose of the post is more general, and about trying to better understand how to use the Drupal API documentation and learn how to interpret what to do on my own. Things like, 'If the method is public, and has the root path 'core/lib/Drupal/Core/Asset/AttachedAssets.php', then from PHP you can access it by adding a use statement starting with the pre-fix 'Durpal/Core/Asset/'", or whatever might be the right approach to understand from the API documentation, what to do with it, and when it can be used.
In my original example case, I was trying to use the `custom_module_library_info_alter` hook to remove bootstrap barrio libraries I wanted to override. I attempted to do this by using:
function custom_module_library_info_alter(array &$libraries, $extension) {
// $libraries = new AttachedAssetsInterface;
// $loaded = $libraries->getAlreadyLoadedLibraries();
if ($extension == 'bootstrap_barrio') {
foreach ($libraries as $key => $library){
if (array_key_exists($key, $libraries)){
unset($libraries[$key]);
}
}
}
}The problem with this approach is that I would get errors, such as `The specified library "bootstrap_barrio/dropbutton" does not exist`. I originally thought I was getting this because the list I was working from was for all defined libraries, but not all of them are actually loaded on a given page. So I wanted to try and get just the loaded libraries. Since then I've come to suspect that this error is not from the unset line, but from later in the render pipeline when something else is attempting to access the library I unset in the library alter hook.
Thanks for the tip, that's great general development advice. I'm using VSCode, so am able to use the 'find in folder' feature to search for instances of usage in my site installation code.
Unfortunately, I'm still having some trouble replicating how it's being used.
At the top of my custom_module.module.yml file I've added:
use Drupal\Core\Asset\AttachedAssets;
use \Drupal\Core\Asset\AttachedAssetsInterface;Then in my `library_info_alter` hook tried to instantiate an interface to call `getAlreadyLoadedLibraries()` from, but I get a, 'Cannot instantiate interface Drupal\Core\Asset\AttachedAssetsInterface' error.
function custom_module_library_info_alter(array &$libraries, $extension) {
$libraries = new AttachedAssetsInterface;
$loaded = $libraries->getAlreadyLoadedLibraries();
}And have also tried creating a docblock and adding a @param in my the library info alter hook function call, similar to:
/**
* @param \Drupal\Core\Asset\AttachedAssetsInterface $cumulative_assets
* The cumulative assets sent so far;
*/
function custom_module_library_info_alter(array &$libraries, $extension, AttachedAssetsInterface $cumulative_assets) {
$loaded = $cumulative_assets->getAlreadyLoadedLibraries();
}But then I get an, `custom_module_library_info_alter(): Argument #3 ($cumulative_assets) must be of type Drupal\Core\Asset\AttachedAssetsInterface, null given`, error, which doesn't make sense to me, because that's what type I thought it was defined with.
Looks like I have more to work out with how PHP & Drupal objects work, but this gives me a starting reference to work off of.
I'm working on implementing color modes with a Barrio Bootstrap SASS sub-theme, and so far I've been able to implement a Dark, Light, and Blue mode with a few changes to the default sub-theme created by the sub-theme script.
I started by using the current 5.0.6 Bootstrap 5 - SASS starter kit script, following the installation guidance from the Drupal Bootstrap Docs → .
With the current Drupal 10 I'm using this default sub-theme had an issue with the default bootstrap and popper libraries it setup, which prevented dropdown buttons from working properly. To fix this I edited the `gulpfile.js`, in the sub-theme, to use the `bootstrap.bundle.min.js` which integrates popper, instead of the default, separate, 'bootstrap.min.js` & `popper.min.js` libraries. Using the integrated bootstrap bundle solved whatever conflict there was in the default arrangement. NOTE: I included the `bootstrap.bundle.min.js.map` file as well to clear up a warning that appears in the browser's web inspector without it.
What I changed in the `gulpfile.js` in the following places:
`const paths = {}`
const paths = {
scss: {
src: './scss/style.scss',
dest: './css',
watch: './scss/**/*.scss',
bootstrap: './node_modules/bootstrap/scss/bootstrap.scss',
},
js: {
bootstrap_bundle: './node_modules/bootstrap/dist/js/bootstrap.bundle.min.js',
bootstrap_bundle_map: './node_modules/bootstrap/dist/js/bootstrap.bundle.min.js.map',
// bootstrap: './node_modules/bootstrap/dist/js/bootstrap.min.js',
// popper: './node_modules/@popperjs/core/dist/umd/popper.min.js',
barrio: '../../contrib/bootstrap_barrio/js/barrio.js',
dest: './js'
}
}`function js () {}`
// Move the javascript files into our js folder
function js () {
// return gulp.src([paths.js.bootstrap, paths.js.popper, paths.js.barrio])
return gulp.src([paths.js.bootstrap_bundle, paths.js.bootstrap_bundle_map, paths.js.barrio])
.pipe(gulp.dest(paths.js.dest))
.pipe(browserSync.stream())
}I could now delete the old `popper.min.js` and `bootstrap.min.js` files in the sub-theme `js` directory as they are no longer necessary.
Next, following the guidance on the Bootstrap 5.3 Color-Modes page, I took a copy of the toggler javascript found there, and put it into a new file I created in the sub-theme's `js` directory, called `color-modes.js`.
Next, I updated my bootstrap sub-theme's libraries file `boot_test.libraries.yml` to reference the bootstrap bundle library I substituted for the separate bootstrap & popper libraries, as well as the new `color-modes.js` file, resulting in:
global-styling:
version: VERSION
js:
js/color-modes.js: {}
js/bootstrap.bundle.min.js: {minified: true, weight: -47}
js/barrio.js: {}
js/custom.js: {}
css:
component:
css/style.css: {}
dependencies:
- core/jquery
- core/drupalIn order to add a 3rd theme to the built in 'light' and 'dark' themes already included with bootstrap 5.3, I now created a new `themes.scss` file in the sub-theme `scss` directory in which I included all the CSS variables found in the `node_modules/bootstrap/dist/css/bootstrap-utilities.css` file for the `[data-bs-theme=dark] {}` block, in a new delcaration for `[data-bs-theme=blue] {}`.
`themes.scss`
[data-bs-theme="blue"] {
color-scheme: 'blue';
--bs-body-color: #10edfd;
--bs-body-color-rgb: 16, 237, 253;
--bs-body-bg: #8e40d8;
--bs-body-bg-rgb: 142, 64, 216;
--bs-emphasis-color: #fff;
--bs-emphasis-color-rgb: 255, 255, 255;
--bs-secondary-color: rgba(222, 226, 230, 0.75);
--bs-secondary-color-rgb: 222, 226, 230;
--bs-secondary-bg: #343a40;
--bs-secondary-bg-rgb: 52, 58, 64;
--bs-tertiary-color: rgba(222, 226, 230, 0.5);
--bs-tertiary-color-rgb: 222, 226, 230;
--bs-tertiary-bg: #2b3035;
--bs-tertiary-bg-rgb: 43, 48, 53;
--bs-primary-text-emphasis: #6ea8fe;
--bs-secondary-text-emphasis: #a7acb1;
--bs-success-text-emphasis: #75b798;
--bs-info-text-emphasis: #6edff6;
--bs-warning-text-emphasis: #ffda6a;
--bs-danger-text-emphasis: #ea868f;
--bs-light-text-emphasis: #f8f9fa;
--bs-dark-text-emphasis: #dee2e6;
--bs-primary-bg-subtle: #031633;
--bs-secondary-bg-subtle: #161719;
--bs-success-bg-subtle: #051b11;
--bs-info-bg-subtle: #032830;
--bs-warning-bg-subtle: #332701;
--bs-danger-bg-subtle: #2c0b0e;
--bs-light-bg-subtle: #343a40;
--bs-dark-bg-subtle: #1a1d20;
--bs-primary-border-subtle: #084298;
--bs-secondary-border-subtle: #41464b;
--bs-success-border-subtle: #0f5132;
--bs-info-border-subtle: #087990;
--bs-warning-border-subtle: #997404;
--bs-danger-border-subtle: #842029;
--bs-light-border-subtle: #495057;
--bs-dark-border-subtle: #343a40;
--bs-heading-color: inherit;
--bs-link-color: #6ea8fe;
--bs-link-hover-color: #8bb9fe;
--bs-link-color-rgb: 110, 168, 254;
--bs-link-hover-color-rgb: 139, 185, 254;
--bs-code-color: #e685b5;
--bs-border-color: #495057;
--bs-border-color-translucent: rgba(255, 255, 255, 0.15);
--bs-form-valid-color: #75b798;
--bs-form-valid-border-color: #75b798;
--bs-form-invalid-color: #ea868f;
--bs-form-invalid-border-color: #ea868f;
}After creating a `blue` theme scss file, I added this file to the list of imports in the `import.scss` file so it will be compiled by gulp.
`import.scss`
/* IMPORTS */
//@import url(font-awesome.min.css);
// variables
@import "variables";
// typography
@import "typography";
//bootstrap
@import "bootstrap";
//material design bootstrap
//@import "../node_modules/mdbootstrap/scss/mdb-free.scss";
// mixins
@import "mixins";
// barrio
@import "barrio";
// color pallette themes
@import "themes";Finally, I edited the sub-theme's original `scss/style.scss` file to comment out all the styling that is in there by default, except the `@import "import"` at the top. If this is not done, these styles will override the color-theme styles.
To test the color mode toggling, I took a copy of the Drupal Barrio Bootstrap `page.html.twig` template, added it to my sub-theme's `templates` folder and then add the following toggle element code just after {{ page.top_header }}, near line 90.
{# Beginning of theme mode selector #}
<div class="d-flex align-items-center gap-3">
<div class="d-flex align-items-center dropdown color-modes">
<button class="btn btn-link px-0 text-decoration-none dropdown-toggle d-flex align-items-center"
id="bd-theme"
type="button"
aria-expanded="false"
data-bs-toggle="dropdown"
data-bs-display="static">
<svg class="bi my-1 me-2 theme-icon-active"><use href="#circle-half"></use></svg>
<span class="ms-2" id="bd-theme-text">Toggle theme</span>
</button>
<ul class="dropdown-menu dropdown-menu-end" aria-labelledby="bd-theme" style="--bs-dropdown-min-width: 8rem;">
<li>
<button type="button" class="dropdown-item d-flex align-items-center" data-bs-theme-value="blue">
{# <svg class="bi me-2 opacity-50 theme-icon"><use href="#sun-fill"></use></svg> #}
blue
<svg class="bi ms-auto d-none"><use href="#check2"></use></svg>
</button>
</li>
<li>
<button type="button" class="dropdown-item d-flex align-items-center" data-bs-theme-value="light">
{# <svg class="bi me-2 opacity-50 theme-icon"><use href="#sun-fill"></use></svg> #}
Light
<svg class="bi ms-auto d-none"><use href="#check2"></use></svg>
</button>
</li>
<li>
<button type="button" class="dropdown-item d-flex align-items-center" data-bs-theme-value="dark">
{# <svg class="bi me-2 opacity-50 theme-icon"><use href="#moon-stars-fill"></use></svg> #}
Dark
<svg class="bi ms-auto d-none"><use href="#check2"></use></svg>
</button>
</li>
<li>
<button type="button" class="dropdown-item d-flex align-items-center active" data-bs-theme-value="auto">
{# <svg class="bi me-2 opacity-50 theme-icon"><use href="#circle-half"></use></svg> #}
Auto
<svg class="bi ms-auto d-none"><use href="#check2"></use></svg>
</button>
</li>
</ul>
</div>
<a href="https://github.com/twbs/examples/tree/main/color-modes/" target="_blank" rel="noopener" class="text-decoration-none">View on GitHub</a>
</div>
{# ------ END of Theme Mode Selector #}
Now everything is ready for color mode switching via this selector placed into the top_header. Make sure to change some colors inside the `themes.scss` for the `blue` mode so you can distinguish it from the `dark` settings that it was copied from.
From the sub-theme directory, open a line command window and run `gulp`, then go to your site homepage and refresh all the caches.
There should now be a selector in the Top Header called `Toggle theme`. Selecting 'blue', 'light', or 'dark' should update the theme colors to many of the elements on the page. Selecting `auto` should use either `light` or `dark` depending on your operating system settings. Note that Barrio variables defined in the sub-theme's `variables.scss` file will not be affected by this, so page elements styled by these Barrio variables will not change according to the selected theme.
I have no idea if this is the best way to setup color modes, but thought I would share how I was able to get color modes partially implemented with the existing Barrio Bootstrap SASS sub-theme, and hopefully it will be useful to others also looking to integrate color modes.
Though I'm still not sure why directly specifying the custom template directly in the custom menu render array's #theme property, in the module's theme hook isn't working as expected, I have found a working solution.
Essentially I needed to leave the custom menu's #theme parameter alone and instead add my custom menu template to the TWIG suggestions list via `main_sections_theme_suggestions_menu_alter()`. The details of this resolution can be found in the Drupal Answers Stack Exchange post regarding this same problem.
Cool, thanks, I appreciate the tip.
Sorry about that, thought this was a general project for that purpose. I figured out how to create my own project and have uploaded these images to that project. Feel free to delete if that's possible.
cheers
mbaycura → created an issue.
mbaycura → created an issue.
@swatidhurandhar, I didn't change the path in my composer.json, i had to change the paths in the patch file itself in order to use a raw git command, "git apply" to apply the patch manually outside of Drupal and composer.
I double checked my patch syntax and path in my composer.json, but still get this failure notification:
I originally had a different descriptor name, but have always been using the same patch path as the others who have been successful. I tried again using the exact syntax as Ravi, but still have the same problem. Perhaps I'm putting my patch entries in the wrong place.
Here is my composer contents, I put the patch in the "extra":{} section
per this documentation →
.
I've not applied patches before so there may be something else altogether in my project that is preventing this, but I don't know what that might be.
{
"name": "drupal/recommended-project",
"description": "Project template for Drupal projects with a relocated document root",
"type": "project",
"license": "GPL-2.0-or-later",
"homepage": "https://www.drupal.org/project/drupal",
"support": {
"docs": "https://www.drupal.org/docs/user_guide/en/index.html",
"chat": "https://www.drupal.org/node/314178"
},
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
],
"require": {
"composer/installers": "^2.0",
"cweagans/composer-patches": "~1.0",
"drupal/bootstrap_barrio": "^5.5",
"drupal/bootstrap_sass": "^5.0",
"drupal/core-composer-scaffold": "^10.0",
"drupal/core-project-message": "^10.0",
"drupal/core-recommended": "^10.0",
"drupal/devel": "^5.0",
"drupal/gin": "^3.0@RC",
"drupal/pathauto": "^1.11",
"drupal/thex": "^9.2",
"drupal/zuvi": "^10.1",
"drush/drush": "^11.3"
},
"conflict": {
"drupal/drupal": "*"
},
"minimum-stability": "beta",
"prefer-stable": true,
"config": {
"allow-plugins": {
"composer/installers": true,
"drupal/core-composer-scaffold": true,
"drupal/core-project-message": true,
"phpstan/extension-installer": true,
"dealerdirect/phpcodesniffer-composer-installer": true,
"cweagans/composer-patches": true
},
"sort-packages": true
},
"extra": {
"drupal-scaffold": {
"locations": {
"web-root": "web/"
}
},
"installer-paths": {
"web/core": [
"type:drupal-core"
],
"web/libraries/{$name}": [
"type:drupal-library"
],
"web/modules/contrib/{$name}": [
"type:drupal-module"
],
"web/profiles/contrib/{$name}": [
"type:drupal-profile"
],
"web/themes/contrib/{$name}": [
"type:drupal-theme"
],
"drush/Commands/contrib/{$name}": [
"type:drupal-drush"
],
"web/modules/custom/{$name}": [
"type:drupal-custom-module"
],
"web/profiles/custom/{$name}": [
"type:drupal-custom-profile"
],
"web/themes/custom/{$name}": [
"type:drupal-custom-theme"
]
},
"patches": {
"drupal/bootstrap_barrio": {
"Some empty regions are still visible": "https://www.drupal.org/files/issues/2023-08-09/3380104-2.patch"
}
},
"drupal-core-project-message": {
"include-keys": [
"homepage",
"support"
],
"post-create-project-cmd-message": [
"<bg=blue;fg=white> </>",
"<bg=blue;fg=white> Congratulations, you’ve installed the Drupal codebase </>",
"<bg=blue;fg=white> from the drupal/recommended-project template! </>",
"<bg=blue;fg=white> </>",
"",
"<bg=yellow;fg=black>Next steps</>:",
" * Install the site: https://www.drupal.org/docs/installing-drupal",
" * Read the user guide: https://www.drupal.org/docs/user_guide/en/index.html",
" * Get support: https://www.drupal.org/support",
" * Get involved with the Drupal community:",
" https://www.drupal.org/getting-involved",
" * Remove the plugin that prints this message:",
" composer remove drupal/core-project-message"
]
}
},
"require-dev": {
"kint-php/kint": "^5.0"
}
}
I verified application of the patch from #2 as well and it works. I was not able to use composer as
described here →
to apply the patch, but was able to manually apply it via git after editing the file paths in the patch to fit my git environment.
Thank for the quick fix
mbaycura → created an issue.
Thanks everyone for the suggestions, I've been able to work out a solution using hook_block_access and reviewing the code used by the module Block Exclude Pages → that taps into the block visibility pages configuration.
In my 'custom_module.module' file, which is 'main_secctions.module' in my case, I added:
use Drupal\block\Entity\Block;
use Drupal\Core\Session\AccountInterface;
/**
* Implements hook_block_access().
* Used to hide blocks on regions not used on pages defined by main_sections module
*/
function main_sections_block_access(Block $block, $operation, AccountInterface $account) {
// get active path
$current_path = \Drupal::service('path.current')->getPath();
// $path_alias = \Drupal::service('path_alias.manager')->getAliasByPath($nodeid);
// \Drupal::service('path.matcher')->matchPath($path_alias, '/landing/*')
// path on which to hide blocks
$hide_on_path = '/landing';
// if the current path is the landing page, hide blocks from certain regions
if ( \Drupal::service('path.matcher')->matchPath($current_path, $hide_on_path) ){
// list of regions on which to hide blocks
$hide_regions = array(
'primary_menu',
'header',
'header_form'
);
// Get the block's visibilty condition configuration
// These are the same visibility settings found on the block config page in the admin UI
$config = $block->getVisibilityConditions()->getConfiguration();
foreach ($hide_regions as $region){
// if block is on a region to hide, then update settings to hide it
if($block->getRegion() === $region){
// add the path on which block should be hidden to visibility pages list
$config['pages'] = $hide_on_path;
// set visibility pages to 'Hide for listed pages'
$config['negate'] = TRUE;
// update block with new visiblity pages config
$block->setVisibilityConfig('request_path', $config);
}
} //END foreach region
} //END path match
} // END of block access hookThanks for the references. I'm building a custom module that creates a landing page and some site sub-section home pages that have modified layouts and I want the module to be self contained so that my configuration is all in one place, and I don't have to manually manage hiding blocks that aren't needed, on every block, separately through the admin UI.
Thanks for the tip, might explain why I haven't seen much working with regions in the API. I'll try to get the same result by finding and hiding blocks instead.
Per comments, and some more digging, it seems that just hiding full regions may not be possible. So the next best thing would be to hide the blocks I don't want, programmatically doing what is done manually through the Drupal Admin block configuration UI, pages-hide/show route options.
To attempt to do this I have tried the following in my custom modules method, referenced by the controller for my landing page route.
$blocks = \Drupal\block\Entity\Block::loadMultiple();
$region_name = 'primary_menu';
// $region_name = 'content';
$block_ids = [];
$block_regions = [];
foreach($blocks as $block){
$block_ids[] = $block->id();
$block_regions[] = $block->getRegion();
if($block->getRegion() === $region_name){
$block_ids[] = $block->id();
$block_unset[] = $block->id();
// Hide this block.
unset($block);
}
}This appears to process correctly when checking my devel kint variable I sent to the resulting page I can see it filtered for main_menu block I'm trying to hide. My active theme is a bootstrap Barrio sub-theme, with no customization, called 'sp_sass_boot5'.
block_unset:
⧉⌕array (3)
⇄0 => string (26) "bootstrap_barrio_main_menu"
⇄1 => string (23) "sp_sass_boot5_main_menu"
⇄2 => string (14) "zuvi_main_menu"However it's still on the page output. Nothing has changed on my page pre and post 'unsetting' the found blocks. I've checked an array variable of the same blocks after unsetting and they are void, so they appear to have been removed. Perhaps I'm working on a local array that has been passed by value instead of reference and is not tied to the active Drupal configuration? Do I need to pass an updated array back to the system somehow?
The second issue is that I seem to be getting all blocks from all themes, active or not active. Though I suspect I can figure out how to filter for just my active theme.
I'm running this code inside my controller method, is that too late in the rendering order or perhaps is my cache getting in the way? I have cleared my cache after editing the new code, but could the render tree be refilling it before I unset the block?
Thanks for the recommendation, perhaps the code in the Context module will be of help as a reference, however, I'm trying to do this with a custom module that wholly controls these pages within itself.
I can get what I want through the the Drupal admin, configuration interface, by configuring blocks to not show up on certain routes/pages, but I am trying to do this within a module such that adding or removing the module takes care of it all directly and doesn't require me to split maintenance between the admin UI and the custom module.
I suppose another way to say what I'm trying to do is to programmatically update that show/hide list accessed through the admin UI block config. I was hoping there was a way to do that via an entire region, but if individual blocks are the only way, or maybe the proper way, then I can try that too. But I still want to do this via a custom module entirely and not split up configuration maintenance.