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));
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | eu_cookie_compliance-toString-3042393-11.patch | 1.97 KB | gngn |
| #9 | Bildschirmfoto 2019-03-27 um 09.53.38.png | 536.4 KB | ro-no-lo |
Comments
Comment #2
ro-no-lo commentedComment #3
svenryen commented@ronan.orb you need to run update.php or `drush updb`.
Comment #4
svenryen commentedComment #5
ro-no-lo commentedWell 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.
Comment #6
svenryen commented@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?
Comment #7
ro-no-lo commentedUpdated 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:
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.)
Comment #8
svenryen commented1.3 has a bug. Please update to 1.5 rather than 1.3, as the update to 1.3 from 1.2 is broken.
Comment #9
ro-no-lo commentedI 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.
Comment #10
SaraKlasson commentedDrush updb solved it for me.
Comment #11
gngn commentedI 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.
Comment #12
svenryen commentedThanks 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.
Comment #14
svenryen commented