Marking this issue critical as it currently results in a WSOD.
Updated to 8.x-1.1 and this issue started, updated to 8.x-1.2 and this issue persists.
The website encountered an unexpected error. Please try again later.Symfony\Component\Debug\Exception\ContextErrorException: Notice: Undefined variable: primary_button_label in eu_cookie_compliance_page_attachments() (line 182 of modules/contrib/eu_cookie_compliance/eu_cookie_compliance.module).
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) (Line: 76) Drupal\webprofiler\EventDispatcher\TraceableEventDispatcher->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: 47) Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 38) Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object, 1, 1) (Line: 52) Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23) Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 666) Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Turned out that in eu_cookie_compliance.module line 134 $method = $config->get('method');
returned NULL
and therefore the following code was breaking.
Replacing it by $method = $config->get('method') ? $config->get('method') : 'default';
fixed it. Probably it's just the config logic that has changed. Probably just need to be able to login again and reexport config to ultimately fix it.
Patch following.
Comment | File | Size | Author |
---|---|---|---|
#16 | eu_cookie_compliance-undefined-variable-primary-button-label-2985543-15-7.x.patch | 584 bytes | svenryen |
#3 | 2985543-3-notice_undefined_index.patch | 560 bytes | leymannx |
Comments
Comment #2
svenryen CreditAttribution: svenryen at Ramsalt Lab commentedDid you run drush updb? Do you have translations on your site?
Comment #3
leymannxComment #4
leymannxYes, I did run drush updb. Issue persisted. Yes, I do have translations on my site.
Comment #5
leymannxYup, what I assumed. On an existing site, with the new changes, Consent method has never been exported and therefore the code breaks. As I see now inside
config/install/eu_cookie_compliance.settings.yml
the default is supposed to beopt_in
. Updated patch accordingly.Comment #6
SpokjeHaving the same issue, but with different symptoms.
Site with Drupal 8.5.3 and translations, eu_cookie_compliance 8.x-1.2.
Did the DB-update, seeing the Notice in the log, but no WSOD.
However the text on the Agree Button is empty.
Patch #3 fixed it for me (since site was using "Consent by default").
Comment #7
svenryen CreditAttribution: svenryen at Ramsalt Lab commentedThanks for updating the patch. I'll have a look this weekend.
Comment #8
leymannxAfter thinking this over, the patch from #3 indeed seems to be the better choice. As it applies the
default
method which has been the default prior to version 8.x-1.1 and therefore should be the method that is chosen for everybody who had the module already up and running before the 8.x-1.1 release.Unfortunately also the order of elements in the markup in the main templates changed. Would be nice this also would have been switched only after a method via config had been set explicitly. Good news is we have identified a marker to distinguish between older and newer installations, which could be used to provide some fallbacks to prevent things from breaking after the feature-rich 8.x-1.1 release.
Anyways, besides these minor flaws thanks for this great module and the ongoing development, I really appreciate that! :)
Comment #9
SpokjeI agree with @leymannx that patch #3 respects the previous settings the closest. Happy to put it on RTBC.
I also agree with @leymannx that the work on this module is greatly appreciated, and I really like the new options.
Having said that, in hindsight it might not been the best idea to roll those, with so many changes, into a Security Update.
An "in-between" Security Release might have gone down easier.
Comment #10
svenryen CreditAttribution: svenryen at Ramsalt Lab commentedThe problem was that a security hole was found and reported in the -dev branch, and it was difficult to coordinate a security update without at the same time releasing the dev branch.
Comment #11
Spokje@svenryen: Ah, that makes sense.
Thank you for clarifying :)
Comment #12
marcoliverAny idea when this might make it into a release?
Comment #13
svenryen CreditAttribution: svenryen at Ramsalt Lab commentedWithin a month is the current estimate.
Comment #14
svenryen CreditAttribution: svenryen at Ramsalt Lab commentedIt's been exactly a month and I've been busy. I'll commit it to dev later and hopefully get a new release out when some bug reports are settled.
Comment #16
svenryen CreditAttribution: svenryen at Ramsalt Lab commentedUpdated D7 to match the default from this patch. The check was already there.
Comment #18
svenryen CreditAttribution: svenryen at Ramsalt Lab commented