This issue is resolved by release of Drupal 8.6.9

Problem/Motivation

Updating from 8.6.7 (or less) to 8.6.8 (or greater) is broken. If you use update.php you can not perform the update. If you use drush then you will see PHP warnings and errors. For example, Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167 and TypeError: Argument 1 passed to Drupal\Core\Extension\ExtensionList::Drupal\Core\Extension\{closure}() must be an instance of Drupal\Core\Extension\Extension.

Fix

  1. Upgrade to Drupal 8.6.8
  2. Use core/update.php - follow the update instructions

Note do not use Drush 8's updatedb or pm-update commands - Drush 9 works fine.

Workarounds

If you have drush or console installed you can clear the cache. For example $ drush cr

Or if you don't you can use the rebuild script. You can do this by:
Either

  1. Edit settings.php and add the line $settings['rebuild_access'] = TRUE; to the bottom of the file
  2. Visit the URL core/rebuild.php on your site
  3. Remove $settings['rebuild_access'] = TRUE; from settings.php

Or

  1. Run the rebuild token calculator from the command line $ php ./core/scripts/rebuild_token_calculator.sh which will output something like timestamp=1549546961&token=9CPufgezJuLFvSNJcbKnGzNLN-bgpBdob3lXMoJF8F3
  2. Visit the URL core/rebuild.php?timestamp=1549546961&token=9CPufgezJuLFvSNJcbKnGzNLN-bgpBdob3lXMoJF8F3 on your site

Proposed resolution

This happens because of #2701829: Extension objects should not implement \Serializable. If we detect stale extension objects we need to force a cache clear. In order to support Drush 8 and Drush 9 plus core's update.php we have to put this protection in both UpdateKernel and update_fix_compatiblity(). This is because

  • update_fix_compatiblity() is too late for update.php
  • UpdateKernel is not used by Drush 8

Remaining tasks

User interface changes

None

API changes

A new @internal static method on UpdateKernel.

Data model changes

None

Release notes snippet

@todo

Original report

Getting multiple copies of this error after upgrading all my sites from Drupal 8.6.7 to Drupal 8.6.8:

mysite.com/public_html
**************************
Cache rebuild complete.                                                                             [ok]
Update information last refreshed: Wed, 02/06/2019 - 10:26
 Name    Installed Version  Proposed version  Message          
 Drupal  8.6.7              8.6.8             Update available 


Code updates will be made to drupal core.
WARNING:  Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt.  If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.
Note: Updating core can potentially break your site. It is NOT recommended to update production sites without prior testing.

Do you really want to continue? (y/n): y
Project drupal was updated successfully. Installed version is now 8.6.8.
Backups were saved into the directory                                                               [ok]
/home/trevor/drush-backups/mysite_com/20190206182619/drupal.
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
The following theme is missing from the file system:  bootstrap.inc:276                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                   [warning]
Creating default object from empty value ModuleHandler.php:236                                      [warning]
No database updates required    

Afterward the theme of the site (In my case, Bootstrap) seems to be corrupted. The problem seems to go away after a "drush cr".

Relevant errors in the logs:

Warning: Class Drupal\Core\Extension\Extension has no unserializer in Drupal\Component\Serialization\PhpSerialize::decode() (line 21 of /var/www/drupal8/mysite.com/public_html/core/lib/Drupal/Component/Serialization/PhpSerialize.php) #0 /var/www/drupal8/mysite.com/public_html/core/includes/bootstrap.inc(584): _drupal_error_handler_real(2, 'Class Drupal\\Co...', '/var/www/drupal...', 21, Array) #1 [internal function]: _drupal_error_handler(2, 'Class Drupal\\Co...', '/var/www/drupal...', 21, Array) #2 /var/www/drupal8/mysite.com/public_html/core/lib/Drupal/Component/Serialization/PhpSerialize.php(21): unserialize('a:6:{s:6:"barti...') #3

CommentFileSizeAuthor
#144 3031128-144-test-fail.patch862 byteshchonov
#144 3031128-144-test-fail.patch862 byteshchonov
#41 3031128-3-41.patch246.67 KBalexpott
#41 37-41-interdiff.txt782 bytesalexpott
#37 3031128-3-37.patch246.48 KBalexpott
#37 30-37-interdiff.txt2.86 KBalexpott
#30 3031128-3-30.patch244.94 KBalexpott
#30 29-30-interdiff.txt5.25 KBalexpott
#29 3031128-3-29.patch240.91 KBalexpott
#29 3031128-3-29.test-only.patch239.68 KBalexpott
#29 22-29-interdiff.txt2.1 KBalexpott
#23 3031128-2-22.patch240.38 KBalexpott
#23 3031128-2-22.test-only.patch239.35 KBalexpott
#15 3031128-2-15.patch104.36 KBalexpott
#15 3031128-2-15.test-only.patch103.46 KBalexpott
#15 10-15-interdiff.txt2.22 KBalexpott
#10 3031128-2-10.patch105.2 KBalexpott
#10 3031128-2-10.test-only.patch103.46 KBalexpott
#8 3031128-8.patch1.74 KBalexpott
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

TrevorBradley created an issue. See original summary.

cilefen’s picture

Berdir’s picture

Yes, a cache clear is necessary, there is no other way.

TrevorBradley’s picture

Would a cache clear in advance of the update prevent the errors, or are the errors unavoidable?

Berdir’s picture

A cache clear would already fill them again with code on based on the old version, so that won't help.

To avoid the error, what you can try is drush up without running updates (--check-updatedb=0, on my version anyway), then drush cr, then drush updb.

TrevorBradley’s picture

Eh, probably not worth stressing about. Still a bit spooky to see errors on a core update.

In summary - the problems associated with the error can be resolved by running a cache clear with "drush cr" after the update.

cilefen’s picture

Based on this report, @xjm added this to the release notes.

alexpott’s picture

Status: Active » Needs review
FileSize
1.74 KB

Oh noes. As @cilefen noted this is due to #2701829: Extension objects should not implement \Serializable. I've tried a few ways to determine we're moving from 8.6.7 to 8.6.8 but I'm not sure that's a great path to go down.

Here's what I've come up with that works. If the Drupal version changes we are going to do a container rebuild because the container cache key changes. Therefore what we can do is if there is a container rebuild we can look to see if we can access $container->get('cache.bootstrap')->get('system.list') - if it unserializes fine and we can get a cache entry - all good move. If it is empty or broken (there's no PHP 5 way to tell the difference - if we were PHP 7 only we could catch the Error) then we can delete all caches and rebuild the theme data. This allows the system to fix itself.

The downsides of this approach are that the caches are emptied more than once when calling drupal_rebuild() or drupal_flush_all_caches(). Given that this is just a few extra db queries at a time when you have 100s I'm not sure that that is a problem and drupal_rebuild() already empties the caches twice :)

We really need to add an upgrade db with warm caches.

larowlan’s picture

Anyway we can add a test for this?

alexpott’s picture

@larowlan yep! was just working on that.

alexpott’s picture

The test only patch is the interdiff :)

jibran’s picture

Is it only happening once and after cache is rebuild it is gone? I think we need to udpdate the title here to mention something about updating core. Also IS says errors but these are just warnings.

+++ b/core/lib/Drupal/Core/DrupalKernel.php
@@ -1646,4 +1657,20 @@ protected function getInstallProfile() {
+    if (!@$container->get('cache.bootstrap')->get('system.list')) {

Do we really want to use @ here? Should we replace it with try catch?

alexpott’s picture

Title: Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167 » Update from 8.6.7 to 8.6.8 warnings - Drupal\Core\Extension\Extension has no unserializer
Priority: Normal » Major

Do we really want to use @ here? Should we replace it with try catch?

As we still support PHP5 I don't think that is possible for PHP warnings... there's no Error class / Throwables in PHP5 as fas as I know.

And whilst they are warnings I was seeing the site un-themed as a result so that's more of an error. Given there is a work around of clearing the cache I think this is major rather than critical.

alexpott’s picture

Priority: Major » Critical

@jibran asked a good question in chat.

why can't we just add an update hook and clear the cache?

If you:

  1. install 8.6.7
  2. log in as user 1
  3. update to 8.6.8
  4. visit update.php -> see lots of warnings - ignore them
  5. -> get stuck on the selection page.

For me this makes this critical.

alexpott’s picture

@jibran ask another good question in chat

should the fix only happen in `\Drupal\Core\Update\UpdateKernel`?

Yep that's totally possible. Also I realised that to be both 8.7.x and 8.6.x compat we need to check the extension list module cache because system_list is gone in 8.7.x.

Re-uplaoding the test-only patch - it is the same but it feels good to keep on adding it when the patch has changed a bit.

alexpott’s picture

+++ b/core/lib/Drupal/Core/Update/UpdateKernel.php
@@ -190,4 +190,21 @@ protected function handleAccess(Request $request) {
+      // Also rebuild themes because it uses state as cache.
+      $this->container->get('theme_handler')->refreshInfo();

Note this is not true in 8.7.x but is in 8.6.x - this can be removed in the patch for 8.7.x

zenimagine’s picture

Hello I have already updated to Drupal 8.6.8 and I also have these warnings.
With drush it corrects the problem.
Should I restore my server? Or can I continue to use drupal normally ?

The last submitted patch, 10: 3031128-2-10.test-only.patch, failed testing. View results

alexpott’s picture

@zenimagine a cache clear with drush is the same thing that is being implemented here - there is no need to downgrade. We trying to make the drush cache clear unnecessary.

+++ b/core/lib/Drupal/Core/Update/UpdateKernel.php
@@ -190,4 +190,21 @@ protected function handleAccess(Request $request) {
+    // If the module list is broken or empty at this point do not trust any
+    // cache.
+    if (!@$this->container->get('cache.default')->get('core.extension.list.module')) {

I'm not convinced this is the correct condition yet - I think it might be empty in the warm cache db. I think what we need to check is if we have a system_list cache entry and if so is it corrupt. Because in order to have this error you have to have been on 8.6.7 or below - we don't need to worry about 8.7.x yet because that's not supported - so if you go from 8.6.7 straight to 8.7.0 or even from 8.5.10 to 8.7.0 this will work.

The last submitted patch, 8: 3031128-8.patch, failed testing. View results

The last submitted patch, 10: 3031128-2-10.patch, failed testing. View results

The last submitted patch, 15: 3031128-2-15.test-only.patch, failed testing. View results

alexpott’s picture

So I think I've come up with the most elegant way of only clearing the caches when necessary. The code to clear the caches is now

    $callable = function () {
      foreach ($this->container->getParameter('cache_bins') as $service_id => $bin) {
        $this->container->get($service_id)->deleteAll();
      }
      // Also rebuild themes because it uses state as cache.
      $this->container->get('theme_handler')->refreshInfo();
    };
    // If the system list is broken the cache has been built by a version of
    // Drupal <= 8.6.7 and we're running on Drupal >= 8.6.8.
    set_error_handler($callable, E_ERROR | E_WARNING);
    $this->container->get('state')->get('system.theme.data', []);
    restore_error_handler();

$this->container->get('state')->get('system.theme.data', []); will only error when it's being built by <= 8.6.7 and we trying to read it on Drupal >= 8.6.8 then we know we need to clear everything. If there is no error because you're on 8.6.8 and its been rebuilt - or your are on 8.7.0 and you've never been on 8.6.x or earlier then there is no error because this doesn't exist.

No interdiff because it is the quoted php above and I've regenerated the DB dump. I did this because when I built is the caches were not quite as warm as they should have been - I had not visited the site.

Status: Needs review » Needs work

The last submitted patch, 23: 3031128-2-22.patch, failed testing. View results

larowlan’s picture

  1. +++ b/core/lib/Drupal/Core/Update/UpdateKernel.php
    @@ -190,4 +190,24 @@ protected function handleAccess(Request $request) {
    +      $this->container->get('theme_handler')->refreshInfo();
    

    should we also output something to let the user know what happened?

    should we call the normal error handler too so things get logged in system logs etc

  2. +++ b/core/lib/Drupal/Core/Update/UpdateKernel.php
    @@ -190,4 +190,24 @@ protected function handleAccess(Request $request) {
    +    set_error_handler($callable, E_ERROR | E_WARNING);
    +    $this->container->get('state')->get('system.theme.data', []);
    

    this is crafty - nice

cilefen’s picture

Metztli’s picture

Relevant to this matter, I see this entry in my httpd (Apache) error log file:

[Wed Feb 06 21:58:20.798480 2019] [php7:notice] [pid 17503] [client my.ip.on.line:54992] TypeError: Argument 1 passed to Drupal\\Core\\Extension\\ExtensionList::Drupal\\Core\\Extension\\{closure}() must be an instance of Drupal\\Core\\Extension\\Extension, instance of stdClass given in /usr/local/httpd/htdocs/core/lib/Drupal/Core/Extension/ExtensionList.php on line 443 #0 [internal function]: Drupal\\Core\\Extension\\ExtensionList->Drupal\\Core\\Extension\\{closure}(Object(stdClass))\n#1 /usr/local/httpd/htdocs/core/lib/Drupal/Core/Extension/ExtensionList.php(445): array_map(Object(Closure),Array)
\n#2 /usr/local/httpd/htdocs/core/lib/Drupal/Core/Extension/ExtensionList.php(422): Drupal\\Core\\Extension\\ExtensionList->recalculatePathnames()\n#3
/usr/local/httpd/htdocs/core/lib/Drupal/Core/Extension/ExtensionList.php(519): Drupal\\Core\\Extension\\ExtensionList->getPathnames()\n#4 /usr/local/httpd/htdocs/core/includes/bootstrap.inc(247): Drupal\\Core\\Extension\\ExtensionList->getPathname('standard')\n#5 /usr/local/httpd/htdocs/core/includes/
bootstrap.inc(293): drupal_get_filename('module', 'standard')\n#6 /usr/local/httpd/htdocs/core/includes/module.inc(134): drupal_get_path('module', 'standard')\n#7 /usr/local/httpd/htdocs/core/includes/module.inc(93): module_load_include('install', 'standard')\n#8 /usr/local/httpd/htdocs/core/includes/
install.inc(83): module_load_install('standard')\n#9 /usr/local/httpd/htdocs/core/modules/system/src/Controller/DbUpdateController.php(146): drupal_load_updates()\n#10 [internal function]: Drupal\\system\\Controller\\DbUpdateController->handle('info', Object(Symfony\\Component\\HttpFoundation\\Request
))\n#11 /usr/local/httpd/htdocs/core/lib/Drupal/Core/Update/UpdateKernel.php(114): call_user_func_array(Array, Array)\n#12 /usr/local/httpd/htdocs/core
/lib/Drupal/Core/Update/UpdateKernel.php(75): Drupal\\Core\\Update\\UpdateKernel->handleRaw(Object(Symfony\\Component\\HttpFoundation\\Request))\n#13 /
usr/local/httpd/htdocs/update.php(28): Drupal\\Core\\Update\\UpdateKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request))\n#14 {main}

Thanks.

alexpott’s picture

re #26 @cilefen you're right - not just semantically similar - it's the same issue just caused by a slightly different issue - loading the profile extension list. The patch would solve that too.

alexpott’s picture

Status: Needs work » Needs review
FileSize
2.1 KB
239.68 KB
240.91 KB

Here's a fix for the 8.6.x problem. It's occurring because the test runner does a config write via \Drupal\Core\Test\FunctionalTestSetupTrait::initConfig which calls \Drupal\system\EventSubscriber\ConfigCacheTag::onSave which loads themes. Somewhat amusingly the ConfigCacheTag::onSave is doing it wrong but that is a separate issue which I'll open later.

I've also updated the code comments to address #25 and hopefully be very clear about what is going on.

alexpott’s picture

We can implement \Drupal\Core\Test\FunctionalTestSetupTrait::initConfig() at a lower level for this test and make it easy for other update tests to use if they need in the future.

indigoxela’s picture

I'm afraid, we're not there yet. I still see errors, when updating from 8.6.7 to 8.6.8 on a testing web:

# drush updb
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
The following theme is missing from the file system:  bootstrap.inc:276                                                          [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                [warning]
Creating default object from empty value ModuleHandler.php:236                                                                   [warning]
Creating default object from empty value ModuleHandler.php:236                                                                   [warning]
No database updates required                                                                                                     [success]

These are the same warnings as without the patch.

How I did the update:
Downloaded latest Drupal release as tar.gz, unpacked it in a different directory and patched it there with 3031128-3-30.patch, re-packed it, unpacked that tar.gz over the testing web, ran "drush updb".

The above warnings occured. And the themes (Bartik and Seven) looked broken. I confirmed, the code change from 3031128-3-30.patch was there, but it didn't solve the problem.

Then I ran "drush cr" and "drush updb". No more errors, theme is looking good again.

Version information:

  • PHP 7.0
  • drush 8.1.18
  • additional contrib modules: admin_toolbar
  • additional themes: none
alexpott’s picture

@indigoxela are you sure? On drush 9.4.0 that does not happen for me.

If I

  1. install minimal on 8.6.7
  2. change to 8.6.8
  3. run drush updb -> see lots of errors

If I

  1. install minimal on 8.6.7
  2. change to 8.6.8 + patch
  3. run drush updb -> success no errors.

Going to try with drush 8.1.18

mkolar’s picture

We have same problem with 8.6.7 to 8.6.8 update, I got this TypeError during update https://www.drupal.org/project/drupal/issues/3031208.. drush cr helped (but thrown this unserializer warning)..

The last submitted patch, 29: 3031128-3-29.test-only.patch, failed testing. View results

alexpott’s picture

Confirm the issue with drush 8.1.18 - this is because in drush 8 it does not use UpdateKernel when triggering updatedb. For me this does not invalidate the current approach. If you are using drush 8.x.x you have a workaround - you can clear the cache - you're also on a drush that will not be supported for much longer. If you don't use drush you can get stuck on in update UI which is way way worse.

indigoxela’s picture

@alexpott: sure, the drush version I used is not the latest, but remember that people on shared webhosting sometimes don't have a possibility to upgrade drush. It's not ideal to assume, all people have the latest version.

Gave updating another try in a different way: via browser (running update.php).

Same problems: Themes look broken at first, but look OK after "update.php". And the exact same warnings are in the dblog.

alexpott’s picture

Here's a patch that will allow Drush 8 to fix the situation. You're still going to get some warnings but now after running updatedb they are all gone. I think this might be the best we can do.

@indigoxela when I use the patch attached here I don't see any theme corruption after doing:

  • Install standard on 8.6.7
  • Log in as user 1
  • Update code to 8.6.8 + patch and visit update.php - yes you need to visit update.php - but there's no way we can get around that.
indigoxela’s picture

Here's a patch that will allow Drush 8 to fix the situation.

@alexpott: "drush cr" with drush version 8.1.18 already fixes the situation (with warnings), this is also the case without any patch applied.

Another note on Drush versions: if people still need support for D7 (or even D6), they are bound to drush version 8. See http://docs.drush.org/en/master/install/#drupal-compatibility for details.

Regarding update via browser:

Update code to 8.6.8 + patch and visit update.php

I can confirm: when no other page is visited before running "update.php" via browser, there are no warnings in dblog.

alexpott’s picture

Created an issue for the ConfigCacheTag problem observed whilst fixing this - #3031302: \Drupal\system\EventSubscriber\ConfigCacheTag is trying to clear render cache for THEME_NAME.settings changes but it does not work

@indigoxela yep drush cr will fix all this problem completely (regardless of drush version) the latest patch in #37 yes doesn't need that if you do "drush up" to upgrade from 8.6.7 to the version this patch lands in - which I think is a good improvement because it's not for sure that everyones deployment process includes a "drush cr" just to incase too fix things (although many probably do).

catch’s picture

Patch looks good to me and worth hotfixing for. I'm happy to roll a release either tomorrow (Friday) or Monday - we should allow at least today to see if any other regressions flush out though and to get this RTBC and committed.

I think we should add @todos to remove this code 8.8.x or 8.9.x when we can reasonably expect sites to have run the update and open a follow-up to do so, otherwise it looks like a good workaround to me.

alexpott’s picture

Patch adds a @todo and I created #3031322: Remove \Drupal\Core\Update\UpdateKernel::fixSerializedExtensionObjects() once 8.6.x is not supported - I think only adding it the new method is okay because once that is gone the test and the calls to it will fail.

alexpott’s picture

Issue summary: View changes

Updated the issue summary.

alexpott’s picture

Issue summary: View changes

Adding workarounds.

alexpott’s picture

Issue summary: View changes
alexpott’s picture

Issue summary: View changes
jppo’s picture

Hello,

Yesterday I get the same problem with many messages such as :
Class Drupal\Core\Extension\Extension has no unserializer ...
I will try to clear caches before and after installation of 8.6.8.

Regards
JP P

alexpott’s picture

Issue summary: View changes

Added more workaround with less editing.

catch’s picture

Status: Needs review » Reviewed & tested by the community

Patch looks good to me now. I'm RTBC-ing but it could use a third committer to commit it, or a third person to review it..

jibran’s picture

Patch looks great. I just have one question why can't we have two patches one for 8.6 and one for 8.7 that way we don't have to worry about #3031322: Remove \Drupal\Core\Update\UpdateKernel::fixSerializedExtensionObjects() once 8.6.x is not supported?

catch’s picture

That's because 8.6 is supported for a total of one year, i.e. until 8.8.0 comes out. We don't officially support jumping minor releases for updates, but someone theoretically could do that, so to be extra nice we should only remove this workaround in 8.9.x - and neither 8.8 nor 8.9 are open yet.

tjtj’s picture

The real question is why this was not found before the release? It causes much anxiety for D8 administrators for no reason. I luckily tried drush cr for lack of nay other ideas.

alexpott’s picture

@tjtj that's a great point. I've opened #3031379: Add a new test type to do real update testing to start to explore a technical way we can do update testing more in the spirit of our users to real site updates.

catch’s picture

Version: 8.6.8 » 8.6.x-dev
Status: Reviewed & tested by the community » Fixed

Committed and pushed bf21c00101 to 8.7.x and 5b52c41801 to 8.6.x. Thanks!

  • catch committed bf21c00 on 8.7.x
    Issue #3031128 by alexpott, TrevorBradley, indigoxela, catch, cilefen,...

  • catch committed 5b52c41 on 8.6.x
    Issue #3031128 by alexpott, TrevorBradley, indigoxela, catch, cilefen,...
TrevorBradley’s picture

Whoa, that exploded quickly. Thanks, awesome Drupal community!

Jens Peter’s picture

Before running this, I wonder if the error is only there when using Drush?
I do not do this but just add the files and run update.php.
Will this make a problem that I need to know about?

Metztli’s picture

Applied @catch's commit 5b52c41 patch to drupal-8.6.8 with fuzz=0

Then proceeded to update normally using update.php

Update procedure went smooth.

Thank you, all!

saparker’s picture

Any ideas please on how to clear the cache (or switch the theme) when I get this error and drush won't do anything without triggering this error and I can't use the web interface (as that just says "The website encountered an unexpected error. Please try again later.")

Egmund’s picture

saparker, my way was to revert back to older version 8-6-7 (in cpanel), then check in here. Then I had an open session ready to clear cache (via admin settings performance) - changed the files to new ver 8.6.8 and clicked 'clear cache'. And all was fine.

adminMN2023’s picture

Jens Peter - Yes - you will still have the issue.
I can't really retrace what I did exactly because it happened so fast - but I got the error on my dev site which I was not expecting after I went to update.php (I do everything via cpanel).

The error came up and I went back a page using my browser arrows. It gave me a broken admin panel (like the template was corrupt).

Worked my way to the cache, cleared it, and the issue fixed itself. Sorry I can't be more specific. I won't attempt it on my production site until the issue is finally fixed. Hope this helps.

Jens Peter’s picture

CB1_Dru1, thank you.
I am talking about live sites so will give it some time to see if it will not be solved.
I cannot understand why a release is not tested for this before being released.

I will keep an eye here to see what will show up.

indigoxela’s picture

To avoid misunderstandings: yes, this was a problem when updating to 8.6.8.

This is NOT a problem anymore, when updating to 8.6.9 - the issue has been fixed with today's release.

Just tested again on a dev web: updating from 8.6.7 to 8.6.9 works flawlessly.

alexpott’s picture

Issue summary: View changes
alexpott’s picture

Issue summary: View changes
TrevorBradley’s picture

Uh oh...

I tried updating my dev environment to 8.6.9 this morning (from 8.6.7), and still get "Extension has no unserializer" error messages during updb

Class Drupal\Core\Extension\Extension has no unserializer PhpSerialize.php:21                       [warning]
Class Drupal\Core\Extension\Extension has no unserializer PhpSerialize.php:21                       [warning]
Class Drupal\Core\Extension\Extension has no unserializer PhpSerialize.php:21                       [warning]
Class Drupal\Core\Extension\Extension has no unserializer PhpSerialize.php:21                       [warning]
Class Drupal\Core\Extension\Extension has no unserializer PhpSerialize.php:21                       [warning]
Class Drupal\Core\Extension\Extension has no unserializer PhpSerialize.php:21                       [warning]
The following theme is missing from the file system:  bootstrap.inc:276  

Note that it's not the same PHP file (DatabaseBackend.php vs PhpSerialize.php). There are also fewer errors than last time.

I tried rolling back and updating to 8.6.8+patch-41, and similarly got these messages. My apologies for not jumping on the patch and testing it sooner!

Others here suggested it might be a Drush 8 vs 9 issue. I am running drush 8. If I "composer require drush/drush:9" and try again, I don't see unserializer error messages. (Though my Drush 9 environment looks a bit messed up - I had to run the update from the web url).

tmanhollan’s picture

I'm experiencing a problem that I believe is related to this, but with symptoms that haven't been reported yet and that are not addressed by the current fix. Like others have reported, I get the warnings after a move from 8.6.7 or less to 8.6.8. As others have noted, immediately rebuilding the cache avoids the problem. Using today's release (going from 8.6.7) also avoids the problem, but only with drush 9.

What I don't think has been reported yet has to do with the use of a non-standard installation profile. If I don't avoid the problem on upgrade (i.e., if I run `drush updb` or visit the UI without first rebuilding the cache), the problem surfaces on the status report page: "Notice: Undefined index: name in system_requirements() (line 52 of core/modules/system/system.install)" and "Notice: Undefined index: version in system_requirements() (line 54 of core/modules/system/system.install)" and the "Installation Profile" line on the status report lists the correct profile's machine name but without the details that would normally be present (human-readable name and version).

If I avoid the initial warnings by rebuilding the cache before anything else, this condition never occurs. But if I DON'T avoid the initial problem, the subsequent problem with the profile is persistent through cache rebuilds and environment reboots -- it doesn't go away, which is why I'm concerned that although the condition is avoidable it may be a symptom of a larger problem.

This is reproducible on a clean install of 8.6.7 using a profile other than standard, but I did have to enable some local dev settings to match my other project to get it to surface -- essentially most of what's in the example.settings.local.php (although I think it was the verbose error reporting that was the key). My projects use a custom profile, but I tested a clean install with demo_umami and the behavior was the same.

TrevorBradley’s picture

Relevant to @tmanhollan's comment: I'm also using a custom install profile.

(Not sure if it would break with the "minimal" install profile)

translector’s picture

I can confirm that this is working fine after updating to 8.6.9 on Acquia Cloud, using the lightning profile and BLT.

Cheers.

TrevorBradley’s picture

@translector: Which version of Drush are you using?

Our current theory is that it may be a Drush 8 issue, (possibly also related to a custom install profile)

alexpott’s picture

@TrevorBradley yes you still get the message whilst upgrading with Drush 8 but what has changed for Drush 8 is that by the end of the updb it is fixed. This was not the case before. It's not possible to fix this in a way for Drush 8 that will fix all the warnings thrown.

TrevorBradley’s picture

Good enough for me. :) Thanks @alexpott.

tmanhollan’s picture

@alexpott, the update does improve things when using drush 8. However, something I didn't catch in my previous comment is that running `drush updb` (with drush 8) without a cache rebuild produces an error on the status report page. It is the same TypeError mentioned in the issue description and the error and stack trace are printed and the rest of the page fails to render. I just ran a couple more tests and unlike the other problem I described, this error happens with the standard profile as well. Rebuilding the cache fixes that, but the problem I described in #67 remains.

alexpott’s picture

@tmanhollan thanks for the extra info - yep I experience exactly the same thing using Drush 8. Doing a cache rebuild does fix it - so that's good.

alexpott’s picture

@tmanhollan here's a fix #3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility() - that also seems to fix all the warnings in Drush 8 too! (I seem to be wrong about that but it does fix the status report)

John Pitcairn’s picture

I've just updated a site from 8.6.7 to 8.6.9 in dev, and run drush updatedb from the command line (Drush 9). That produced the expected warnings, and everything appears fine after a cache clear now, except:

If I visit the top-level configuration page at /admin/config I get these 2 notices:

Notice: Undefined index: name in system_requirements() (line 52 of core/modules/system/system.install).
system_requirements('runtime')
call_user_func_array('system_requirements', Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 112)
Drupal\system\SystemManager->listRequirements() (Line: 96)
Drupal\system\SystemManager->checkRequirements() (Line: 102)
Drupal\system\Controller\SystemController->overview('system.admin_config')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
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: 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: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Notice: Undefined index: version in system_requirements() (line 54 of core/modules/system/system.install).
system_requirements('runtime')
call_user_func_array('system_requirements', Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler->invokeAll('requirements', Array) (Line: 112)
Drupal\system\SystemManager->listRequirements() (Line: 96)
Drupal\system\SystemManager->checkRequirements() (Line: 102)
Drupal\system\Controller\SystemController->overview('system.admin_config')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
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: 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: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Egmund’s picture

I just updated a 'live' site from 8.6.7 to 8.6.9 by exchanging the files w. new version in cpanel filemanager. Same problem as with updating (other sites) to 8.6.8 (extension errors, messed up theme, site encountered an error - try later).

This is getting somewhat serious guys.

Running the update.php fixes the site. Have not checked whether errors continue in log.

Egmund’s picture

Status: Fixed » Needs work

I reset this issue to 'need work' since it is not fixed.

Or I could of course open a new bug report.

The info on the page with drupal cores is misleading. "Stable and well tested"? Not so. Both 8.6.8 and 8.6.9 might be stable, but can not be installed without crashing many sites. So: "Well tested"? NOT!

indigoxela’s picture

There really seems to be a problem. The weird thing is: I can't reproduce it.

In my installs there aren't any problems with warnings on status page or /admin/config.

I always run update.php or drush updb (depending on hosting) - even if I know, there aren't any actual database changes.
And my installs are regular ones, no special profile or distribution.

This needs some more digging...

alexpott’s picture

Status: Needs work » Fixed

@Egmund thank you for report and additional concerns. However, this issue should not be re-opened because as your report says:

Running the update.php fixes the site. Have not checked whether errors continue in log.

It is update.php’s job to fix data structures after a codebase update, and until that is done, the site may experience errors. This is why the update instructions recommend putting your site in maintenance mode prior to upgrading.

If your continued testing does find other issues opening additional bug reports would be appreciated. Note there already is one follow-up to deal with upgrading using Drush 8 - see #3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility()

Re #76 @John Pitcairn thanks for the report. Can you provide some more information like exactly which Drush version you are using because as #79 points out this does not appear to be reproducible. It might also be worth seeing if #3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility() addresses your issue. Note that thaat patch would have to be applied before running your update.

alexpott’s picture

@John Pitcairn thinking about #76 some more - if you are using drush 9 updating from 8.6.7 to 8.6.9 should not produce any warnings at all whilst running the updatedb command. So I think a key piece of information is the precise Drush version - you can find this by running drush --version.

mkaand’s picture

I use 8.6.7 and it is impossible to upgrade 8.6.9 via just copying vendor and core folders. Something is wrong with 8.6.9. I am waiting for next release.

Egmund’s picture

Thank you alexpott,
But this problem is new with D 8.6.8 & 8.6.9 - never had it before that I need to be ready to run update.php in advance (i.e. the theme would come up fine, so I could run update 'from inside').

tmanhollan’s picture

@alexpott, thank you for your work on #3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility(). I'll test and leave feedback on that issue.

catch’s picture

@Egmund #83 not every single update results in errors before update.php is run, but any update could - that's why we always recommending update.php immediately and putting the site into maintenance mode.

Egmund’s picture

I understand catch. I have been sloppy in my previous updates (for many years).

johnvenpin’s picture

8.6.7 to 8.6.9 upgrade then warnings - Drupal\Core\Extension\Extension has no unserializer etc
then 500 Internal Server Error error -
have tried downgrading and still the 500 internal server error -
looks like my Saturday night is going to be fun.

alexpott’s picture

@johnvenpin and other reporting new information on this issue. Thanks it is always useful to know that people are experiencing issues. Also it'd be really helpful if we can have more information so that we can try to reproduce the problems people are experiencing. Information that is useful includes:

  • How are you updating the code - composer / drush / tarball?
  • How are you running the database updates - drush command / visiting update.php?
  • If using Drush what is the output of drush --version
  • Are you using a custom or contrib install profile - i.e. not standard or minimal?
John Pitcairn’s picture

@alexpott re #81 ... oops. Seems this particular dev site is pegged to Drush 9.0.0-beta4 because of a ridiculous old workflow script. Apologies for the noise.

alexpott’s picture

@John Pitcairn - it's great that you've worked out what was wrong and also reported it here - both the problem and the cause - others might benefit! Not noise and no need to be sorry.

alexpott’s picture

#3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility() Now has a more complete fix for updating via Drush 8 and it also has a script that can fix a site that has been updating with Drush 8 and the install profile has been removed from the module list.

Egmund’s picture

Tarball. Repacing core, vendor & files in root except .htaccess.
Here is from error.log:
TypeError: Argument 1 passed to Drupal\Core\Extension\ExtensionList::Drupal\Core\Extension\{closure}() must be an instance of Drupal\Core\Extension\Extension, instance of stdClass given in /home/havredalz/public_html/core/lib/Drupal/Core/Extension/ExtensionList.php on line 443 #0 [internal function]: Drupal\Core\Extension\ExtensionList->Drupal\Core\Extension\{closure}(Object(stdClass))

But: As pointed out, I was not 'following procedure'.

Can I help in other ways w. this issue? (I do have several sites to upgrade from 8.6.8 to 8.6.9)

alexpott’s picture

Issue summary: View changes

Adding notes to issue summary based on @Egmund's issues with upgrading and known problems.

TMWagner’s picture

Issue tags: +8.6.9 update

Appears that 8.6.9 did not fix the issue...

- Updating drupal/core (8.6.7 => 8.6.9): Loading from cache
Writing lock file
Generating autoload files
- .csslintrc (https://cgit.drupalcode.org/drupal/plain/.csslintrc?h=8.6.9): Downloading (100%)
- .editorconfig (https://cgit.drupalcode.org/drupal/plain/.editorconfig?h=8.6.9): Downloading (100%)
- .eslintignore (https://cgit.drupalcode.org/drupal/plain/.eslintignore?h=8.6.9): Downloading (100%)
- .eslintrc.json (https://cgit.drupalcode.org/drupal/plain/.eslintrc.json?h=8.6.9): Downloading (100%)
- .gitattributes (https://cgit.drupalcode.org/drupal/plain/.gitattributes?h=8.6.9): Downloading (100%)
- .ht.router.php (https://cgit.drupalcode.org/drupal/plain/.ht.router.php?h=8.6.9): Downloading (100%)
- .htaccess (https://cgit.drupalcode.org/drupal/plain/.htaccess?h=8.6.9): Downloading (100%)
- index.php (https://cgit.drupalcode.org/drupal/plain/index.php?h=8.6.9): Downloading (100%)
- robots.txt (https://cgit.drupalcode.org/drupal/plain/robots.txt?h=8.6.9): Downloading (100%)
- sites/default/default.services.yml (https://cgit.drupalcode.org/drupal/plain/sites/default/default.services....): Downloading (100%)
- sites/default/default.settings.php (https://cgit.drupalcode.org/drupal/plain/sites/default/default.settings....): Downloading (100%)
- sites/development.services.yml (https://cgit.drupalcode.org/drupal/plain/sites/development.services.yml?...): Downloading (100%)
- sites/example.settings.local.php (https://cgit.drupalcode.org/drupal/plain/sites/example.settings.local.ph...): Downloading (100%)
- sites/example.sites.php (https://cgit.drupalcode.org/drupal/plain/sites/example.sites.php?h=8.6.9): Downloading (100%)
- update.php (https://cgit.drupalcode.org/drupal/plain/update.php?h=8.6.9): Downloading (100%)
- web.config (https://cgit.drupalcode.org/drupal/plain/web.config?h=8.6.9): Downloading (100%)

cilefen’s picture

@TMWagner Does the command output you posted above illustrate a symptom of the problem? Might it have been truncated?

Skin’s picture

Same thing for me after updating from 8.6,7 to 8.6.9:

Project drupal was updated successfully. Installed version is now 8.6.9.
Backups were saved into the directory /root/drush-backups/pointnet_drupal8webdesign/20190211104532/drupal.                                                                    [ok]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
The following theme is missing from the file system:  bootstrap.inc:276                                                                                                       [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Class Drupal\Core\Extension\Extension has no unserializer DatabaseBackend.php:167                                                                                             [warning]
Creating default object from empty value ModuleHandler.php:236                                                                                                                [warning]
Creating default object from empty value ModuleHandler.php:236                                                                                                                [warning]
No database updates required                                                                                                                                                  [success]
alexpott’s picture

@Skin please see #88 - and also I think #3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility() because I think that the output you've put in your comments means you are using Drush 8 to update your code.

Skin’s picture

  • How are you updating the code: drush pm-update
  • How are you running the database updates:should be included in drush pm-update
  • If using Drush what is the output of drush --version: Drush Version : 8.1.17
  • Are you using a custom or contrib install profile - i.e. not standard or minimal? : Standard profile

After the update I noticed that I`ve lost the home link in the main menù, i don`t know if it is connected.

Mitch5713’s picture

Will this issue be fixed with 8.70??? Without having to jump through all these "hoops" ?????
I tried updating from 8.67 to 8.69 NO GOOD failure!!

here is the error i get :
OS: Linux a2ss23.a2hosting.com 2.6.32-896.16.1.lve1.4.54.el6.x86_64 #1 SMP Wed May 2 07:43:19 EDT 2018 x86_64 E_WARNING: Class Drupal\Core\Extension\Extension has no unserializer /home/softwear/public_html/NorthLandDrupal8/core/lib/Drupal/Core/Cache/DatabaseBackend.php 167 Callstack: -> unserialize('a:2:{s:5:"...') -> Drupal\Core\Cache\DatabaseBackend::prepareItem(stdClass(...) { ... }, false) -> Drupal\Core\Cache\DatabaseBackend::getMultiple(array(1) { ... }, false) -> Drupal\Core\Cache\DatabaseBackend::get(system_list(...)) -> system_list('theme') -> Drupal\Core\Extension\ThemeHandler::systemThemeList() -> Drupal\Core\Extension\ThemeHandler::listInfo() -> Drupal\Core\Theme\ThemeAccessCheck::checkAccess('NorthlandT...') -> Drupal\Core\Theme\ThemeNegotiator::determineActiveTheme(Drupal\Core\Routing\RouteMatch(...) { ... }) -> Drupal\Core\Theme\ThemeManager::initTheme(Drupal\Core\Routing\RouteMatch(...) { ... }) -> Drupal\Core\Theme\ThemeManager::getActiveTheme() -> Drupal\Core\Theme\Registry::init(NULL) -> Drupal\Core\Theme\Registry::getRuntime() -> Drupal\Core\Entity\EntityViewBuilder::getBuildDefaults(Drupal\node\Entity\Node(...) { ... }, 'full') -> Drupal\node\NodeViewBuilder::getBuildDefaults(Drupal\node\Entity\Node(...) { ... }, 'full') -> Drupal\Core\Entity\EntityViewBuilder::viewMultiple(array(1) { ... }, 'full', NULL) -> Drupal\Core\Entity\EntityViewBuilder::view(Drupal\node\Entity\Node(...) { ... }, 'full') -> Drupal\Core\Entity\Controller\EntityViewController::view(Drupal\node\Entity\Node(...) { ... }, 'full', NULL) -> Drupal\node\Controller\NodeViewController::view(Drupal\node\Entity\Node(...) { ... }, 'full', NULL) -> call_user_func_array(Drupal\node\Controller\NodeViewController->view, array(3) { ... }) -> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::Drupal\Core\EventSubscriber\{closure}() -> Drupal\Core\Render\Renderer::executeInRenderContext(Drupal\Core\Render\RenderContext(...) { ... }, Closure(...) { ... }) -> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::wrapControllerExecutionInRenderContext(Drupal\node\Controller\NodeViewController->view, array(3) { ... }) -> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::Drupal\Core\EventSubscriber\{closure}() -> Symfony\Component\HttpKernel\HttpKernel::handleRaw(Symfony\Component\HttpFoundation\Request(...) { ... }, 1) -> Symfony\Component\HttpKernel\HttpKernel::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\StackMiddleware\Session::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\StackMiddleware\KernelPreHandle::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\page_cache\StackMiddleware\PageCache::fetch(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\page_cache\StackMiddleware\PageCache::lookup(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\page_cache\StackMiddleware\PageCache::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\StackMiddleware\ReverseProxyMiddleware::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\StackMiddleware\NegotiationMiddleware::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Stack\StackedHttpKernel::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\DrupalKernel::handle(Symfony\Component\HttpFoundation\Request(...) { ... })

tim.plunkett’s picture

alexpott’s picture

@Mitch5713 I'm sorry the update didn't work for you. In order to help us help you and others in the same position - do you have any information on the failures you experienced? Was it due to #3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility()? Thanks

efpapado’s picture

Updating drupal/core (8.6.3 => 8.6.9)

it's still here.

alexpott’s picture

@efpapado if you are updating with Drush 8 you will still see notices. There's not much that can be done about that. Also if you did use Drush 8 there's #3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility(). You can confirm what problems you are experiencing after running update.php?

Mitch5713’s picture

here is the error i get :
OS: Linux a2ss23.a2hosting.com 2.6.32-896.16.1.lve1.4.54.el6.x86_64 #1 SMP Wed May 2 07:43:19 EDT 2018 x86_64 E_WARNING: Class Drupal\Core\Extension\Extension has no unserializer /home/softwear/public_html/NorthLandDrupal8/core/lib/Drupal/Core/Cache/DatabaseBackend.php 167 Callstack: -> unserialize('a:2:{s:5:"...') -> Drupal\Core\Cache\DatabaseBackend::prepareItem(stdClass(...) { ... }, false) -> Drupal\Core\Cache\DatabaseBackend::getMultiple(array(1) { ... }, false) -> Drupal\Core\Cache\DatabaseBackend::get(system_list(...)) -> system_list('theme') -> Drupal\Core\Extension\ThemeHandler::systemThemeList() -> Drupal\Core\Extension\ThemeHandler::listInfo() -> Drupal\Core\Theme\ThemeAccessCheck::checkAccess('NorthlandT...') -> Drupal\Core\Theme\ThemeNegotiator::determineActiveTheme(Drupal\Core\Routing\RouteMatch(...) { ... }) -> Drupal\Core\Theme\ThemeManager::initTheme(Drupal\Core\Routing\RouteMatch(...) { ... }) -> Drupal\Core\Theme\ThemeManager::getActiveTheme() -> Drupal\Core\Theme\Registry::init(NULL) -> Drupal\Core\Theme\Registry::getRuntime() -> Drupal\Core\Entity\EntityViewBuilder::getBuildDefaults(Drupal\node\Entity\Node(...) { ... }, 'full') -> Drupal\node\NodeViewBuilder::getBuildDefaults(Drupal\node\Entity\Node(...) { ... }, 'full') -> Drupal\Core\Entity\EntityViewBuilder::viewMultiple(array(1) { ... }, 'full', NULL) -> Drupal\Core\Entity\EntityViewBuilder::view(Drupal\node\Entity\Node(...) { ... }, 'full') -> Drupal\Core\Entity\Controller\EntityViewController::view(Drupal\node\Entity\Node(...) { ... }, 'full', NULL) -> Drupal\node\Controller\NodeViewController::view(Drupal\node\Entity\Node(...) { ... }, 'full', NULL) -> call_user_func_array(Drupal\node\Controller\NodeViewController->view, array(3) { ... }) -> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::Drupal\Core\EventSubscriber\{closure}() -> Drupal\Core\Render\Renderer::executeInRenderContext(Drupal\Core\Render\RenderContext(...) { ... }, Closure(...) { ... }) -> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::wrapControllerExecutionInRenderContext(Drupal\node\Controller\NodeViewController->view, array(3) { ... }) -> Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::Drupal\Core\EventSubscriber\{closure}() -> Symfony\Component\HttpKernel\HttpKernel::handleRaw(Symfony\Component\HttpFoundation\Request(...) { ... }, 1) -> Symfony\Component\HttpKernel\HttpKernel::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\StackMiddleware\Session::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\StackMiddleware\KernelPreHandle::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\page_cache\StackMiddleware\PageCache::fetch(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\page_cache\StackMiddleware\PageCache::lookup(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\page_cache\StackMiddleware\PageCache::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\StackMiddleware\ReverseProxyMiddleware::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\StackMiddleware\NegotiationMiddleware::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Stack\StackedHttpKernel::handle(Symfony\Component\HttpFoundation\Request(...) { ... }, 1, true) -> Drupal\Core\DrupalKernel::handle(Symfony\Component\HttpFoundation\Request(...) { ... })

alexpott’s picture

@Mitch5713 can you detail the upgrade steps you are taking? You will see this error on you site immediately after putting the new code in place. In order to fix this you need to visit update.php or run drush updb. You will also see this error before it is fixed when running drush updb using drush 8.

Mitch5713’s picture

I update my sites using Softaculous usually and it works fine, i get the error after the update when trying to log into the site to run update.php, so the error eixsts when trying to login after updating thanks

Mitch5713’s picture

the reason I do not use drush with Drupal8 is i was told not to becaause i use Softaculous to do the initial install and was told if i do that than i should stick with it for updates. An so far all have worked just fine until j\now???

Mitch5713’s picture

I have a "Sandbox" site in which i could use drush if i had the steps and docs needed to do it?

alexpott’s picture

@Mitch5713 - thanks for the info. Here are some steps that I think will work for you:

  1. change $settings['update_free_access'] = FALSE; to $settings['update_free_access'] = TRUE; in your sites/default/settings.php
  2. Go directly to your-site.com/update.php and runs the updates (this might not run an update but it will fix your site)
  3. change $settings['update_free_access'] = TRUE; to $settings['update_free_access'] = FALSE; in your sites/default/settings.php
cilefen’s picture

@alexpott I have sites that seem to be persistently stuck with this. I'll provide details as I collect them.

cilefen’s picture

It seems what I actually have is a very bad VM which is causing `drush updatedb` to die or timeout so that's nothing to do with this.

cilefen’s picture

IIRC a drush cache-rebuild followed by drush updatedb worked with Drush 8.

Mitch5713’s picture

thanks Alexpott if will give that a shot :)

Mitch5713’s picture

ok i ran the update received the error that i stated above. Went in and changed setting.php file as you suggested above, ran update.php and received this error:
OS: Linux a2ss23.a2hosting.com 2.6.32-896.16.1.lve1.4.54.el6.x86_64 #1 SMP Wed May 2 07:43:19 EDT 2018 x86_64 E_WARNING: Class Drupal\Core\Extension\Extension has no unserializer /home/softwear/public_html/Towners/core/lib/Drupal/Component/Serialization/PhpSerialize.php 21 Callstack: -> unserialize('a:10:{s:6:...') -> Drupal\Component\Serialization\PhpSerialize::decode('a:10:{s:6:...') -> Drupal\Core\KeyValueStore\DatabaseStorage::getMultiple(array(1) { ... }) -> Drupal\Core\State\State::getMultiple(array(1) { ... }) -> Drupal\Core\State\State::get('system.the...', array(0) { ... }) -> Drupal\Core\Update\UpdateKernel::fixSerializedExtensionObjects(Drupal\Core\DependencyInjection\ContainerBuilder(...) { ... }) -> Drupal\Core\Update\UpdateKernel::loadLegacyIncludes() -> Drupal\Core\DrupalKernel::preHandle(Symfony\Component\HttpFoundation\Request(...) { ... }) -> Drupal\Core\Update\UpdateKernel::handle(Symfony\Component\HttpFoundation\Request(...) { ... })

Mitch5713’s picture

Then i did as you suggested i logged into the site and all was fine it worked!! Im a little nervous to do this on my production sites, will this be addresses in the next version 8.7???
Many thanks

alexpott’s picture

@Mitch5713 unfortunately the warning is unavoidable depending on how you get to update.php or if you use drush 8. However once you are on 8.6.9 or the upcoming upcoming 8.6.10 you'll not have to go through the same process for 8.7.0. That said it is always possible that future updates require placing the site into maintenance, going to to update.php and exiting maintenance mode as this is the prescribed procedure. It just happens that this is not often required and a site will "work" (where work means responding to GET requests) whilst the update is in progress.

geerlingguy’s picture

geerlingguy’s picture

Eek, sorry about that, incorrect issue.

balintk’s picture

We ran into this issue, updated to 8.6.10 today from 8.6.7 using Drush 8. Clearing the cache and running database updates didn't help (tried all possible ways), while our theme remained corrupted. After reviewing the patch in this thread, we ended up executing this command, which fixed our site:

drush php-eval "require './core/includes/update.inc'; update_fix_compatibility();"

jcmartinez’s picture

I can confirm that going from 8.6.6 to 8.6.10 this weird message showed; however, drush updatedb ran without a glitch.

alexpott’s picture

@balintk I'm sorry that you experienced difficulties whilst applying the security update. #3031740: Updating to 8.6.8 or 8.6.9 with Drush 8 causes data loss via update_fix_compatibility() was included as a part of the security release to specifically resolve this problem for Drush 8 users. Some more information would be great to try to work out why running drush updatedb did not bring everything back to normal as it did for @jcmartinez. Things that would be interesting are which exact version of drush are you using (drush --version) and do you have any specialised caching modules enabled? Also I'm glad that you came up with a good workaround for you and thanks for sharing.

sozkara’s picture

I can confirm issues specifically with memcache module after updating to 8.6.10

alexpott’s picture

@sozkara thanks for the report. Yes memcache would have issues if doing the update via CLI because there is no way from the CLI to clear your memcache. In this instance running update.php via the web or doing an update and restarting your webservers is the way to go. This is true for all updates to core that affect the cache. Memcache makes this tricky. I was thinking of APCu :( hmm... I wonder why memcache has problems.

esod’s picture

We're also seeing the problem with a reference to memcache when updating from 8.6.7 to 8.6.10 :

The following updates are pending:

system module : 
  8601 -  Fix missing install profile after updating to Drupal 8.6.9 with Drush 8.

rest module : 
  Clear caches due to changes in route definitions.

Do you wish to run all pending updates? (y/n): y
Performing system_update_8601                                               [ok]
Class Drupal\Core\Extension\Extension has no unserializer              [warning]
MemcacheDriver.php:60
Class Drupal\Core\Extension\Extension has no unserializer              [warning]
MemcacheDriver.php:60
Class Drupal\Core\Extension\Extension has no unserializer              [warning]
MemcacheDriver.php:60

Post updating rest                                                          [ok]
Cache rebuild complete.                                                     [ok]
Finished performing updates.                                                [ok]

We're using drush version 8.1.18

Drush version                 :  8.1.18

We have the memcache module and the purge module on our system.

cilefen’s picture

@esod If I remember correctly, @alexpott mentioned a few times that those warnings will always display during this upgrade.

Mitch5713’s picture

alexpott: Thanks so much for your help, now that i have updated my sites successfully(with ur helP)to 8.69 is it necessary to update to 8.6.10? Or just wait for 8.7??

Mitch

alexpott’s picture

@Mitch5713 8.6.10 is a security update - see https://www.drupal.org/SA-CORE-2019-003

alexpott’s picture

@esod thanks for the info - can you confirm that your site was still experiencing after the database updates. The database updates are necessary to remove the warning and in some instances - for example using Drush 8 - will show the warning before there is a chance to fix it. This does not mean that the update has not fixed the problem.

seanB’s picture

I can confirm the warning still occurs after we updated one of our sites using memcache. All database updates have run successfully.
Not sure if this issue is better suited for the memcache module?

UPDATE: Restarting memcache seems to have solved the issue.

Warning: Class Drupal\Core\Extension\Extension has no unserializer in Drupal\memcache\Driver\MemcacheDriver->getMulti() (line 60 of /var/www/htdocs/modules/contrib/memcache/src/Driver/MemcacheDriver.php) #0 /var/www/htdocs/core/includes/bootstrap.inc(584): _drupal_error_handler_real(2, 'Class Drupal\\Co...', '/var/www/htdoc...', 60, Array) #1 [internal function]: _drupal_error_handler(2, 'Class Drupal\\Co...', '/var/www/htdoc...', 60, Array) #2 /var/www/htdocs/modules/contrib/memcache/src/Driver/MemcacheDriver.php(60): MemcachePool->get(Array) #3 /var/www/htdocs/modules/contrib/memcache/src/MemcacheBackend.php(84): Drupal\memcache\Driver\MemcacheDriver->getMulti(Array) #4 /var/www/htdocs/modules/contrib/memcache/src/MemcacheBackend.php(76): Drupal\memcache\MemcacheBackend->getMultiple(Array, false) #5 /var/www/htdocs/core/lib/Drupal/Core/Theme/ThemeInitialization.php(83): Drupal\memcache\MemcacheBackend->get('theme.active_th...') #6 /var/www/htdocs/core/lib/Drupal/Core/Theme/ThemeInitialization.php(73): Drupal\Core\Theme\ThemeInitialization->getActiveThemeByName('seven') #7 /var/www/htdocs/core/lib/Drupal/Core/Theme/ThemeManager.php(406): Drupal\Core\Theme\ThemeInitialization->initTheme('seven') #8 /var/www/htdocs/core/lib/Drupal/Core/Theme/ThemeManager.php(96): Drupal\Core\Theme\ThemeManager->initTheme(Object(Drupal\Core\Routing\RouteMatch)) #9 /var/www/htdocs/core/lib/Drupal/Core/Cache/Context/ThemeCacheContext.php(43): Drupal\Core\Theme\ThemeManager->getActiveTheme() #10 /var/www/htdocs/core/lib/Drupal/Core/Cache/Context/CacheContextsManager.php(118): Drupal\Core\Cache\Context\ThemeCacheContext->getContext(NULL) #11 /var/www/htdocs/core/lib/Drupal/Core/Render/RenderCache.php(307): Drupal\Core\Cache\Context\CacheContextsManager->convertTokensToKeys(Array) #12 /var/www/htdocs/core/lib/Drupal/Core/Render/RenderCache.php(66): Drupal\Core\Render\RenderCache->createCacheID(Array) #13 /var/www/htdocs/core/lib/Drupal/Core/Render/PlaceholderingRenderCache.php(109): Drupal\Core\Render\RenderCache->get(Array) #14 /var/www/htdocs/core/lib/Drupal/Core/Render/Renderer.php(263): Drupal\Core\Render\PlaceholderingRenderCache->get(Array) #15 /var/www/htdocs/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false) #16 /var/www/htdocs/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(226): Drupal\Core\Render\Renderer->render(Array, false) #17 /var/www/htdocs/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() #18 /var/www/htdocs/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(227): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #19 /var/www/htdocs/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(117): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch)) #20 /var/www/htdocs/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch)) #21 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #22 /var/www/htdocs/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #23 /var/www/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent)) #24 /var/www/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #25 /var/www/htdocs/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #26 /var/www/htdocs/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #27 /var/www/htdocs/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #28 /var/www/htdocs/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #29 /var/www/htdocs/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #30 /var/www/htdocs/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #31 /var/www/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #32 /var/www/htdocs/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #33 /var/www/htdocs/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #34 {main}.

allupaku’s picture

This error is still popping up and it is also breaking the rendering of of bootstrap theme, after upgrading from 8.6.9 to 8.6.10. This is usually breaking the rendering / cache rebuilding after a cron run. I have tried all the solutions mentioned in this thread here and dont see any change in the behavior. Can we reopen this issue. Drush version 8.1.18 , php 7.2 & 7.3 , Core 8.6.10 . Cache clearing will fix the issue , but will again break the rendering on next automated cron run. Any one else ?

webdrips’s picture

I can confirm this is still an issue, and we're not using memcache on this particular site.

Seems to be related to this error:

TypeError: Argument 1 passed to Drupal\Core\Theme\ThemeInitialization::loadActiveTheme() must be an instance of Drupal\Core\Theme\ActiveTheme, boolean given, called in /core/lib/Drupal/Core/Theme/ThemeInitialization.php on line 74 in Drupal\Core\Theme\ThemeInitialization->loadActiveTheme() (line 136 of /core/lib/Drupal/Core/Theme/ThemeInitialization.php) #0 /core/lib/Drupal/Core/Theme/ThemeInitialization.php(74): Drupal\Core\Theme\ThemeInitialization->loadActiveTheme(false) #1 /core/lib/Drupal/Core/Theme/ThemeManager.php(406): Drupal\Core\Theme\ThemeInitialization->initTheme('sophie') #2 /core/lib/Drupal/Core/Theme/ThemeManager.php(96): Drupal\Core\Theme\ThemeManager->initTheme(Object(Drupal\Core\Routing\RouteMatch)) #3 /core/lib/Drupal/Core/Theme/Registry.php(207): Drupal\Core\Theme\ThemeManager->getActiveTheme() #4 /core/lib/Drupal/Core/Theme/Registry.php(251): Drupal\Core\Theme\Registry->init(NULL) #5 /core/lib/Drupal/Core/Entity/EntityViewBuilder.php(175): Drupal\Core\Theme\Registry->getRuntime() #6 /core/modules/node/src/NodeViewBuilder.php(59): Drupal\Core\Entity\EntityViewBuilder->getBuildDefaults(Object(Drupal\node\Entity\Node), 'full') #7 /core/lib/Drupal/Core/Entity/EntityViewBuilder.php(138): Drupal\node\NodeViewBuilder->getBuildDefaults(Object(Drupal\node\Entity\Node), 'full') #8 /core/lib/Drupal/Core/Entity/EntityViewBuilder.php(111): Drupal\Core\Entity\EntityViewBuilder->viewMultiple(Array, 'full', NULL) #9 /core/lib/Drupal/Core/Entity/Controller/EntityViewController.php(97): Drupal\Core\Entity\EntityViewBuilder->view(Object(Drupal\node\Entity\Node), 'full') #10 /core/modules/node/src/Controller/NodeViewController.php(55): Drupal\Core\Entity\Controller\EntityViewController->view(Object(Drupal\node\Entity\Node), 'full', NULL) #11 [internal function]: Drupal\node\Controller\NodeViewController->view(Object(Drupal\node\Entity\Node), 'full', NULL) #12 /core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #13 /core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #14 /core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #15 /core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #16 /vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #17 /vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #18 /core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #19 /core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #20 /core/modules/page_cache/src/StackMiddleware/PageCache.php(184): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 /core/modules/page_cache/src/StackMiddleware/PageCache.php(121): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 /core/modules/page_cache/src/StackMiddleware/PageCache.php(75): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true) #23 /core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #24 /core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #25 /vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #26 /core/lib/Drupal/Core/DrupalKernel.php(669): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #27 /index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #28 {main}.

Notes on this site:

  1. Drupal version 8.6.10
  2. Extremely simple custom theme uses Bartik as base theme on a very simple site.
  3. Tried clearing caches, running updates, and #109/#119.

Nothing has worked to date.

sfdrummer’s picture

I too can confirm that this is happening on our sites. Same issue regarding Warning: Class Drupal\Core\Extension\Extension has no unserializer in Drupal\Component\Serialization\PhpSerialize::decode().

bajah1701’s picture

I too can confirm this is still an issue in 8.6.10. It completely crashes the site. I had to disable the web services module and all other custom modules that required it, in order to get the site working again.

webdrips’s picture

Status: Fixed » Active

@bajah1701, what modules did you wind up disabling? When you say "required it" what is the it?

We don't have the RESTful Web Services module enabled if that's what you mean.

Like you said, it completely "crashes" the site, with the styling being gone, and "No front page content has been created yet"

Setting this back to active

Thanks!

alexpott’s picture

Thanks everyone for the additional reports on this issue. It'd be great if someone can provide a reliable way to reproduce the problem with core and contrib. At the moment there are no steps to reproduce the problem so it hard to work out what is causing it. Things that might help are lists of installed modules - i.e. what's in the core.extension configuration.

@sfdrummer the full stack trace for #132 might useful.

webdrips’s picture

Sure thing! Edit I see you asked for the info in core.extension

module:
  action: 0
  admin_toolbar: 0
  admin_toolbar_links_access_filter: 0
  admin_toolbar_tools: 0
  automated_cron: 0
  backup_migrate: 0
  better_exposed_filters: 0
  big_pipe: 0
  block: 0
  block_content: 0
  book: 0
  breakpoint: 0
  captcha: 0
  ckeditor: 0
  color: 0
  comment: 0
  config: 0
  config_translation: 0
  contact: 0
  contextual: 0
  ctools: 0
  datetime: 0
  datetime_range: 0
  dblog: 0
  devel: 0
  dynamic_page_cache: 0
  editor: 0
  field: 0
  field_group: 0
  field_group_migrate: 0
  field_ui: 0
  file: 0
  filter: 0
  google_analytics: 0
  help: 0
  history: 0
  image: 0
  imce: 0
  jq_footnotes: 0
  language: 0
  link: 0
  locale: 0
  menu_firstchild: 0
  menu_ui: 0
  metatag: 0
  metatag_page_manager: 0
  metatag_views: 0
  migrate: 0
  migrate_d6_metatag_custom: 0
  migrate_drupal: 0
  migrate_drupal_multilingual: 0
  migrate_drupal_ui: 0
  migrate_plus: 0
  migrate_tools: 0
  migrate_upgrade: 0
  node: 0
  options: 0
  page_cache: 0
  page_manager: 0
  path: 0
  pdf_api: 0
  printable: 0
  printable_pdf: 0
  quickedit: 0
  rdf: 0
  redirect: 0
  search: 0
  shortcut: 0
  site_verify: 0
  superfish: 0
  system: 0
  taxonomy: 0
  text: 0
  token: 0
  toolbar: 0
  tour: 0
  update: 0
  user: 0
  views_aggregator: 0
  views_aggregator_more_functions: 0
  views_php: 0
  views_ui: 0
  xmlsitemap_custom: 0
  xmlsitemap_engines: 0
  filefield_sources: 1
  menu_link_content: 1
  pathauto: 1
  xmlsitemap: 1
  content_translation: 10
  views: 10
  standard: 1000
theme:
  stable: 0
  classy: 0
  bartik: 0
  seven: 0
  sophie: 0
profile: standard

All I can say for sure is the following:

  1. The site works fine for a few minutes after clearing all the caches
  2. Clearing caches individually using the Admin Toolbar module doesn't fix the issue
  3. Clearing the router cache causes the following error InvalidArgumentException: $string ("") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 132 of /core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php).
  4. See #131 for additional error I see frequently

I see a few other warnings/errors in the log, but it's difficult to tell if they might be related or not.

bajah1701’s picture

@webdrips
We built a notification module that requires web services and web services requires serialize both of which are provided by core. With both web services and serialize enabled the site crashes with just a white screen. Drupal logs shows nothing but apache logs return this below.

PHP Fatal error: Trait 'Drupal\\serialization\\Normalizer\\SerializedColumnNormalizerTrait' not found in
/var/www/drupal/apphome/core/modules/serialization/src/Normalizer/FieldItemNormalizer.php on line 14

With respect to the error you highlighted "TranslatableMarkup" I have come across this before from since Drupal 8.6.7. I deal with it by commenting the line with the error statement.

Peter Buchanan’s picture

I can reproduce the problem at will.

My upgrade is from 8.6.7 to 8.6.10, and I've spent many days thrashing though possible solutions.

I've a couple of other Drupal 8 sites, but not had problems with them. The obvious difference is that this site has commerce installed and running.

I did the upgrade on a test site so can play at will without upsetting anyone, and I can restore the site and try again;-)

webdrips’s picture

Just coming back to this, we finally found the issue after digging through countless error logs: the host had configure two settings.php files to point to the same database. The domain was the same between the two sites, but the subdomain was different.

Thus the site with the incorrect subdomain was being scraped by bots, and that was what kept causing issues.

I don't know what change in 8.6.10 was made that could have triggered this, but hopefully this is some clue.

kfritsche’s picture

The issue can also be reproduced with Drupal TestBot using latest patch from #1894286: System updates are executed without priority

catch’s picture

Status: Active » Fixed

Given that webdrips has confirmed this was a site configuration issue, and no-one else has explicitly confirmed this as an issue between 8.6.7 and 8.6.8 (as opposed to not updating to 8.6.7 yet), I'm going to go ahead and mark this fixed again. If you can reliable reproduce this on 8.6.8 please re-open with steps to reproduce though.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

hchonov’s picture

@kfritsche has pointed out a test fail on a d.o. issue in #140. In the patch there at the end of the setup method we retrieve the extension data indirectly through the call to update_check_incompatibility() which leads to the error by executing the following statement:
$modules = \Drupal::service('extension.list.module')->reset()->getList();.

The test that fails is the one that has been introduced here - WarmCacheUpdateFrom8dot6Test.

I think that this is a reliable reproduction of the problem.

hchonov’s picture

And here is a one line test showing that the problem still exists, therefore I am re-opening the issue.

alexpott’s picture

Status: Needs work » Fixed

@hchonov please do not re-open old Closed (fixed) issues like this. The only reason you are able to do that is because you are in maintainers.txt.

Using this service prior to updates being run is going to elicit the error. You have to run updates before using it. That is the only way to fix this issue. The updater has some logic in it to try to ensure that the service is works once the UpdateKernel is in place - see \Drupal\Core\Update\UpdateKernel::fixSerializedExtensionObjects(). The test added is not really proving anything other than without updates the service is broken - which we already know. If #1894286: System updates are executed without priority is causing the problem then that patch needs to change it's approach to account for this.

If there is an issue separate from what #1894286: System updates are executed without priority is doing then we should open a new issue.

hchonov’s picture

@hchonov please do not re-open old Closed (fixed) issues like this. The only reason you are able to do that is because you are in maintainers.txt.

@alexpott, I've done this according to @çatch's comment #141:

If you can reliable reproduce this on 8.6.8 please re-open with steps to reproduce though.

Using this service prior to updates being run is going to elicit the error. You have to run updates before using it. That is the only way to fix this issue.

I apologize, I didn't realise that.

alexpott’s picture

@hchonov no worries. Once an issue has moved from fixed to closed (fixed) we should only re-open in exceptional circumstances. If you can then reaching out in some chat medium before re-opening closed (fixed) issues is great - more than happy to discuss things like this :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Dropa’s picture

I'm not entirely sure why I got this error still now, but I just came across the same error when trying to import production database from yesterday. In both cases core version was the same 8.9.13.

Just in case someone else gets the same error when trying to do following:

drush sql-drop -y && drush sql-cli < production.sql && drush updb -y --no-post-updates && drush cim -y && drush updb -y && drush cr

And the config import fails with the same error as mentioned in original post

TypeError: Argument 1 passed to Drupal\Core\Extension\ExtensionList::Drupal\Core\Extension\{closure}() must be an instance of Drupal\Core\Extension\Extension, instance of stdClass given in Drupal\Core\Extension\ExtensionList->Drupal\Core\Extension\{closure}() (line 443 of /var/www/html/web/core/lib/Drupal/Core/Extension/ExtensionList.php).

It may be that it gets fixed by just running drush cr before config import, but in my case it did not, as the cache clear did die on another error (service dependency, which I'm not even sure why that happened, as the dependencies should be ok)

How I was able to fix the situation, was clearing all the caches from database before doing any other drush command after the db-import.

So in full, the command was this:

drush sql-drop -y && drush sql-cli < production.sql && drush sqlq "TRUNCATE cache_config;TRUNCATE cache_container;TRUNCATE cache_data;TRUNCATE cache_default;TRUNCATE cache_discovery;TRUNCATE cache_dynamic_page_cache;TRUNCATE cache_entity;TRUNCATE cache_menu;TRUNCATE cache_render;TRUNCATE cache_toolbar;" && drush updb -y --no-post-updates && drush cim -y && drush cr