Problem/Motivation
(Maybe a regression of #3238391: Webform css/js assets are stale?)
After updating webform (6.0.5 => 6.1.0), I'm getting a PHP error in dblog any time I...
- View a webform with custom CSS.
- Load any build/config pages for managing that webform.
...while logged in with permission to manage webforms.
When I view the webform (while logged-in as this user), the custom CSS is not loaded. (When I view the webform not logged-in as a user with permission to manage webforms, the custom CSS loads fine, and there are no errors in dblog.)
Log entry details:
Type: PHP
Location: https://mysite.com/webform/javascript/my_form?r211ng
Severity: Error
Message:
Error: Call to undefined method Drupal\webform\Routing\WebformUncacheableResponse::addCacheableDependency() in Drupal\webform\Controller\WebformEntityController->css() (line 99 of /code/web/modules/contrib/webform/src/Controller/WebformEntityController.php)
[...backtrace -- lmk if you want it!]
When I remove the custom CSS (via /admin/structure/webform/manage/my_form/settings/assets), the error goes away, but it comes back when I add the custom CSS back.
I have another webform that doesn't have any custom CSS -- I added some fake/placeholder CSS to that form, and when I saved, I got the addCacheableDependency()
undefined method error.
When I add custom JavaScript to either of my webforms, there's a second PHP error in dblog:
Error: Call to undefined method Drupal\webform\Routing\WebformUncacheableResponse::addCacheableDependency() in Drupal\webform\Controller\WebformEntityController->javascript() (line 123 of /code/web/modules/contrib/webform/src/Controller/WebformEntityController.php)
(I'm still on core 8.9.19, FWIW.)
Steps to reproduce
(see above)
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#7 | 3247584-7.patch | 1.95 KB | jrockowitz |
#5 | 3247584-5.patch | 693 bytes | jrockowitz |
Comments
Comment #2
alisonComment #3
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commented@see https://drupal.stackexchange.com/questions/308041/webform-5-3-to-6-1-0-e...
Comment #4
alison@jrockowitz thanks! -- are you saying that the fix is what the commenter over there suggested, or are you sharing it as a workaround for now?
Comment #5
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedThis might fix this issue.
Comment #6
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedComment #7
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedThis feels like the better solution.
Comment #8
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedComment #9
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedComment #11
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedComment #12
francoud CreditAttribution: francoud as a volunteer and commentedSame problem, on apache2.4 a Windows server, Drupal 9: the patch in #7 solved.
Curiously, the same website running on linux, had no problems and didn't need the patch. But I applied it anyway to the "good" server, and it still is ok, so I guess you can add the patch to the next release.
Thanks for your great job!
Comment #13
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedI am planning on tagging a new release in the next week or so.
Comment #14
KarinGWe just hit this as well on a number of sites - thank you for fixing this so quickly @jrockowitz