Score:1

Unable to reinstall Admin Toolbar in modules directory

mx flag

All my modules are in the web/modules/ directory except for Admin Toolbar which is in web/modules/contrib/. (Why? Long story, legacy site.) Admin Toolbar refuses to update now because of the inconsistency.

I temporarily changed the composer modules directory to web/modules/contrib/ and uninstalled the toolbar flushing the cache all along the way. I then removed the admin_toolbar directory and the composer.json entry. I changed the composer directory back to web/modules/ and installed Admin Toolbar again (doing more cache flushing). Everything's fine until I enable the module. It breaks the site and returns:

TypeError: Drupal\Core\Render\Renderer::doTrustedCallback(): Argument #1 ($callback) must be of type callable, array given, called in /var/www/html/yln/web/core/lib/Drupal/Core/Render/Renderer.php on line 788 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 51 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php). 

Is there some way to fix this? Is there something in the database that could be manually edited to get around this problem? I'm on Drupal 9.

Update: Here's my json file.

{
    "name": "drupal/recommended-project",
    "description": "Project template for Drupal 9 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": {
        "0": {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    },
    "require": {
        "composer/installers": "^1.9",
        "drupal/addtocal_augment": "^1.1@beta",
        "drupal/admin_toolbar": "^3.4",
        "drupal/block_visibility_groups": "^2.0",
        "drupal/bootstrap": "^3.28",
        "drupal/bootstrap5": "^3.0",
        "drupal/core-composer-scaffold": "^9.3",
        "drupal/core-project-message": "^9.3",
        "drupal/core-recommended": "9.5.9",
        "drupal/date_augmenter": "^1.1@beta",
        "drupal/devel": "^5.1",
        "drupal/easy_breadcrumb": "^2.0",
        "drupal/entity_print": "^2.11",
        "drupal/extlink": "^1.7",
        "drupal/fullcalendar_view": "^5.1",
        "drupal/libraries": "^4.0",
        "drupal/linkchecker": "^1.1",
        "drupal/mimemail": "^1.0@alpha",
        "drupal/multiple_fields_remove_button": "^2.2",
        "drupal/r4032login": "^2.2",
        "drupal/search_api": "^1.29",
        "drupal/search_api_autocomplete": "^1.7",
        "drupal/search_api_solr": "^4.2",
        "drupal/search_api_spellcheck": "^4.0",
        "drupal/slick": "^2.7",
        "drupal/smart_date": "^4.0",
        "drupal/tagclouds": "^2.0",
        "drupal/twig_tweak": "^3.2",
        "drupal/typed_data": "^1.0@beta",
        "drupal/upgrade_status": "^4.0",
        "drush/drush": "^11",
        "mikehaertl/phpwkhtmltopdf": "~2.1",
        "tecnickcom/tcpdf": "~6"
    },
    "conflict": {
        "drupal/drupal": "*"
    },
    "minimum-stability": "stable",
    "prefer-stable": true,
    "config": {
        "sort-packages": true,
        "allow-plugins": {
            "composer/installers": true,
            "drupal/core-composer-scaffold": true,
            "drupal/core-project-message": true
        }
    },
    "extra": {
        "drupal-scaffold": {
            "locations": {
                "web-root": "web/"
            }
        },
        "installer-paths": {
            "web/core": [
                "type:drupal-core"
            ],
            "web/libraries/{$name}": [
                "type:drupal-library"
            ],
            "web/modules/{$name}": [
                "type:drupal-module"
            ],
            "web/profiles/{$name}": [
                "type:drupal-profile"
            ],
            "web/themes/{$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"
            ]
        },
        "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/8/install",
                "  * 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"
            ]
        }
    }
}

I just ran composer require 'drupal/admin_toolbar:^3.4' and cleared the cache. Composer says it upgraded admin_toolbar to 3.4 but Drupal reports it's still at 3.3.

cn flag
While you're doing this, it's probably worth considering that having contrib modules in modules/contrib (and custom in modules/custom) is considered best practice. Having them all directly in modules is quite an old style of organising the files as far as Drupal's concerned. It'll still work the way you're doing it (your current issue notwithstanding), but it's going to make things difficult when you want to introduce a proper deployment flow, and less predictable for future devs working on the site
Chanel avatar
mx flag
That ship has sailed. This site existed pre-v7 (I've forgotten what version we were on originally) and there was no upgrade process that I know of to move modules to the new directories. It was only until when I moved to v9 that things went haywire where some modules were in contrib and some not. We have almost 50 modules and I'd have to uninstall, delete all the settings, and start over from scratch again. And I would have the same problem as above but in reverse. That just isn't feasible. If I'm incorrect, please educate me.
cn flag
That's the other thing I should've mentioned - you don't actually need to uninstall a module to move it. Drupal is smart enough to separate the physical path from the module that's installed, it just needs to find a `module.info.yml` _somewhere_ during discovery to link it up. Usually you would literally move the folder, rebuild cache, then possibly rebuild cache one more time, and all should be well. BTW I realise none of this addresses the error you've got, it was more of an aside. Maybe you could restore a fresh backup, move everything into contrib, clear cache a few times, and see
cn flag
Or if you're not bothered about changing the paths to /contrib, restore a DB backup and just try moving the toolbar module up without uninstalling, and then cache rebuilds
Chanel avatar
mx flag
I'll give it a shot. If it's that easy, I'll go ahead and move everything to contrib and custom. I'm assuming I can't do it one module at a time at my convenience but will have to do it in one fell swoop. I just tried putting the admin_toolbar back in contrib and when I ran the update (for just that module), it reinstalled a whole bunch of my other modules in contrib too. Now I have real mess. (I'll revert the server -- it's my test system so I run hogwild.)
cn flag
The installer path plugin (thing that moves drupal modules into web/ rather than vendor/) always works on the current settings, and composer will always make sure everything's installed during an update, so if you change from modules to modules/contrib, it's going to install everything again. You might be overthinking all of this a bit though - the mess can be cleared up by simply deleting the contrib module folders that are directly under /modules, and rebuilding cache
4uk4 avatar
cn flag
... and how is the error connected to all of this? This error seems just so random, a wrong callback in a render array. Could be anywhere. Get a stack trace. Xdebug might be helpful to check the variables' content.
id flag
It’s a guessing game without seeing the composer.json file.
apaderno avatar
us flag
It seems the question wrongly diagnosed why the module does not correctly update. Drupal core looks for modules in the *modules* directory and its subdirectories; the fact most of the modules are installed in web/modules and a single module is installed in web/modules/contrib does not cause any issue.
Chanel avatar
mx flag
@Clive I moved admin_toolbar into modules, refreshed the cache three times, and when I reload the site, I get the error `Drupal\Component\Plugin\Exception\PluginException: Plugin (admin_toolbar_tools.extra_links:node.add.article) instance class "Drupal\admin_toolbar_tools\Plugin\Menu\MenuLinkEntity" does not exist. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 97 of core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php). `
id flag
I’m voting to close this question because it is becoming a support thread. As currently-written it is not possible to answer. It needs updating and refocusing.
Chanel avatar
mx flag
@cilefen Then where am I supposed to ask the question?
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.