- Issue created by @GaëlG
- Issue was unassigned.
Authenticated forms used to be uncacheable because of CSRF tokens. This is not a problem anymore (see 📌 Form tokens are now rendered lazily, allow forms to opt in to be cacheable Needs review ). So that the sitewide contact form could probably be cacheable.
As we are not sure the current cacheability metadata of the form are correct (it was not used so it's not tested), we forced it to be uncacheable in 📌 Form tokens are now rendered lazily, allow forms to opt in to be cacheable Needs review .
We should make sure cacheability metadata are correct, then opt in for cacheability thanks to 📌 Form tokens are now rendered lazily, allow forms to opt in to be cacheable Needs review or 📌 Deprecate not giving cacheability metadata to forms Needs work (when these are done).
Log in as an admin user.
Go to the contact site page (/contact). You will get the following HTTP header: X-Drupal-Dynamic-Cache: UNCACHEABLE.
You should have X-Drupal-Dynamic-Cache: MISS (if it was not yet in cache), or X-Drupal-Dynamic-Cache: HIT on subsequent page loads.
Most of the needed work had already been done in patches in
📌
Form tokens are now rendered lazily, allow forms to opt in to be cacheable
Needs review
but it was scope creep so it has to be done in this separate issue.
See remaining tasks beyond.
- Update the contact site test in \Drupal\Tests\standard\Functional\StandardTest::testStandard() so that it wants X-Drupal-Dynamic-Cache: HIT.
- Remove the forced max-age zero temporarily set to the form in waiting for this issue to be done.
- Check that the current cacheability metadata of the form is correct.
- Maybe add more tests to check correct cacheability.
None, unless better performance is an UI change. :)
None.
None.
To be done.
Active
11.0 🔥
Last updated
It affects performance. It is often combined with the Needs profiling tag.