Route serialization incompatibilities between PHP 7.4 and 7.3 (9.x only)

@NigelCunningham can you confirm that you are using the drush installed by composer or a globally installed drush?

I would have expected the drush to be run using ./vendor/bin/drush - the command you've posted in the issue summary suggests a global drush.

Could you confirm the output of ./vendor/bin/drush --version against both 8.9.0 and 9.0.0?

Also the error is in generating the output of the password reset link for user/1 - so it looks to me like the output of drush uli rather than drush si?

Are you using the database cache? If so could you manually truncate the database tables, see if the site works then, and then try to trigger a cache clear from the performance admin screen? This might help to rule drush or cache clears in general in or out.

Lastly, are you running the same PHP version on cli and your webserver?

OK more questions:

Can you redo the install via the UI, then clear caches from the performance admin page - that would narrow down whether this is an issue with router rebuild generally, or specific to when it's called from drush.

Also, if that works, then could you try only drush uli on a working site to see if it can generate the link or not.

Then a further question would be - could you dump the output of SELECT COUNT(*) FROM router on a working and non-working site, and also SELECT name FROM router ORDER BY name ASC.

Also double check dblog for any notices or errors from router rebuild.

Per #10.

This is just a guess but any chance you can disable opcache and apcu (if you have it enabled), restart your webserver, and then repeat your steps starting from the install?

It looks like the router table itself is fine then.

Another thing to check might be the output of again comparing the working and broken sites.

SELECT * FROM cache_data WHERE cid LIKE 'route_provider.route_load%';

I don't think removing the o format unserialization is the issue, this is different to the O format.

However it does sound like it's the serialization between PHP 7.3 and PHP 7.4 that's breaking.

The main change between Drupal 8.9 and 9.0 is that the Symfony router (and CMF router additions) have been updated - they may be doing something differently which is causing unserialize to fail.

Can you check whether the serialized value in the database is different for:

1. Drupal 8.9
2. Drupal 9.0 with PHP 7.3 (i.e. when it's saved using PHP 7.3)
3. Drupal 9.0 with PHP 7.4 (i.e. when it's saved using PHP 7.4).

Yet another thing to check, would be instead of checking the site works when everything is on PHP 7.3, check it also works when everything is on PHP 7.4.

Could you also post the exact PHP versions installed?

Bumping to major for now.

So I copied and pasted the string in #17 into a simple PHP file, see attached.

It unserializes for me on PHP 7.4 but not on PHP 7.3 - but this is the reverse of what was reported in #17?

$ php7.3 --version
PHP 7.3.15-3+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Feb 23 2020 07:23:33) ( NTS )

$ php7.3 unserialize.php 
PHP Warning:  Erroneous data format for unserializing 'Symfony\Component\Routing\Route' in .../drupal/unserialize.php on line 4
PHP Notice:  unserialize(): Error at offset 42 of 1235 bytes in .../drupal/unserialize.php on line 4
bool(false)

$ php7.4 --version
PHP 7.4.4 (cli) (built: Mar 20 2020 13:47:45) ( NTS )

$ php7.4 unserialize.php 
object(Symfony\Component\Routing\Route)#5 (9) {
  ["path":"Symfony\Component\Routing\Route":private]=>
  string(5) "/node"
...

I've installed Drupal 8.9 on PHP 7.3 and the moved to Drupal 9.0 and done the upgrade on PHP 7.4 and didn't experience the problems.

However if I take the string in #17 use vendor/bin/drush php to unserialize it it works on PHP7.4 but not on PHP7.3. Nice.

Psy Shell v0.10.4 (PHP 7.4.6 — cli) by Justin Hileman
>>> unserialize('O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:5:"/node";s:4:"host";s:0:"";s:8:"defaults";a:5:{s:11:"_controller";s:47:"Drupal\views\Routing\ViewPageController::handle";s:6:"_title";s:0:"";s:7:"view_id";s:9:"frontpage";s:10:"display_id";s:6:"page_1";s:30:"_view_display_show_admin_links";b:1;}s:12:"requirements";a:2:{s:11:"_permission";s:14:"access content";s:7:"_format";s:4:"html";}s:7:"options";a:8:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:18:"_view_argument_map";a:0:{}s:23:"_view_display_plugin_id";s:4:"page";s:26:"_view_display_plugin_class";s:38:"Drupal\views\Plugin\views\display\Page";s:30:"_view_display_show_admin_links";b:1;s:16:"returns_response";b:0;s:14:"_access_checks";a:1:{i:0;s:23:"access_check.permission";}s:4:"utf8";b:1;}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:12:"#^/node$#sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:5:"/node";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:5:"/node";s:8:"numParts";i:1;}}');
=> Symfony\Component\Routing\Route {#4098}

Psy Shell v0.10.4 (PHP 7.3.18 — cli) by Justin Hileman
>>> unserialize('O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:5:"/node";s:4:"host";s:0:"";s:8:"defaults";a:5:{s:11:"_controller";s:47:"Drupal\views\Routing\ViewPageController::handle";s:6:"_title";s:0:"";s:7:"view_id";s:9:"frontpage";s:10:"display_id";s:6:"page_1";s:30:"_view_display_show_admin_links";b:1;}s:12:"requirements";a:2:{s:11:"_permission";s:14:"access content";s:7:"_format";s:4:"html";}s:7:"options";a:8:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:18:"_view_argument_map";a:0:{}s:23:"_view_display_plugin_id";s:4:"page";s:26:"_view_display_plugin_class";s:38:"Drupal\views\Plugin\views\display\Page";s:30:"_view_display_show_admin_links";b:1;s:16:"returns_response";b:0;s:14:"_access_checks";a:1:{i:0;s:23:"access_check.permission";}s:4:"utf8";b:1;}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:12:"#^/node$#sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:5:"/node";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:5:"/node";s:8:"numParts";i:1;}}');
PHP Warning:  Erroneous data format for unserializing 'Symfony/Component/Routing/Route' in /Users/alex/dev/sites/drupal8alt.deveval()'d code on line 1
PHP Notice:  unserialize(): Error at offset 42 of 1235 bytes in /Users/alex/dev/sites/drupal8alt.deveval()'d code on line 1
=> false

xpost with @longwave and snap :)

So I can reproduce the bug - kinda. If I install Drupal 9.0 on PHP 7.4 (upgrading from D8 doesn't matter). Visit the site everything is working nicely. If I then downgrade PHP to 7.3 it breaks with exactly the same error. I clear the caches use drush and everything is fine again. I then update PHP back to 7.4 and the bug does not occur and everything is fine.

There is a note in the PHP 7.4 incompatible changes list that might be relevant here:

"ArrayObject, ArrayIterator, SplDoublyLinkedList and SplObjectStorage now support the __serialize() and __unserialize() mechanism in addition to the Serializable interface. This means that serialization payloads created on older PHP versions can still be unserialized, but new payloads created by PHP 7.4 will not be understood by older versions."

So we can do something like this to at least not end up with a WSOD but it looks really tricky.

Actually I think this is related to https://wiki.php.net/rfc/custom_object_serialization

"If a class both implements Serializable and __serialize()/__unserialize(), then serialization will prefer the new mechanism, while unserialization can make use of either, depending on whether the C (Serializable) or O (__unserialize) format is used. As such, old serialized strings encoded in C format can still be decoded, while new strings will be produced in O format."

All classes involved here implement both __serialize()/__unserialize() and the Serializable interface. On PHP 7.4 they are encoded in the O format, which PHP 7.3 doesn't know how to unserialize again.

Yep S3 Router object implements Serializable but not the methods, it's the combination of both in S4 that is causing the PHP 7.3 vs. 7.4 compatibility issue.

I don't have a better idea than #25 at the moment (with a longer explanatory comment).

Yep definitely needs a better comment.

Other things I thought about:

• Maybe we could set router rebuild flag and then redirect back to self. Didn't pursing this because potential for looping redirects and rebuild happens on terminate which means it might not have started by the time the next request occurs.
• Where at which point to catch the error in the backtrace. I felt the router class made sense and the match method. But I'm not sure.

@NigelCunningham I agree. Addressing this specific case like we do #25 doesn't feel right and there can be other problems.

I think what we could do is stored the version PHP the container is compiled with and if they mismatch then throw an exception and tell people what's occurred and to visit rebuild.php.

I don't think we should try to do any automatic fixing.

I considered whether we should add PHP_VERSION to \Drupal\Core\DrupalKernel::getContainerCacheKey() but rebuilding the container is not enough here so I don't think that's a way forward.

The patch https://www.drupal.org/files/issues/2020-06-04/3145563-23.patch worked for me, for PHP 7.4.5.
Thanx @alexpott.

It would have been useful if PHP had added a php.ini flag or extra option for serialize() to preserve the PHP 7.3 behaviour, then we could have used that and switched only when we dropped support for PHP 7.3.

Preventing PHP version downgrades without a rebuild seems sensible, although it should only be for minor PHP version mismatches.

I asked

Beyond saying don’t do that, has anyone come up with a good way to deal with a \Symfony\Component\Routing\CompiledRoute gets serialized to a database from a PHP 7.4 instance and a PHP 7.3 instance is used to read it. PHP 7.4 can read PHP 7.3 serialized stuff but not vice versa due to https://wiki.php.net/rfc/custom_object_serialization (edited)

in Symfony slack...

dkarlovi:
Are those specific versions a hard requirements? In that case, I'd add a 7.3 compatible serializer step

nicolasgrekas:
Instead of serializing the routes, can't you serialize the array returned for CompiledUrlMatcher?

nicolasgrekas:
Same for the generator btw

Re #29, this isn't a Drupal upgrade issue per se, Jess. the problem is more related to having a different PHP version for your CLI vs the webserver

Any issue that causes problems when upgrading to a new version gets these tags, so that we can find and triage them appropriately. :) They are often database schema upgrade issues, but they are also sometimes other various compatibility issues or contrib blockers. So the tags are correct. Our goal is to understand what difficulties there are for upgrades in the ecosystem so that (a) others who encounter the same issues can locate the discussion and (b) so that we can triage them, resolve them ASAP in whatever manner is correct, and provide hotfixes or workarounds as needed.

@NigelCunningham the problem with the suggestion to use CompiledUrlMatcher in #35 is that we partially do route matching in the way we query the router from the DB so that's not going to work. So that leaves implementing a custom serializer. At which point I'm left wondering whether the idea of storing the php version in the container and erroring out when run on a lesser version of PHP is the best way to go.

@NigelCunningham I'm not convinced that the additional query to the state system is what we want on every request. That's why I was thinking of adding this as a container parameter when DrupalKernel rebuilds the container. And whilst we've identified this concrete problem we serialize other things so this could crop up anywhere.

I was getting the same error using PHP 7.3. Upgraded from Drupal 8 and Installed with composer. The site ran okay until drush cr was run and then WSOD with the website encountered an unexpected error. Please try again later. I have posted apache error.log below.

@ #40 patch works

Thank you.

Got error 'PHP message: TypeError: Argument 2 passed to Symfony\\Component\\Routing\\RouteCollection::add() must be an instance of Symfony\\Component\\Routing\\Route, bool given, called in /var/www/demo/dkone-20200610/web/core/lib/Drupal/Core/Routing/RouteProvider.php on line 382 in /var/www/demo/dkone-20200610/vendor/symfony/routing/RouteCollection.php on line 74

got the error with Drupal 9.0.1 after downgrading PHP to 7.3 from 7.4.
#25 fixed the issue.

I think I am seeing this on Drupal 8.9.2 on PHP 7.4.8 using Pantheon's 7.4 config: https://v74-php-info.pantheonsite.io/

Like gurunathan, the patch in #25 was a godsent. After an arduous recreation of my Drupal 8 website because the simple transition from Drupal 8 to Drupal 9 isn't if you use many modules, I found that on my LAMP server was set at the latest of everything but I found that my hosting site is always lagging the world and in this case PHP 7.3. After changing so many things to use PHP 7.3 on the LAMP server, I had a Drupal 9.0.2 website that wouldn't work. I hate patching things, really prefer Composer updates, but I prefer even more seeing my website running again. Thanks alexpott.

The original keeps the compiled route so let's do that too. The performance penalty of the reflection is not significant, it's certainly much, much less than recompiling. Note this is doable without reflection but I am not 100% it's worth it: https://gist.github.com/chx/4e3b6b1467ae578bb6b0196d6078dc4a

As with #45, I am also seeing this problem with 8.9.2. WSOD after running drush cr

Is there a corresponding issue for D8?

A bit of a long shot, but I thought I would try the patch at #47 against 8.9.2. To my surprise it did actually apply, but after running drush cr a different error is returned.

Fatal error: Uncaught ArgumentCountError: Too few arguments to function Symfony\Component\Routing\Route::__construct(), 0 passed in /var/www/html/web/core/lib/Drupal/Core/Routing/RouteProvider.php on line 507 and at least 1 expected in /var/www/html/vendor/symfony/routing/Route.php:53
Stack trace:
#0 /var/www/html/web/core/lib/Drupal/Core/Routing/RouteProvider.php(507): Symfony\Component\Routing\Route->__construct()
#1 /var/www/html/web/core/lib/Drupal/Core/Routing/RouteProvider.php(383): Drupal\Core\Routing\RouteProvider->unserialize('O:31:"Symfony\\C...')
#2 /var/www/html/web/core/lib/Drupal/Core/Routing/RouteProvider.php(183): Drupal\Core\Routing\RouteProvider->getRoutesByPath('/store')
#3 /var/www/html/web/core/lib/Drupal/Core/Routing/Router.php(239): Drupal\Core\Routing\RouteProvider->getRouteCollectionForRequest(Object(Symfony\Component\HttpFoundation\Request))
#4 /var/www/html/web/core/lib/Drupal/Core/Routing/Router.php(123): Drupal\Core\Routing\Router->getInitialRouteCollection(Object(Symfony\Component\HttpFoundat in /var/www/html/vendor/symfony/routing/Route.php on line 53

@MrPaulDriver the specific issue with Symfony routing we don't think is in 8.9.x, however the general issue when downgrading from PHP 7.4 to 7.3 could affect other code such as contrib modules you have installed.

the specific issue with Symfony routing we don't think is in 8.9.x

Hmm. It's a bit confusing for me, only to say I am seeing exactly the same error message; as does @xeM8VfDh at #45

I also experienced this particular issue on 8.9 after downgrading PHP from 7.4 to 7.3.
Using the patch from #25 fixed the problem.

Thank you @orlando.thoeny. Using the patch from #25 fixed the problem for me too.

It does appear that this issue can effect both 8 and 9.

I have same issue after install Drush 10.3 (composer require 'drush/drush') on site with Drupal 9.03 and PHP 7.3.

Patch #25 fixed the problem for me.

we was have yesterday the same issue with drupal 9.0.6
from one minute to another, the production website was broken and we became the follow error. Patch #25 and drush cr solve the problem. We use 7.3.22

The website encountered an unexpected error. Please try again later.
TypeError: Argument 2 passed to Symfony\Component\Routing\RouteCollection::add() must be an instance of Symfony\Component\Routing\Route, bool given, called in /home/xyz/webroot/core/lib/Drupal/Core/Routing/RouteProvider.php on line 382 in Symfony\Component\Routing\RouteCollection->add() (line 74 of /home/xyz/vendor/symfony/routing/RouteCollection.php).
Symfony\Component\Routing\RouteCollection->add('entity.node.canonical', ) (Line: 382)
Drupal\Core\Routing\RouteProvider->getRoutesByPath('/node/4') (Line: 182)
Drupal\Core\Routing\RouteProvider->getRouteCollectionForRequest(Object) (Line: 237)
Drupal\Core\Routing\Router->getInitialRouteCollection(Object) (Line: 121)
Drupal\Core\Routing\Router->matchRequest(Object) (Line: 92)
Drupal\Core\Routing\AccessAwareRouter->matchRequest(Object) (Line: 112)
Symfony\Component\HttpKernel\EventListener\RouterListener->onKernelRequest(Object, 'kernel.request', Object) (Line: 78)
Symfony\Component\EventDispatcher\LegacyEventDispatcherProxy->dispatch(Object, 'kernel.request') (Line: 134)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 191)
Drupal\page_cache\StackMiddleware\PageCache->fetch(Object, 1, 1) (Line: 128)
Drupal\page_cache\StackMiddleware\PageCache->lookup(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 115)
Drupal\shield\ShieldMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 705)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I just ran into this problem with a new build of Drupal 9.0.7 and then I used a new version of composer (version 2....) to install webform.

composer require 'drupal/webform:^6.0@alpha'
  vendor/drush/drush/drush en webform
  composer require drush/drush
  vendor/drush/drush/drush en webform
  vendor/drush/drush/drush updb
  vendor/drush/drush/drush cr

And it went south. I applied patch #25 and it works again. Sigh.

Thanks!

I commented #43 so just an update.

I have been working a few sites and have found that this only happens when you run drush cr

I have

manually installed/ then updated site 9.0.6 -> 9.0.7 -> 9.1.0 -> CLI update / update.php and then Flush cache in UI / No problem on all updates
composer installed/ then updated site 9.0.6 -> 9.0.7 -> 9.1.0 ->composer update / update.php and then Flush cache in UI / No problem on all updates

on the above composer site drush cr breaks it, but patch #40 fixes it
drush versions 10.2.2 and on 9.1.0 sites 10.3.6

Other composer sites w/ Drush workflow that are in production still break as I mentioned above at #43 but patch #40 fixes it

So it seems like it is something to do with the Drush cr.

Hope that helps in some way.

I hit this also

Just add this here
9.1.0 -> 9.1.2 composer with drush cr

no longer issue as outlined in #57 or #43

the only difference was dependencies updated, could that effect it?
- Updating symfony/polyfill-php73 (v1.20.0 => v1.22.0): Downloading (100%)
- Updating symfony/polyfill-php72 (v1.20.0 => v1.22.0): Downloading (100%)

PHP version 7.3.23-4+ubuntu18.04.1+deb.sury.org+1

Updating the polyfills does not fix the issue for me (but #25 does).

#25 worked for me

I confirm having the same issue with Layout Builder serialization in Drupal 9.1.x under PHP 7.4
Patch #25 is working
Thank you :)

Drupal 9.1.4 site runs in DDEV container served with PHP 7.3
- Running drush cr on host with PHP 7.3 is fine.
- Running drush cr on host with PHP 7.4 causes WSOD.

TypeError: Argument 2 passed to Symfony\Component\Routing\RouteCollection::add() must be an instance of Symfony\Component\Routing\Route, bool given, called in /var/www/html/web/core/lib/Drupal/Core/Routing/RouteProvider.php on line 380 in Symfony\Component\Routing\RouteCollection->add() (line 74 of /var/www/html/vendor/symfony/routing/RouteCollection.php).

- Apply 3145563-23.patch.txt
- Running drush cr on host with PHP 7.4 works as expected.

#25 fixes on 7.3.18-1+0~20200515.59+debian8~1.gbp12fa4f as well

10+ confirmation on #25 in the last 10 months. What needs to be done to resolve this "major" issue?

Per #27 and #28, the patch in #25 needs a better explanatory comment before it can be committed.

Hmm ... would something like this be acceptable:

   // Catch changes in PHP serialization bewteen 7.3 & 7.4 (https://www.drupal.org/project/drupal/issues/3145563)
    try {
      $collection = $this->getInitialRouteCollection($request);
    }
    catch (\TypeError $e) {
      \Drupal::service('router.builder')->rebuild();
      $collection = $this->getInitialRouteCollection($request);
    }

Commenting is important but I feel like it's better to include a fix with passable commenting then spending a few year debating symantics about wording. :shrug:

I just installed Drupal 9.1.6, PHP 7.3.9, OOTB vanilla install, and the front page crashes which what AFAICT is this problem

> TypeError: Argument 2 passed to Symfony\Component\Routing\RouteCollection::add() must be an instance of Symfony\Component\Routing\Route, bool given

Shouldn't this be a critical?

> Shouldn't this be a critical?
Well it breaks the site, but around #30 most people think its not a Drupal problem but a "dont change PHP versions and run drush cr"

> I just installed Drupal 9.1.6, PHP 7.3.9, OOTB vanilla install, and the front page crashes which what AFAICT is this problem
I just install Drupal 9.1.6, PHP 7.3.27 via composer and ran a "drush si" command to install the site and the front page worked fine. Did you use the Drush command? Did you switch PHP versions?

@joachim, what other steps did you do that lead to the problem? Based on your description, I was unable to replicate your encounter.

I'm seeing it with a site set up with https://github.com/joachim-n/drupal-core-development-project. But strangely, only on one of my machines! On the other machine, that Composer project template works perfectly.

I can reproduce the unserialisation problem very simply:

1. Open the DB and the {router} table
2. Find the view.frontpage.page_1 route
3. Copy the route data. In mine, it's this:

O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:5:"/node";s:4:"host";s:0:"";s:8:"defaults";a:5:{s:11:"_controller";s:47:"Drupal\views\Routing\ViewPageController::handle";s:6:"_title";s:0:"";s:7:"view_id";s:9:"frontpage";s:10:"display_id";s:6:"page_1";s:30:"_view_display_show_admin_links";b:1;}s:12:"requirements";a:2:{s:11:"_permission";s:14:"access content";s:7:"_format";s:4:"html";}s:7:"options";a:8:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:18:"_view_argument_map";a:0:{}s:23:"_view_display_plugin_id";s:4:"page";s:26:"_view_display_plugin_class";s:38:"Drupal\views\Plugin\views\display\Page";s:30:"_view_display_show_admin_links";b:1;s:16:"returns_response";b:0;s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:23:"access_check.permission";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:12:"#^/node$#sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:5:"/node";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:5:"/node";s:8:"numParts";i:1;}}

In index.php, after the autoloader is loaded, do this:

$route = 'O:31:"Symfony\Component\Routing\Route":9:{s:4:"path";s:5:"/node";s:4:"host";s:0:"";s:8:"defaults";a:5:{s:11:"_controller";s:47:"Drupal\views\Routing\ViewPageController::handle";s:6:"_title";s:0:"";s:7:"view_id";s:9:"frontpage";s:10:"display_id";s:6:"page_1";s:30:"_view_display_show_admin_links";b:1;}s:12:"requirements";a:2:{s:11:"_permission";s:14:"access content";s:7:"_format";s:4:"html";}s:7:"options";a:8:{s:14:"compiler_class";s:33:"Drupal\Core\Routing\RouteCompiler";s:18:"_view_argument_map";a:0:{}s:23:"_view_display_plugin_id";s:4:"page";s:26:"_view_display_plugin_class";s:38:"Drupal\views\Plugin\views\display\Page";s:30:"_view_display_show_admin_links";b:1;s:16:"returns_response";b:0;s:4:"utf8";b:1;s:14:"_access_checks";a:1:{i:0;s:23:"access_check.permission";}}s:7:"schemes";a:0:{}s:7:"methods";a:2:{i:0;s:3:"GET";i:1;s:4:"POST";}s:9:"condition";s:0:"";s:8:"compiled";O:33:"Drupal\Core\Routing\CompiledRoute":11:{s:4:"vars";a:0:{}s:11:"path_prefix";s:0:"";s:10:"path_regex";s:12:"#^/node$#sDu";s:11:"path_tokens";a:1:{i:0;a:2:{i:0;s:4:"text";i:1;s:5:"/node";}}s:9:"path_vars";a:0:{}s:10:"host_regex";N;s:11:"host_tokens";a:0:{}s:9:"host_vars";a:0:{}s:3:"fit";i:1;s:14:"patternOutline";s:5:"/node";s:8:"numParts";i:1;}}';
unserialize($route);

This should work because the autoloader is now loaded, so all the classes for the serialised objects can be found.

But instead it fails with this error:

> Warning: Erroneous data format for unserializing 'Symfony\Component\Routing\Route'

Googling that gets me this Doctrine issue https://github.com/doctrine/orm/issues/3897 which says:

What happens now when a class that implements \Serializable is that a "Warning: Erroneous data format for unserializing" shows up and the function unserialize() returns false.

That is because a class that implements \Serializable is expected to have the letter 'C' in the serialize string instead of the letter 'O'.

I wonder if something wacky is going on on my system with CLI PHP (running when I installed the site with Drush, not sure if it's from the OS or MAMP) and web PHP (MAMP) not being the same version.

EDIT: Yup, I think that's it. Drush is getting PHP 7.4.2, while the web is using 7.3.9 from MAMP. So routes are being serialised in one version of PHP and unserialised in another and BOOM. It worked with a straight git clone of Drupal core because I didn't have Drush there, so I installed Drupal in the web UI -- hence same version of PHP throughout.

@joachim using different PHP versions on CLI and the your server is not really supported - this is one very obvious problem but there other ways in which things can go wrong.

But I think that doing the work around in #25 is fine - if you are flip-flopping between PHP versions you'll suffer a massive performance regression but at things won't be broken. But someone still needs to add a better explanatory comment as #67

One month later, last "composer update" brought me back here again.
#25 fixed

> @joachim using different PHP versions on CLI and the your server is not really supported - this is one very obvious problem but there other ways in which things can go wrong.

Indeed. This was accidental -- I symlink MAMP's php executable into my ~/bin, which was 7.4 at the time, and then more recently I switched MAMP's setting from 7.4 to 7.3 because of some module or other which was causing deprecation errors. I forgot to update the symlink!

The patch fixes the crash for me on my wonky setup.

I'll try to find time to add the required comment.

Actually, nope, I have NO idea what this patch is doing.

-      $result[$name] = unserialize($route);
+      $result[$name] = $this->unserialize($route);
     }

     return $result;
@@ -529,4 +530,18 @@ protected function getCurrentLanguageCacheIdPart() {
     return $this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_URL)->getId();
   }

+  /**
+   * @param string $route
+   *
+   * @return \Symfony\Component\Routing\Route
+   */
+  protected function unserialize($route): \Symfony\Component\Routing\Route {
+    $decoded = json_decode($route);

We used to call unserialize() and now we do json_decode(). How does that even work?

@joachim it's the patch in #25 that we could put in with a decent comment.

Oops! I just ran dorgflow to get the patch locally and forgot it's not the latest one on the issue.... thanks! :)

Here's the patch wit the expanded comment.

(Removed)

Thanks @joachim! The comment looks good to me, the mentions of the PHP version should mean that we find this eventually and can remove it when we no longer support PHP prior to 7.4.

Committed/pushed to 9.3.x, 9.2.x, and 9.1.x, thanks!

Since we only have one report of this being an issue on 8.9.x, going to mark this fixed against 9.x for now. 8.9.x is only really getting critical bug fixes at this point, however if we do get more confirmation of this being an issue there, could be persuaded to backport.

Just confirming:
* code in #25 fixed twince my D9 site
* my D9 site PHP was never downgraded

getInitialRouteCollection needs a proper error handling here, obviously. While cause of failure should be digged somewhere else.

Thanks for recent progress so far!

@afagioli the only known case where this happens is where a mismatch of PHP versions are used. If you do php -v on the command line do you see the same version of PHP as you see on the site's status report (on admin/reports/status). An alternative is that the site is being built from a database dump that we exported on different version of PHP.

makes sense to me, @alexpott
Maybe this should be also integrated in the comment.
In my own case, no recent DB import from outside.

Thanks again!

Has anyone solved this whiout drush patch?
I don`t have too much experience with drupal and was working local, on 7.3 php 5.7 mysql on wamp. I had to upgrade my rig and when i install wamp i`dont realice that 7.3 and 7.4 will have this isuue,
Now on local with 7.4.31 and 5.7 i have being having this issue when i tried to upload on a test domain on my server.
Any help will be apreceated.
Cheers

Thanks @alexpott & @joachim, The patch is working fine with D9.1.x versions (9.1.8)

@Estebancena, Try to apply the patch from composer.json file. Like this
"patches": {
"drupal/core": {
"Route serialization incompatibilities between PHP 7.4 and 7.3 (9.x only)" : "https://www.drupal.org/files/issues/2021-05-10/3145563-78.drupal.Route-s..."
}
},
& run composer install

#78 - Patched file code perfectly working.
thank you @joachim

Just an FYI, any recent release of D9.1.x / D9.2.x will not require this patch.

D9.3.0 and higher does not require a patch for fixing this

Thanks to everyone for resolving this.

I may have used this patch "off label", but I had to apply it against 8.9.19 in order to update my server to PHP7.4. Worked like a charm!

Hello.
I have updated to drupal 9.2.10
PHP 7.3.21
MySql 8.0.23
Apache 2.4.46

And i have this warning. And when I deploy to production server, the navegator shows: The website encountered an unexpected error. Please try again later.
How can i Fix it?

Thanks

Warning: Erroneous data format for unserializing 'Symfony\Component\Routing\Route' en Drupal\Core\Routing\RouteProvider->getRoutesByPath() (línea 380 de D:\Drupal\portales-d9\portal-compras\web\core\lib\Drupal\Core\Routing\RouteProvider.php)
#0 D:\Drupal\portales-d9\portal-compras\web\core\includes\bootstrap.inc(312): _drupal_error_handler_real(2, 'Erroneous data ...', 'D:\\Drupal\\p...', 380)
#1 [internal function]: _drupal_error_handler(2, 'Erroneous data ...', 'D:\\Drupal\\p...', 380, Array)
#2 D:\Drupal\portales-d9\portal-compras\web\core\lib\Drupal\Core\Routing\RouteProvider.php(380): unserialize('O:31:"Symfony\\C...')
#3 D:\Drupal\portales-d9\portal-compras\web\core\lib\Drupal\Core\Routing\RouteProvider.php(180): Drupal\Core\Routing\RouteProvider->getRoutesByPath('/admin/reports/...')
#4 D:\Drupal\portales-d9\portal-compras\web\core\lib\Drupal\Core\Routing\Router.php(238): Drupal\Core\Routing\RouteProvider->getRouteCollectionForRequest(Object(Symfony\Component\HttpFoundation\Request))
#5 D:\Drupal\portales-d9\portal-compras\web\core\lib\Drupal\Core\Routing\Router.php(111): Drupal\Core\Routing\Router->getInitialRouteCollection(Object(Symfony\Component\HttpFoundation\Request))
#6 D:\Drupal\portales-d9\portal-compras\web\core\lib\Drupal\Core\Routing\AccessAwareRouter.php(92): Drupal\Core\Routing\Router->matchRequest(Object(Symfony\Component\HttpFoundation\Request))
#7 D:\Drupal\portales-d9\portal-compras\vendor\symfony\http-kernel\EventListener\RouterListener.php(112): Drupal\Core\Routing\AccessAwareRouter->matchRequest(Object(Symfony\Component\HttpFoundation\Request))
#8 [internal function]: Symfony\Component\HttpKernel\EventListener\RouterListener->onKernelRequest(Object(Symfony\Component\HttpKernel\Event\RequestEvent), 'kernel.request', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#9 D:\Drupal\portales-d9\portal-compras\web\core\lib\Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher.php(142): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\RequestEvent), 'kernel.request', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))

If you are running 9.2.10 you should consider one of the two options:

lock psr/container at 1.1.1 temporarily until you can upgrade to php 7.4

or, upgrade to php 7.4 immediately

or revert your recent changes (to what you had prior to 9.2.10).

Solution #95 works for me. I upgraded to PHP 7.4

Hi people, I had this issue and none previous patch solve my problem, after trying many options, I solved this issue following this Steps.

1. truncate table router in database:

TRUNCATE TABLE router;

2. truncate all cache tables, prevously i've identified all cache tables listing tables in database.

TRUNCATE TABLE  cache_advagg                           ;
TRUNCATE TABLE  cache_bootstrap                        ;
TRUNCATE TABLE  cache_config                           ;
TRUNCATE TABLE  cache_container                        ;
TRUNCATE TABLE  cache_data                             ;
TRUNCATE TABLE  cache_default                          ;
TRUNCATE TABLE  cache_discovery                        ;
TRUNCATE TABLE  cache_dynamic_page_cache               ;
TRUNCATE TABLE  cache_entity                           ;
TRUNCATE TABLE  cache_jsonapi_normalizations           ;
TRUNCATE TABLE  cache_menu                             ;
TRUNCATE TABLE  cache_page                             ;
TRUNCATE TABLE  cache_render                           ;
TRUNCATE TABLE  cache_rest                             ;
TRUNCATE TABLE  cache_schema_metatag_cache             ;
TRUNCATE TABLE  cache_toolbar                          ;
TRUNCATE TABLE  cachetags ;

3. Execute router rebuild using druhs.

drush ev "\Drupal::service('router.builder')->rebuild()"

4. Clear Cache

drush cr