Running the installer leads into a wsod

my first submission errored out. created a new, second, issue, but on submit that created two identical issues. closing this one as duplicate. apologies.

I closed the other one as a duplicate, no worries.

@rkoller, does this happen on 1.x HEAD, without 🐛 Remove .ddev directory from composer create-project Active ?

nope, just tested, on 1.x HEAD, it does not happen there. git cloned the repo into a new empty directory, ran simply ddev launch and after the initial setup was done and the installer was popped up in the browser i've entered the same settings as in steps to reproduce

Arrrrghhhh...thanks for checking.

Huh, I just tried this with the latest changes from 🐛 Remove .ddev directory from composer create-project Active -- I admit I might have to update the manual testing instructions -- and it worked for me.

and i am completely puzzled meanwhile. yesterday (or better this morning right before bed) i'Ve tried it one last time with the shell install and documented everything in a gist https://gist.github.com/rpkoller/297ba345281def46cf8f302147bd68c5 (@rfay suggested to set export DEBUG=true and document every detail in that gist). but after ten plus consistent WSODs attempts over the night it worked in that last attempt for the first time as documented in the gist. all other attempts with the same setup failed repeatedly consistently. i said in #4 git clone git@git.drupal.org:project/drupal_cms.git . && ddev launch worked yesterday. well this morning right after waking up i'Ve retried things, cuz it puzzled me that it worked for the shell approach in my last attempt before bed, and i am back to the WSOD and had another two failed attempts (thought maybe it was a lima problem, but that could be ironed out because after the computer was shut down over night it was a fresh start today). i then tried the git clone git@git.drupal.org:project/drupal_cms.git . && ddev launch which worked fine the few times i tested yesterday. BUT one out of the three attempts this morning failed now. so the WSOD happened there as well but not that consistent. NO idea what could be causing this. might be some sort of race condition that might happen more likely with the shell approach compared to the git clone one?!

For whatever it's worth, there does seem to be preexisting evidence (not in this issue) that there is a race condition in the installer somewhere.

I have absolutely no idea how that's possible, but there seems to be something. It's extremely hard to debug (or even reproduce)! Because it doesn't happen consistently, though, it's not a stable blocker or a top priority. :-\

for the git based approach i completely agree but in case of the shell script it isnt such a rare case anymore but more of a consistent problem, at least for me (and yep very hard to debug - i will ask randy if he might have an idea how it might be possible to debug that). i think i will try a few more times after 🐛 Remove .ddev directory from composer create-project Active goes in and if the problem persists there and keeps happening that consistent i would consider it more pressing problem tbh cuz launch-drupal-cms.sh might be the way quite a few people interact with drupal cms for the first time in the future? and i guess the odds are high that i am not the only one then.

@rkoller:

You mention Safari, so I assume you are using macOS. What hardware, and what version of the OS?

What version of DDev are you using? And lima.

In #6, @phenaproxima mentioned possibly updating the testing instructions. Are these the steps you use?

• Check out the MR branch and copy the project_template directory to another location.
• Rename the copied directory to something else (like cms-test or whatever) and cd into it
• Edit launch-drupal-cms.sh and replace this line:
  ddev composer create drupal/cms --stability="RC"
  with this:
  ddev composer create drupal/cms --stability="dev" --repository='{"type":"vcs","url":"https://github.com/phenaproxima/test-ddev-cms.git"}'
• Run ./launch-drupal-cms.sh OR follow the proposed instructions from https://github.com/ddev/ddev/pull/6829

i am on a mbp m1pro 32gb with sonoma 14.7.2 and safari 18.2... and i am on lima 1.0.2 and on the HEAD version for DDEV.

and the steps are correct, plus the steps i've applied in the installer "In the installer choose all the available pre configured types of content (blog, case studies, events, news, person profiles and projects), use the default site name, and finally add an email address and password"

but as we have discussed on slack the issue got committed meanwhile, so those additional steps are not necessary anymore, it is simply downloading the zip file from either https://www.drupal.org/project/drupal_cms → or https://new.drupal.org/drupal-cms/release-candidate and then follow the aformentioned settings in the installed. but as i have noted with the zip file from one of those links i was unable to reproduce the WSOD so far. but i will try a few more times tonight if i am able to.

My system:

• macOS Sonoma 14.7.1
• Safari 18.1.1
• Apple M3 Pro Chip
• 36 GB RAM
• DDEV 1.24.1 (*)
• lima 1.0.2 (*)

(*) After brew upgrade

I cannot reproduce the problem.

After upgrading my Mac to Sonoma 14.7.2/Safari 18.2 (same as @rkoller) I can reproduce the problem.

I did not try exactly these steps to reproduce before upgrading. But I cannot use the script because I get an rsync error when I try ddev composer create .... Instead of fixing that, I use these steps:

mkdir cms-test14
cd cms-test14
ddev config --project-type=drupal11 --docroot=web
ddev start
ddev ssh
composer create-project drupal/cms --stability="RC" # on the container
vi .ddev/config.yaml # Change web to cms/web
exit
ddev restart
ddev launch # Set default browser to Safari.

I run the installer, without selecting any of the optional recipes. I end on the page https://cms-test14.ddev.site/admin/dashboard/welcome?check_logged_in=1 with the error message

Error: Call to a member function getPath() on null in drupal_cms_installer_theme_registry_alter() (line 280 of profiles/drupal_cms_installer/drupal_cms_installer.profile).

It seems that the custom installation profile did not uninstall itself:

% ddev exec cms/vendor/bin/drush st --field=install-profile
drupal_cms_installer

But if I clear caches, then it is gone:

% ddev exec cms/vendor/bin/drush cr                        
 [success] Cache rebuild complete.
% ddev exec cms/vendor/bin/drush st --field=install-profile && echo done

done

In fact, after clearing caches I do not see any problem with the site.

Using Firefox or Chrome, everything works normally.

It is not related to this issue, but there is another problem with the launch-drupal-cms.sh script:

ddev config --project-type=drupal11 --docroot="$DOCROOT" || exit 3

The type drupal11 is only available with the latest DDEV. On Linux, I have installed with apt, and I seem to be stuck at 1.23.1. Perhaps that line should change to this (suggested by @rkoller):

ddev config --project-type=drupal --php-version=8.3 --docroot="$DOCROOT" || exit 3

I'm able to confirm this error, using both Lima and Orbstack as Docker providers, but only on Safari version 18.2. I had to upgrade the mac to Sequoia 15.2 to get it.

I can reproduce reliably with this procedure:

1. unzip drupal-cms.zip
2. mv drupal-cms . For example, `mv drupal-cms dc6`
3. cd dc6
4. ./launch-drupal-cms.sh
5. When it opens web browser, switch over to Safari, with the right URL, like https://dc6.ddev.site
6. Select all of the options, next
7. Use admin@example.com/admin for username/pass
8. Say "never for this site" when it prompts to save password.
9. It dies after a long pause after "Applied projects recipe"

The website encountered an unexpected error. Try again later.

Error: Call to a member function getPath() on null in drupal_cms_installer_theme_registry_alter() (line 286 of profiles/drupal_cms_installer/drupal_cms_installer.profile).
Drupal\Core\Extension\ModuleHandler->alter() (Line: 434)
Drupal\Core\Theme\Registry->build() (Line: 276)
Drupal\Core\Theme\Registry->get() (Line: 88)
Drupal\Core\Utility\ThemeRegistry->initializeRegistry() (Line: 69)
Drupal\Core\Utility\ThemeRegistry->__construct() (Line: 314)
Drupal\Core\Theme\Registry->getRuntime() (Line: 141)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 188)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 176)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->makeSubrequest() (Line: 132)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->on404() (Line: 109)
Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase->onException() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 241)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable() (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Did some more digging with Xdebug. I got the following output for Safari in the last step right before the WSOD turns up with a breakpoint added on line 286 of the drupal_cms_installer.profile .

The entire call stack contains calls on functions to files that belong to core or symfony, at least as far as i can see. drupal_cms_installer_theme_registry_alter() is getting called in the previous step in the ModuleHandler.php.

I've then tried the same with Firefox. But the breakpoint was not triggered right at the end like in Safari, you directly go into Dashboard instead. So it looks like drupal_cms_installer_theme_registry_alter() isn't called with Firefox. I've now tried to debug the previous steps, finding out at which point of the call stack you get to the Dashboard instead (but unfortunately i have to press proceed for too many times and i am not getting anywhere not even past the first section of the installer cuz i had set the last four breakpoints from the call stack shown for Safari - even with just the breakpoint for modulehandler.php only there are too many clicks)

The WSOD persists in RC2 for Safari, just "successfully" tested. Only difference the line shifted further to 295

The website encountered an unexpected error. Try again later.

Error: Call to a member function getPath() on null in drupal_cms_installer_theme_registry_alter() (line 295 of profiles/drupal_cms_installer/drupal_cms_installer.profile).
Drupal\Core\Extension\ModuleHandler->alter() (Line: 434)
Drupal\Core\Theme\Registry->build() (Line: 276)
Drupal\Core\Theme\Registry->get() (Line: 88)
Drupal\Core\Utility\ThemeRegistry->initializeRegistry() (Line: 69)
Drupal\Core\Utility\ThemeRegistry->__construct() (Line: 314)
Drupal\Core\Theme\Registry->getRuntime() (Line: 141)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 158)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 153)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse() (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 188)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 176)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->makeSubrequest() (Line: 132)
Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->on404() (Line: 109)
Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase->onException() (Line: 246)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 241)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable() (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Personally I couldn't reproduce this, just running the installer:
./launch-drupal-cms.sh

with the following setup:
MacOS X Sonoma 14.6.1
Safari 18.0
ddev version v1.24.1
and checking NONE of all the available pre configured types of content (blog, case studies, events, news, person profiles and projects)

The Drupal CMS sites builds fine to me,
but (still) for the NOT generation of the Hero home page ( https://www.drupal.org/project/drupal_cms/issues/3494618 🐛 Drupal Cms Front Page Hero image not visible in the first load / visit (needs a reload) Active )

I ran into same error while installing the site with the installer. But WSOD appears with only a line at first:

The "dashboard" parameter was not converted for the path "/admin/dashboard/{dashboard}" (route name: "entity.dashboard.canonical")

After refresh, the same complete verbose is shown as mentioned in the issue-summary.

But this error occured for me with two browsers (both chromium based):

• Microsoft Edge version: 131.0.2903.99
• Brave: version version: 1.73.101

However the error DOES NOT occur in Mozilla Firefox 133.0.3 (64-bit)! It worked perfectly in this browser!

Some more info about the testing environment:
OS: Ubuntu 24.02
ddev: 1.24.1

Same process was applied. None of the pre configured content types were selected and skip this step button was pressed followed by regular install with default name.

thanks for testing @itamair, you are unable to reproduce because you are on safari 18.0... as outlined in #13 🐛 Running the installer leads into a wsod Active , @benjifisher was on a version <18.2 as well unable to reproduce, but as soon as he updated to 18.2 he was able to reproduce.

@debrup i guess you are seeing a different kind of error. is it happening to you with the zip for RC2? there seems to be a regression of the issue in 🐛 The "dashboard" parameter was not converted for the path Needs work . i've read a discussion yesterday where @stasadev ran into the same problem you've encountered.

Hello @rkoller,
I was using a forked repo of the 1.x branch as I was working on an issue. The fork is fairly new as I created it yesterday. I did not use any zip file.

So I have no idea why this is happening in Safari only, but I think I see a real easy way to get rid of this WSOD: let's just add a line like this at the top of drupal_cms_installer_library_info_alter():

  global $install_state;
  // If we're no longer installing Drupal, there's nothing for us to do.
  if (empty($install_state)) {
    return;
  }

I'll bet you a silver dollar that will fix the problem while not affecting anything else. I'd gladly merge that. This is a case where doing due diligence might be more trouble than it's really worth.

However, speaking of due diligence. As I scanned through the backtrace in the issue summary, this one line jumped out at me:

Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase->onException() (Line: 246)

So an exception happened somewhere, and that has triggered a subrequest for (presumably) the exception page! The subrequest doesn't have $install_state available to it (that only ever happens during the install process), so it craps out.

So although I'm in favor of just papering over the WSOD by adding an early return in drupal_cms_installer_library_info_alter(), we should also figure out where the original exception is coming from, and what the problem is, and fix that. I'm guessing that adding the early return will actually enable us to do that. Can someone open an MR, please, which adds the early return, then try again and let me know what the new result is?

Looking at the backtrace again, you can see one or two frames further down in the call stack:

Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber->on404()

So a 404 error (presumably) is occurring, somewhere, somehow, and we're getting another failure while trying to handle that, because /system/404 isn't an installer page, so $install_state doesn't exist, but the profile is still installed (and therefore its library_info_alter hook runs).

That's why the early return is probably the "correct" fix, but it would be nice to know what exactly is triggering a 404. That may be where we'll find out why this only affects Safari.

In MR !338, I added the empty($install_state) check as suggested in #22, although I am not sure why it should be in drupal_cms_installer_library_info_alter() instead of drupal_cms_installer_theme_registry_alter().

If I were to going to try to fix this with only partial diagnosis, then I would clear caches after uninstalling:

function drupal_cms_installer_uninstall_myself(): void {
  \Drupal::service(ModuleInstallerInterface::class)->uninstall([
    'drupal_cms_installer',
  ]);
  // Clear caches here.
  // ...
}

That is based on my testing in #13: drush st shows Install profile : drupal_cms_installer, but that goes away after drush cr.

My guess is that @rkoller's stack trace in the issue summary (also reported by @rfay in #15 and @rkoller in #17) shows an NotFoundHttpException because it is trying to load a page defined by the dashboard module, and that module is (thanks to stale cache) apparently uninstalled.

If that guess is right, then you are looking at a symptom. If my guess is wrong, then you are probably looking in the right place.

thanks! i've manually tested. after checking out the feature branch i've did three rounds of installs (after reaching the dashboard i did a ddev drush sql:drop && ddev launch)... so at the moment i am unable to reproduce the WSOD. so the only thing left to answer is benjis question if we are looking still at another symptom or the actual root cause. the only thing i can say is that at least i am unable to run into the WSOD at the moment.

I can produce that stack trace by just curling any random invalid path during the install. E.g.:

% curl http://localhost:8888/bla
The website encountered an unexpected error. Try again later.<br><br><em class="placeholder">Error</em>: Call to a member function getPath() on null in <em class="placeholder">drupal_cms_installer_theme_registry_alter()</em> (line <em class="placeholder">295</em> of <em class="placeholder">profiles/drupal_cms_installer/drupal_cms_installer.profile</em>). <pre class="backtrace">Drupal\Core\Extension\ModuleHandler-&gt;alter() (Line: 434)
Drupal\Core\Theme\Registry-&gt;build() (Line: 276)
Drupal\Core\Theme\Registry-&gt;get() (Line: 88)
Drupal\Core\Utility\ThemeRegistry-&gt;initializeRegistry() (Line: 69)
Drupal\Core\Utility\ThemeRegistry-&gt;__construct() (Line: 314)
Drupal\Core\Theme\Registry-&gt;getRuntime() (Line: 141)
Drupal\Core\Theme\ThemeManager-&gt;render() (Line: 446)
Drupal\Core\Render\Renderer-&gt;doRender() (Line: 203)
Drupal\Core\Render\Renderer-&gt;render() (Line: 158)

I also got the trace when the installer completes in Firefox. But my machine is really old and really slow, so that might help with the race condition.

[12606] [Thu Dec 19 07:45:36 2024] [::1]:54554 [302]: GET /core/install.php?profile=drupal_cms_installer&langcode=en&recipes%5B0%5D=drupal_cms_starter&recipes%5B1%5D=drupal_cms_blog&recipes%5B2%5D=drupal_cms_case_study&recipes%5B3%5D=drupal_cms_events&recipes%5B4%5D=drupal_cms_news&recipes%5B5%5D=drupal_cms_person&recipes%5B6%5D=drupal_cms_project&site_name=My%20Drupal%20CMS%20site
[12606] [Thu Dec 19 07:45:36 2024] [::1]:54554 Closing
[12607] [Thu Dec 19 07:45:36 2024] [::1]:36944 Accepted
[12607] [Thu Dec 19 07:45:36 2024] [::1]:36944 [302]: GET //admin/dashboard/welcome
[12607] [Thu Dec 19 07:45:36 2024] [::1]:36944 Closing
[12593] [Thu Dec 19 07:45:36 2024] [::1]:36958 Accepted
[12593] [Thu Dec 19 07:45:36 2024] Uncaught PHP Exception Error: "Call to a member function getPath() on null" at /[...]/web/profiles/drupal_cms_installer/drupal_cms_installer.profile line 295
[12593] [Thu Dec 19 07:45:36 2024] [::1]:36958 [500]: GET /admin/dashboard/welcome?check_logged_in=1
[12593] [Thu Dec 19 07:45:36 2024] [::1]:36958 Closing
[12605] [Thu Dec 19 07:45:37 2024] [::1]:36962 Accepted
[12605] [Thu Dec 19 07:45:37 2024] [::1]:36962 [404]: GET /favicon.ico - No such file or directory
[12605] [Thu Dec 19 07:45:37 2024] [::1]:36962 Closing

I think I have a lead. Since 📌 OOP hooks using attributes and event dispatcher Needs review hook implementations are stored in a container parameter. That parameter is dumped along with the container when the very first request is handled by the standard front controller (index.php) and DrupalKernel.

Normally the very first request taking this code path is the redirect after the installation. An installation will complete successfully if that is the case.

Any stray request handled by the default front controller and DrupalKernel during installation will trigger a container build / dump. I guess that this might have lead to problems before. But now that HookCollectorPass sets the hook_implementations_map parameter which is subsequently used by ModuleHandler when hooks are invoked, the effect of an outdated container loaded from cache is much worse.

In order to isolate its environment, the installer uses a special InstallerKernel with container dumping disabled. The final drupal_cms_installer_uninstall_myself step is executed in the installer environment as well. It actually does trigger a container rebuild, but the resulting container is not dumped. After the subsequent redirect, a stale container is loaded from cache and ModuleHandler uses an outdated hook implementations map where drupal_cms_installer hook implementations are still present.

There's debugging, and then there's debugging. #30 is the latter. Wow!

Any stray request handled by the default front controller and DrupalKernel during installation will trigger a container build / dump.

@rkoller mentioned to me in Slack that he saw in the server logs that during installation, Safari -- and Safari alone, presumably -- is making requests for some icons (I can't remember their names) that are not existing in the project, thus triggering 404s. Those are probably the stray requests that mess up the container, and would also explain why this is only affecting Safari. What's more, it would explain why this is only affecting certain versions of Safari.

I wonder if doing an explicit container cache clear in drupal_cms_installer_uninstall_myself() would fix it. Could someone give that a try? Just add this as the last line of the function:

\Drupal::cache('container')->deleteAll();

Let's give that a try and see if it squashes this bug.

I have added \Drupal::cache('container')->deleteAll(); in drupal_cms_installer_uninstall_myself().

But now it throws some error. screenshot attached herewith

The website encountered an unexpected error. Try again later.
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "cache.container". in Symfony\Component\DependencyInjection\ContainerBuilder->getDefinition() (line 1042 of /var/www/html/vendor/symfony/dependency-injection/ContainerBuilder.php).

I reproduced the same problem, @rushikesh raval. Changing it to \Drupal::service('kernel')->invalidateContainer(); fixed it (my bad!), and the installer succeeded. Try that?

It worked for me so I have pushed that to the MR. If any of you lovely people would care to test it out, I'll happily commit this.

@phenaproxima I have try with \Drupal::service('kernel')->invalidateContainer(); as per #33.

It working now.

so issue https://www.drupal.org/project/drupal_cms/issues/3492820 🐛 The "dashboard" parameter was not converted for the path Needs work is also fixed.

So this is (probably) causing two bugs, eh!

That, in my book, makes this a critical.

I've also tested the latest changes in MR338.. did three rounds of testing. after each round i did a drush sql:drop. and with the latest changes i've ended up on the dashboard three times in a row, no WSOD. per @phenaproximas i'll set the issue to RTBC.

This is a very tricky bug that I wasn't going to have the bandwidth to dive into before general release, but man, the community really stepped up. I'm grateful for all your diligent reporting, testing, and work in this issue.

Joyfully merged into 1.x. Thanks!

phenaproxima → credited bala.addweb → .

phenaproxima → credited stasadev → .

phenaproxima → credited upperholme → .

phenaproxima → credited yogesh kushwaha → .

Transferring credit from 🐛 The "dashboard" parameter was not converted for the path Needs work , which appears to be the same bug in a different form.

Echoing @phenaproxima's awe at the collaboration to get this fixed! Thanks everyone :)