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
- Upgrade to Drupal 8.6.8
- 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
- Edit settings.php and add the line
$settings['rebuild_access'] = TRUE;
to the bottom of the file - Visit the URL
core/rebuild.php
on your site - Remove
$settings['rebuild_access'] = TRUE;
from settings.php
Or
- Run the rebuild token calculator from the command line
$ php ./core/scripts/rebuild_token_calculator.sh
which will output something liketimestamp=1549546961&token=9CPufgezJuLFvSNJcbKnGzNLN-bgpBdob3lXMoJF8F3
- 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.phpUpdateKernel
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
Comment | File | Size | Author |
---|---|---|---|
#144 | 3031128-144-test-fail.patch | 862 bytes | hchonov |
#144 | 3031128-144-test-fail.patch | 862 bytes | hchonov |
#41 | 3031128-3-41.patch | 246.67 KB | alexpott |
#41 | 37-41-interdiff.txt | 782 bytes | alexpott |
#37 | 3031128-3-37.patch | 246.48 KB | alexpott |
Comments
Comment #2
cilefen CreditAttribution: cilefen at Institute for Advanced Study commentedThis seems like the last few comments on #2701829: Extension objects should not implement \Serializable.
Comment #3
BerdirYes, a cache clear is necessary, there is no other way.
Comment #4
TrevorBradley CreditAttribution: TrevorBradley commentedWould a cache clear in advance of the update prevent the errors, or are the errors unavoidable?
Comment #5
BerdirA 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.
Comment #6
TrevorBradley CreditAttribution: TrevorBradley commentedEh, 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.
Comment #7
cilefen CreditAttribution: cilefen at Institute for Advanced Study commentedBased on this report, @xjm added this to the release notes.
Comment #8
alexpottOh 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.
Comment #9
larowlanAnyway we can add a test for this?
Comment #10
alexpott@larowlan yep! was just working on that.
Comment #11
alexpottThe test only patch is the interdiff :)
Comment #12
jibranIs 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.
Do we really want to use @ here? Should we replace it with try catch?
Comment #13
alexpottAs 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.
Comment #14
alexpott@jibran asked a good question in chat.
If you:
For me this makes this critical.
Comment #15
alexpott@jibran ask another good question in chat
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.
Comment #16
alexpottNote 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
Comment #17
zenimagine CreditAttribution: zenimagine commentedHello 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 ?
Comment #19
alexpott@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.
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.
Comment #23
alexpottSo 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
$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.
Comment #25
larowlanshould 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
this is crafty - nice
Comment #26
cilefen CreditAttribution: cilefen at Institute for Advanced Study commented#3031208: "TypeError: Arguement 1 Passed..." after Composer update to Drupal 8.6.8 is semantically similar.
Comment #27
Metztli CreditAttribution: Metztli commentedRelevant 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.
Comment #28
alexpottre #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.
Comment #29
alexpottHere'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.
Comment #30
alexpottWe 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.Comment #31
indigoxela CreditAttribution: indigoxela commentedI'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:
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:
Comment #32
alexpott@indigoxela are you sure? On drush 9.4.0 that does not happen for me.
If I
If I
Going to try with drush 8.1.18
Comment #33
mkolar CreditAttribution: mkolar at Ciklum Western Europe for BurdaForward commentedWe 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)..
Comment #35
alexpottConfirm 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.
Comment #36
indigoxela CreditAttribution: indigoxela commented@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.
Comment #37
alexpottHere'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:
Comment #38
indigoxela CreditAttribution: indigoxela commented@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:
I can confirm: when no other page is visited before running "update.php" via browser, there are no warnings in dblog.
Comment #39
alexpottCreated 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).
Comment #40
catchPatch 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.
Comment #41
alexpottPatch 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.
Comment #42
alexpottUpdated the issue summary.
Comment #43
alexpottAdding workarounds.
Comment #44
alexpottComment #45
alexpottComment #46
jppo CreditAttribution: jppo commentedHello,
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
Comment #47
alexpottAdded more workaround with less editing.
Comment #48
catchPatch 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..
Comment #49
jibranPatch 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?
Comment #50
catchThat'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.
Comment #51
tjtj CreditAttribution: tjtj commentedThe 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.
Comment #52
alexpott@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.
Comment #53
catchCommitted and pushed bf21c00101 to 8.7.x and 5b52c41801 to 8.6.x. Thanks!
Comment #56
TrevorBradley CreditAttribution: TrevorBradley commentedWhoa, that exploded quickly. Thanks, awesome Drupal community!
Comment #57
Jens Peter CreditAttribution: Jens Peter commentedBefore 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?
Comment #58
Metztli CreditAttribution: Metztli commentedApplied @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!
Comment #59
saparker CreditAttribution: saparker commentedAny 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.")
Comment #60
Egmund CreditAttribution: Egmund commentedsaparker, 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.
Comment #61
adminMN2023 CreditAttribution: adminMN2023 commentedJens 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.
Comment #62
Jens Peter CreditAttribution: Jens Peter commentedCB1_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.
Comment #63
indigoxela CreditAttribution: indigoxela commentedTo 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.
Comment #64
alexpottComment #65
alexpottComment #66
TrevorBradley CreditAttribution: TrevorBradley commentedUh 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
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).
Comment #67
tmanhollan CreditAttribution: tmanhollan commentedI'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.
Comment #68
TrevorBradley CreditAttribution: TrevorBradley commentedRelevant to @tmanhollan's comment: I'm also using a custom install profile.
(Not sure if it would break with the "minimal" install profile)
Comment #69
translectorI can confirm that this is working fine after updating to 8.6.9 on Acquia Cloud, using the lightning profile and BLT.
Cheers.
Comment #70
TrevorBradley CreditAttribution: TrevorBradley commented@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)
Comment #71
alexpott@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.
Comment #72
TrevorBradley CreditAttribution: TrevorBradley commentedGood enough for me. :) Thanks @alexpott.
Comment #73
tmanhollan CreditAttribution: tmanhollan commented@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.
Comment #74
alexpott@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.
Comment #75
alexpott@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)Comment #76
John Pitcairn CreditAttribution: John Pitcairn commentedI'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:Comment #77
Egmund CreditAttribution: Egmund commentedI 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.
Comment #78
Egmund CreditAttribution: Egmund commentedI 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!
Comment #79
indigoxela CreditAttribution: indigoxela commentedThere 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...
Comment #80
alexpott@Egmund thank you for report and additional concerns. However, this issue should not be re-opened because as your report says:
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.
Comment #81
alexpott@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 runningdrush --version
.Comment #82
mkaand CreditAttribution: mkaand commentedI 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.
Comment #83
Egmund CreditAttribution: Egmund commentedThank 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').
Comment #84
tmanhollan CreditAttribution: tmanhollan commented@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.
Comment #85
catch@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.
Comment #86
Egmund CreditAttribution: Egmund commentedI understand catch. I have been sloppy in my previous updates (for many years).
Comment #87
johnvenpin CreditAttribution: johnvenpin as a volunteer commented8.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.
Comment #88
alexpott@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:
drush --version
Comment #89
John Pitcairn CreditAttribution: John Pitcairn commented@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.
Comment #90
alexpott@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.
Comment #91
alexpott#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.
Comment #92
Egmund CreditAttribution: Egmund commentedTarball. 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)
Comment #93
alexpottAdding notes to issue summary based on @Egmund's issues with upgrading and known problems.
Comment #94
TMWagner CreditAttribution: TMWagner commentedAppears that 8.6.9 did not fix the issue...
Comment #95
cilefen CreditAttribution: cilefen at Institute for Advanced Study commented@TMWagner Does the command output you posted above illustrate a symptom of the problem? Might it have been truncated?
Comment #96
SkinSame thing for me after updating from 8.6,7 to 8.6.9:
Comment #97
alexpott@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.
Comment #98
SkinAfter the update I noticed that I`ve lost the home link in the main menù, i don`t know if it is connected.
Comment #99
Mitch5713 CreditAttribution: Mitch5713 commentedWill 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(...) { ... })
Comment #100
tim.plunkettOpened a follow-up: #3032869: \Drupal\Core\Update\UpdateKernel::fixSerializedExtensionObjects() caused test runs to double in duration
Comment #101
alexpott@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
Comment #102
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedUpdating drupal/core (8.6.3 => 8.6.9)
it's still here.
Comment #103
alexpott@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?
Comment #104
Mitch5713 CreditAttribution: Mitch5713 commentedhere 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(...) { ... })
Comment #105
alexpott@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.
Comment #106
Mitch5713 CreditAttribution: Mitch5713 commentedI 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
Comment #107
Mitch5713 CreditAttribution: Mitch5713 commentedthe 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???
Comment #108
Mitch5713 CreditAttribution: Mitch5713 commentedI have a "Sandbox" site in which i could use drush if i had the steps and docs needed to do it?
Comment #109
alexpott@Mitch5713 - thanks for the info. Here are some steps that I think will work for you:
$settings['update_free_access'] = FALSE;
to$settings['update_free_access'] = TRUE;
in your sites/default/settings.php$settings['update_free_access'] = TRUE;
to$settings['update_free_access'] = FALSE;
in your sites/default/settings.phpComment #110
cilefen CreditAttribution: cilefen at Institute for Advanced Study commented@alexpott I have sites that seem to be persistently stuck with this. I'll provide details as I collect them.
Comment #111
cilefen CreditAttribution: cilefen at Institute for Advanced Study commentedIt 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.
Comment #112
cilefen CreditAttribution: cilefen at Institute for Advanced Study commentedIIRC a drush cache-rebuild followed by drush updatedb worked with Drush 8.
Comment #113
Mitch5713 CreditAttribution: Mitch5713 commentedthanks Alexpott if will give that a shot :)
Comment #114
Mitch5713 CreditAttribution: Mitch5713 commentedok 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(...) { ... })
Comment #115
Mitch5713 CreditAttribution: Mitch5713 commentedThen 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
Comment #116
alexpott@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.
Comment #117
geerlingguy CreditAttribution: geerlingguy at Acquia commentedComment #118
geerlingguy CreditAttribution: geerlingguy at Acquia commentedEek, sorry about that, incorrect issue.
Comment #119
balintk CreditAttribution: balintk commentedWe 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();"
Comment #120
jcmartinezI can confirm that going from 8.6.6 to 8.6.10 this weird message showed; however, drush updatedb ran without a glitch.
Comment #121
alexpott@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.Comment #122
sozkara CreditAttribution: sozkara as a volunteer and commentedI can confirm issues specifically with memcache module after updating to 8.6.10
Comment #123
alexpott@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.Comment #124
esod CreditAttribution: esod at Memorial Sloan Kettering Cancer Center commentedWe're also seeing the problem with a reference to memcache when updating from 8.6.7 to 8.6.10 :
We're using drush version 8.1.18
We have the memcache module and the purge module on our system.
Comment #125
cilefen CreditAttribution: cilefen at Institute for Advanced Study commented@esod If I remember correctly, @alexpott mentioned a few times that those warnings will always display during this upgrade.
Comment #126
Mitch5713 CreditAttribution: Mitch5713 commentedalexpott: 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
Comment #127
alexpott@Mitch5713 8.6.10 is a security update - see https://www.drupal.org/SA-CORE-2019-003
Comment #128
alexpott@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.
Comment #129
seanBI 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}.
Comment #130
allupaku CreditAttribution: allupaku commentedThis 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 ?
Comment #131
webdrips CreditAttribution: webdrips commentedI can confirm this is still an issue, and we're not using memcache on this particular site.
Seems to be related to this error:
Notes on this site:
Nothing has worked to date.
Comment #132
sfdrummer CreditAttribution: sfdrummer commentedI 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().
Comment #133
bajah1701 CreditAttribution: bajah1701 as a volunteer commentedI 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.
Comment #134
webdrips CreditAttribution: webdrips commented@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!
Comment #135
alexpottThanks 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.
Comment #136
webdrips CreditAttribution: webdrips commentedSure thing! Edit I see you asked for the info in core.extension
All I can say for sure is the following:
InvalidArgumentException: $string ("") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 132 of /core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php).
I see a few other warnings/errors in the log, but it's difficult to tell if they might be related or not.
Comment #137
bajah1701 CreditAttribution: bajah1701 as a volunteer commented@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.
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.
Comment #138
Peter Buchanan CreditAttribution: Peter Buchanan as a volunteer and commentedI 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;-)
Comment #139
webdrips CreditAttribution: webdrips commentedJust 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.
Comment #140
kfritscheThe issue can also be reproduced with Drupal TestBot using latest patch from #1894286: System updates are executed without priority
Comment #141
catchGiven 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.
Comment #143
hchonov@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.
Comment #144
hchonovAnd here is a one line test showing that the problem still exists, therefore I am re-opening the issue.
Comment #145
alexpott@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.
Comment #146
hchonov@alexpott, I've done this according to @çatch's comment #141:
I apologize, I didn't realise that.
Comment #147
alexpott@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 :)
Comment #149
Dropa CreditAttribution: Dropa commentedI'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
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: