Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
<em class="placeholder">Warning</em>: DateTime::createFromFormat(): Invalid date.timezone value '@@TIMEZONE@@', we selected the timezone 'UTC' for now. in <em class="placeholder">Drupal\Core\EventSubscriber\FinishResponseSubscriber->setExpiresNoCache()</em> (line <em class="placeholder">263</em> of <em class="placeholder">/Users/webchick/Sites/8.x/core/lib/Drupal/Core/EventSubscriber/FinishResponseSubscriber.php</em>).
Relevant code is in DbLogController::eventDetails().
This fixes it, but not sure it's the right fix. I wanted to try and fix it in formatMessage() but that didn't seem to take effect.
Comment | File | Size | Author |
---|---|---|---|
#16 | exception_log_messages-2409881-16-only-test.patch | 1.6 KB | subhojit777 |
#16 | interdiff-2409881-12-16.txt | 1.42 KB | subhojit777 |
#16 | exception_log_messages-2409881-16.patch | 2.06 KB | subhojit777 |
#12 | exception_log_messages-2409881-12.patch | 1.84 KB | subhojit777 |
#12 | interdiff-2409881-6-12.txt | 1.89 KB | subhojit777 |
Comments
Comment #1
joelpittetThis solves the problem, but I think formatMessage() would be a better place to solve it like you mentioned.
This works as well.
Comment #2
subhojit777There is already an issue for this #2345779: Fix double-escaping due to Twig autoescape in dblog event "operations", see comment. We should close this one.
Comment #3
cburschkaSorry, the other issue did not fix this. That patch targeted the "operations" links; the message itself is still escaped.
Screenshot from an install based on the latest source (commit c83565f6).
Edit: Based on looking at some of the rejected patches, it seems that some of them did try to fix the message too, but after some iterations the one that ultimately got committed only got the link.
Comment #4
cburschkaLast patch still applies with small offset, and still fixes the problem.
Comment #5
subhojit777Patch looks good. I would have RTBC'd it, but not sure whether it needs tests.
Comment #6
ruscoe CreditAttribution: ruscoe as a volunteer commentedHad to make a small change to the patch from #1 to get this working for me.
I wrapped the formatted message in a call to
SafeMarkup::set
to bringDbLogController::formatMessage
in line with howDbLogController::overview
displays the log message.Comment #7
dawehnerBefore we change that we should be 100% ensure that we have a test to ensure that we escape once here.
Comment #8
pwolanin CreditAttribution: pwolanin as a volunteer commentedWe should not be adding any uses of SafeMarkup::set()
Instead, we possibly want to use SafeMarkup::checkAdminXss($string), or the suggested inline code inside that method.
Comment #9
cburschkaWhat would be the correct approach here?
Edit: ah
Comment #10
subhojit777Comment #11
subhojit777Comment #12
subhojit777Not using
SafeMarkup::checkAdminXss($string)
and usingSafeMarkup::xssFilter($string)
because the former function will be deprecated soon.Comment #13
subhojit777Comment #14
subhojit777oops, looks like something's wrong. This patch
exception_log_messages-2409881-12-only-test.patch
should have failed.Comment #15
subhojit777Comment #16
subhojit777looks like the test works with
<script>
tag, and fails with<em>
tag.Comment #18
subhojit777Comment #20
dawehnerSo yeah the patch no longer works as expected ...
Comment #21
pwolanin CreditAttribution: pwolanin as a volunteer commentedThis seems to be fixed in HEAD - I cannot reproduce it and the text is not double escaped.