In doing so, the existing integration tests uncovered dozens of bugs. Those bugs pointed out problems that would've broken Drupal 8 when used in combination with a reverse proxy.
Surely we didn't catch all such bugs yet, since we don't have 100% integration test coverage. This issue is about finding the remaining pages/scenarios that are broken when page caching is enabled. The majority of pages/scenarios are working, as is proven by the integration test coverage. But surely a minority is still broken.
Please test the (a)typical scenarios that you use in Drupal 7, and verify that they work in Drupal 8. If not, create a new child issue of this meta!
The goal: make sure that while you as a site builder/site administrator/content editor are changing settings, creating content, updating content…, that anonymous users immediately see the updated content.
- Drupal 8 HEAD
- 2 browser windows or 2 browsers: in one you're logged in as the site builder/admin/editor, in the other you're the anonymous user
- Test scenario. E.g. as the admin, modify node 1, save it. As the anonymous user, you should immediately see the updated node 1 on both the frontpage and at
- Repeat step 1 for scenarios you care about/are interested in, until you find something that doesn't work.
- Once you find something, you'll want to figure out the root cause. 95% of the time, the problem will be missing cache tags. 3% of the time, the problem will be missing cache tag invalidations, 2% of the time will be more complex, e.g.
So, to find the root cause:
debug($tags)to the function. Now repeat your scenario. You will see which cache tags were invalidated. If no cache tags were invalidated, or no cache tag associated with the thing you've modified was invalidated, then you've found something that should have a cache tag, but doesn't. Congrats :) Please open a new issue and talk to a mentor if this looks daunting. Go back to step 1.
- Now that you know the cache tag that is being invalidated (let's call it "X"), we need to make sure that the page cached for the anonymous user in the page cache also has this cache tag. The easiest way to look at that is by using the developer tools:
If "X" is not in there, then the problem is that the rendered content that depends on the thing that has the "X" cache tag, didn't actually set the cacheability metadata of the thing on the render array. First, open an issue, and say at which specific URL the problem exists. Second, find the route at which this happens: find the route in one of the
*.routing.ymlfiles that corresponds to the URL. Add this to the issue. Third, find the code generating the render array: the
_controllerpoints to a class + method that generates the content for that route. Add this to the issue. Fourth, find in the controller's code where the thing that has the "X" cache tag is being used. Use
RendererInterface::addDependency()(see the concrete example at https://www.drupal.org/developing/api/8/render/arrays/cacheability for more) to make the render array "depend" on the thing that has cache tag "X", this will automatically make the render array "absorb" all the cacheability metadata of the thing. Now test again: the bug should be fixed! Time to post a patch and go back to step 1!
When opening an issue, always mark this issue as the parent issue, so we can find it from here!)
Novice todos, i.e. missing cache tags and/or missing test coverage (in no particular order):
- None right now!
Done (in chronological order: first listed is first committed):