First of all we use our own theme, which I do not know what it is based on (someone else did the theme stuff).

After composer update from 1.2 to 1.5 it crashed right away in .module on line 231 because a __toString() was used on a non-object.

The website encountered an unexpected error. Please try again later.
Error: Call to a member function __toString() on string in eu_cookie_compliance_page_attachments() (line 232 of modules/contrib/eu_cookie_compliance/eu_cookie_compliance.module).
eu_cookie_compliance_page_attachments(Array) (Line: 297)

There are these lines, which ALL are problematic.

    $html_info = trim(Drupal::service('renderer')->renderRoot($html_info)->__toString());
    $mobile_html_info = trim(Drupal::service('renderer')->renderRoot($mobile_html_info)->__toString());
    $html_agreed = trim(Drupal::service('renderer')->renderRoot($html_agreed)->__toString());
    $withdraw_markup = trim(Drupal::service('renderer')->renderRoot($withdraw_markup)->__toString());

The first line could be solved by going into the settings of the module and choose a default template to render. (I debugged that). The next error occured then on the line with the $mobile_html_ino also with __toString() use on non-object. The thing is, These lines: Drupal::service('renderer')->renderRoot($xyz) are in our case all returned an empty string. Which is absolute plausable. If you check the callable() and step into at some point you'll find that the current renderer (which is the callable()) has also code like this:

...
   // in Renderer.php
  protected function doRender(&$elements, $is_root_call = FALSE) {
    if (empty($elements)) {
      return '';
    }
...

Which means an empty string is an allowed return value. Therefore calling unchecked a ->__toString() on it crashes.

I do not know WHY the renderer does return an empty string. It worked flawlesly with the 1.2 version of the module. The fix for these 4 lines are obvious.

Propably this:

    $html_info = trim((string) Drupal::service('renderer')->renderRoot($html_info));
    $mobile_html_info = trim((string) Drupal::service('renderer')->renderRoot($mobile_html_info));
    $html_agreed = trim((string) Drupal::service('renderer')->renderRoot($html_agreed));
    $withdraw_markup = trim((string) Drupal::service('renderer')->renderRoot($withdraw_markup));

Comments

ronan.orb created an issue. See original summary.

ro-no-lo’s picture

Issue summary: View changes
svenryen’s picture

@ronan.orb you need to run update.php or `drush updb`.

svenryen’s picture

Status: Active » Closed (works as designed)
ro-no-lo’s picture

Well I did run update.php and still I had that error. But it's very odd that you forcefully ignore that ->renderRoot(..) can return a string which you try to run ->__toString() on.

svenryen’s picture

@ronan.orb. You had previously 1.2 installed, then you updated to 1.5 and it did not show any updates for the module when you ran update.php? Did you also rebuild cache?

ro-no-lo’s picture

Updated locally to 1.3 instead of 1.5 (from 1.2) and run

vendor/bin/drupal update:entities
vendor/bin/drupal update:execute all

and also /update.php

No remaining updates.

My Frontpage, after composer update to 1.3:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function __toString() on string in eu_cookie_compliance_page_attachments() (line 231 of modules/contrib/eu_cookie_compliance/eu_cookie_compliance.module).
eu_cookie_compliance_page_attachments(Array) (Line: 297)
Drupal\Core\Render\MainContent\HtmlRenderer->invokePageAttachmentHooks(Array) (Line: 273)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
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: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->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)

Iirc Drupal has no great way to roll updates back, therefore fiddling around with the updates from the .install file are exhausting. I'll as I suggested rewrite the lines to the php-wise correct way of casting the result into a string. (I mean for real magic double-underscore methods are "magic" for a reason. You don't call them directly - from the outside. I can't even remember using that in like 15 years.)

svenryen’s picture

1.3 has a bug. Please update to 1.5 rather than 1.3, as the update to 1.3 from 1.2 is broken.

ro-no-lo’s picture

StatusFileSize
new536.4 KB

I had resettet the updates counter to 8109, so that the needed settings will be executed. My update script does all updates and cache clear automaticly in order. Reinstalled the module again via composer and the website was instantly shut down - via "the website encountered an error" message.

The log was clear about that - see attachment.

The updates were run, because the updates counter was after that again on 8111. So I *think* I did not made a mistake on my part.

log

SaraKlasson’s picture

Drush updb solved it for me.

gngn’s picture

Version: 8.x-1.5 » 8.x-1.14
Status: Closed (works as designed) » Needs review
StatusFileSize
new1.97 KB

I encountered the same errors as described in the issue decription.
drush updb did not help.

Patch attached for 8.x-1.14 (I know it's old, but I cannot update for now).
the patch is similiar to the suggestion in the description - I changed the mentioned lines to check if renderRoot() returned an object.

svenryen’s picture

Status: Needs review » Reviewed & tested by the community

Thanks for the patch. I haven't run across this issue, but if there's a problem with the loading of the renderer I see it can return an empty string/

Note that the module will be entirely useless when this happens, since it won't be able to render its banners.

  • svenryen committed 08dfdc1 on 8.x-1.x authored by gngn
    Issue #3042393 by gngn, ro-no-lo, svenryen, SaraKlasson: Update 1.2 to 1...
svenryen’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

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