WARNING: 8-x-1.3 Update crashes site with WSOD. Fix inside.

Same:

Error: Call to a member function __toString() on string in eu_cookie_compliance_page_attachments() (line 231 of /home/innosys/public_html/modules/contrib/eu_cookie_compliance/eu_cookie_compliance.module) #0 /home/innosys/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(297): eu_cookie_compliance_page_attachments(Array) #1 /home/innosys/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(273): Drupal\Core\Render\MainContent\HtmlRenderer->invokePageAttachmentHooks(Array) #2 /home/innosys/public_html/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)) #3 /home/innosys/public_html/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)) #4 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #5 /home/innosys/public_html/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)) #6 /home/innosys/public_html/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent)) #7 /home/innosys/public_html/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #8 /home/innosys/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #9 /home/innosys/public_html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #10 /home/innosys/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(184): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #11 /home/innosys/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(121): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true) #12 /home/innosys/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(75): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true) #13 /home/innosys/public_html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #14 /home/innosys/public_html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /home/innosys/public_html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /home/innosys/public_html/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /home/innosys/public_html/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #18 {main}.

I am getting the same error.

Same here. Update to 8.x-1.3 form 8.x-1.2 crashed all site.

Admin pages are accessible so i was able to unistall the module.

Error: Call to a member function __toString() on string in eu_cookie_compliance_page_attachments() (line 231 of /var/www/vhosts/xxxxxxxxx.com/httpdocs/modules/eu_cookie_compliance/eu_cookie_compliance.module) #0

Got the same error, but managed to work around.
Luckily I was logged in, so I managed to update the module settings;

- consent method selected (radio button)
- but NO default option is selected for "info banner template"
- selected the first option

Error was gone and site is back up now.

This is probably made worse by the security update last night.

yoursite/admin/config/system/eu-cookie-compliance is the path to config

I'll add an image in a bit.

You could try drush config:edit eu_cookie_compliance.settings and the setting you need to add is

popup_info_template: legacy

(credit to @yazzybe for the fix!)

View of setting in system:

Note that both of these are empty when first seen.

Nice catch @yazzbe!

Seems like this is introduced by https://www.drupal.org/node/2985662 which introduces a new setting 'popup_info_template', but doesn't seem to add in a hook_update.

Will work on a patch next.

EDIT: @Andy_D beat me to it :)

Updating the title to reflect the seriousness of this issue.

Attached patch should add the missing popup_info_template: legacy when it's not there.
Thanks to @Andy_D and @yazzbe for the solid investigation.

Note to maintainer: Retro-updating hook_update_n is never a good idea, and is what caused this issue.
Thanks for the hard work on this module! :)

It seems that testbot marks modules with no tests as Build Successful which turns into Needs Work (failed testing)

I like that idea, but it doesn't mean this patch is breaking stuff (Build Successful indicates at the very least the patch applied cleanly).

Putting this back to Needs Review.

#15 This issue is under investigation, see DrupalCI: Test Runner issue queue at #2990645: "Build Successful" is treated as a test failure

The patch in #12 applies correctly to 8.x-1.x and fixes the configuration for existing installations updating from 8.x-1.2 to 8.x-1.3

Thanks @idebr was looking for that issue to confirm my ramblings in #15

Argh, reverted back to RTBC

Title update to make clear we're talking about the D8 version.

Quick fix: goto the settings page (admin/config/system/eu-cookie-compliance) and save (worked for me).

---

Long version: Updating 8.x-1.2 -> 8.x-1.3 I got changes in eu_cookie_compliance.install

@@ -283,6 +283,7 @@ function eu_cookie_compliance_update_8109() {
     ->set('withdraw_action_button_label', 'Withdraw consent')
     ->set('withdraw_tab_button_label', 'Privacy settings')
     ->set('withdraw_enabled', TRUE)
+    ->set('popup_info_template', 'legacy')
     ->save();
 }

So the new config popup_info_template is set to legacy - but in an old (and already executed) update!

*Update*: like noted in #12 by Spokje:

Retro-updating hook_update_n is never a good idea, and is what caused this issue.

For me it was enough to go to the settings page (admin/config/system/eu-cookie-compliance) and save.

But then I got the changed config popup_info_template: new - not legacy!

Looking at the code I found in EuCookieComplianceConfigForm::validateForm():

    // Set popup_info_template value to 'new' if method is not 'consent by
    // default'.
    if ($form_state->getValue('method') !== 'default') {
      $form_state->setValue('popup_info_template', 'new');
    }

and yeah - I do not have method 'consent by default'.
I do not know about the consequences, but I think the new update-function eu_cookie_compliance_update_8111() should consider this.
Something like this:

+/**
+ * Adding config variable for the popup_info_template.
+ */
+function eu_cookie_compliance_update_8111() {
+  $popup_info_template = \Drupal::configFactory()
+    ->get('eu_cookie_compliance.settings')
+    ->get('popup_info_template');
+
+  if ($popup_info_template === NULL) {
+    $method = \Drupal::configFactory()
+      ->get('eu_cookie_compliance.settings')
+      ->get('method');
+     // Set popup_info_template value to 'new' if method is not 'consent by
+     // default'.
+    $popup_info_template = $method == 'default' ? 'legacy' : 'new';
+    \Drupal::configFactory()
+      ->getEditable('eu_cookie_compliance.settings')
+      ->set('popup_info_template', $popup_info_template)
+      ->save();
+  }
+}

Setting back to needs review.

Patch following the thoughts in #20 attached.

Btw: #21 (as well as #12) requires database update - e.g. drush updatedb.

Setting to needs-review (see #15)

Reviewing it now.

This has been committed to -dev. We're waiting for feedback on this other issue before we can tag a new release.
#3038214: [D8] \Drupal\Component\Utility\Xss::filter introduced in 8.x-1.3 filters valid html from existing configuration

Changing this to Fixed since it has been committed to the Dev-branch

It was actually tagged in 1.4 right now :)

An additional note here, for anyone still using features to manage these sorts of configs (I know, not advisable), you'll want to update your eu_cookie_compliance.settings.yml file with this new config key/value. I had updated to 1.4, rebuilt the site but was still getting the same error. Validated that the update hook had actually run by checking the schema value in the db and figured features had to have something to do with reverting/unsetting the updated value...

Simply add the following new line after the popup_info definition (first I used 'legacy' and it broke our custom styling for the banner, 'new' worked and maintained the custom styles):

popup_info_template: new

Revert features and you should be good to go.

I am just wondering, how it comes that security update which is supposed to solve some issues causes new issues that cannot be solved without applying new patches?
Are those security update even tested, or what?
Why is is such a pain all the time to roll out update (which are even minor updates, by the way)?

aleksi_anisimov. You hit it spot on, the added features were not tested well enough for all configurations. We regret the inconvenience, and you're more than welcome to help maintain or test the module.