After D7 Upgrade - Dashboard Link in Menu that does nothing
Description of the bug
If I go through the process of upgrading a site using the D2B Migrate Module, after the upgrade is complete there is a link to the dashboard page, but there is no icon and the link goes to a blank page - because the dashboard module is not enabled.
Steps To Reproduce
To reproduce the behavior:
Upgrade a Drupal 7 site to Backdrop with the D2B module. I assume the same problem is true if you go through the regular upgrade process, but I have not tested it.
Actual behavior
Dashboard link is present without an icon and linking to a blank page.
Expected behavior
I expect that either there is no dashboard link in the admin menu or that if it is there, it has an icon as expected and links to the actual dashboard.
I personally would prefer the second option.
Additional information
I have done this several times and can verify that the Dashboard module is NOT enabled on the original Drupal 7 site and there is no Dashboard link in the admin menu.
I originally opened another issue suggesting that enable modules like the project installer and the dashboard module during upgrades. But, since that issue proposes a specific solution that is not uniformly accepted, I am opening this more specific issue to address the bug aspect of this and to enterain other possible solutions.
https://github.com/backdrop/backdrop-issues/issues/6451
If anyone would like to test this, I can provide a copy of the database I used in this example stripped of user data. Please, contact me in Zulip. If you have a Drupal 7 database, you should be able to test this in a Backdrop CMS Demo Sandbox.
I just verified that you can test this in a just a couple of minutes using a Demo Sandbox site on BackdropCMS.org and a D7 database.
You can reproduce the same problem by simply disabling the Dashboard module in a "native" Backdrop installation. The link remains without an icon.
Even after you uninstall the Dashboard module, the iconless link remains. Only clearing the cache removes it.
My wild guess here is (in this case) a problem with the admin bar cache. But this may not explain the similar issue with your D7 upgrade (it may be a different cause there).
EDIT: clearing the cache doesn't fix the iconless link if you only disable (not uninstall) Dashboard. This works only if you fully uninstall it.
EDIT 2: Another observation. When you disable (not uninstall) Dashboard, the Dashboard layout gets disabled too. However, once you fully uninstall Dashboard AND clear the cache, the Dashboard layout is deleted. Soooo, this may have to do with poor handling of disabled layouts that have a "Normal menu entry" in Menu handling (another wild guess)
@argiepiano - My initial thought was that these issues should't be related, because the dashboard module was never enabled in the Drupal 7 site that was upgraded.
But, then it occurred to me. That I'm running the D2B upgrade on a fresh BD site in which the Dasbhoard module WAS enabled, before the upgrade. I'm guessing that this is a config issue. After the upgrade, there is potentially still some config files for the dashboard module which were never deleted.
This makes me wonder if this might be a problem with other things as well. This should be somethign pretty easy for me to check, I'll do that now.
@argiepiano and @docwilmot
Yes, after upgrade the dashboard config file still exists. The module is not enabled and not available to uninstall.
{
"_config_name": "dashboard.settings",
"dashboard_login_redirect": true,
"news_feed_url": "https://backdropcms.org/api/notifications"
}
This makes me think that maybe this is an issue for the D2B Migrate module. Maybe the D2B Migrate module needs to do some cleanup before running the upgrade.
Or does the core upgrade process need to do this cleanup, since this may also effect all upgrades even if they don't use D2B.
In meetings today it was pointed out to me that this problem would not effect the normal upgrade, so this problem is probably specific to the D2B module upgrade process. I already have a ticket there and will pursue this issue there.
Should I close this issue or does anything think that there is still a core component to this problem?
Well, I pointed out above that this happens also on a native installation of BAckdrop. Is there an issue that addresses the problem I discovered?
So, perhaps it's a good idea to start a separate issue, or rename the description here
@argiepiano There is an issue for that already. https://github.com/backdrop/backdrop-issues/issues/3888
This is what you are referring to, right?
@argiepiano There is an issue for that already. #3888
This is what you are referring to, right?
Yes, that's it. So, this can be closed in my opinion
@laryn - You reported similar behavior during what I assume was a normal upgrade. https://github.com/backdrop/backdrop-issues/issues/3888#issuecomment-965840374
Do you think this issue is different from #3888 and/or should it be a core issue?