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.
This issue started out with the 3.4 Views upgrade that was breaking Views with time-based cache enabled. The 3.5 release reverted the patch that had caused the problem, but several people are still having problems when time-based cache is enabled in 3.5. This bug report has been updated at present to the 3.5 version, but someone may need to close it and start a new bug report, since some of the information here applies to the old 3.4 release.
Comment | File | Size | Author |
---|---|---|---|
#11 | 1748526-time-based-try.patch | 715 bytes | dawehner |
#2 | 1748526-cache-time.patch | 668 bytes | dawehner |
Set cache to none | 31.79 KB | couturier |
Comments
Comment #1
almamun CreditAttribution: almamun commented+1
With Views 7.3.4, if time based cached is enabled, views blocks wont appear.
But as soon as I replaced 7.3.4 with 7.3.3, views blocks appeared.
Also I needed to update filter (taxonomy/term) to make them work for 3.4
almamun
----------------
Dinajpur - Rangpur - Rajshahi
Comment #2
dawehnerThere has been a change in the cache, see #1509980: cache_get() performance regression
The attachment gives you a revert of the patch, so this issue should fix you.
Comment #4
couturier CreditAttribution: couturier commentedYes, this patch works. Thank you!
Comment #5
couturier CreditAttribution: couturier commentedI'm moving this back to needs work because I submitted comment #4 at the same time comment #3 went live, so the order was accidentally reversed.
Comment #6
laura s CreditAttribution: laura s commentedI can confirm this bug, but have additional info: I have a problematic view that is fixed by removing time-based caching, but it can also be fixed by removing "Published or Admin" filter (I replaced it with the Published filter). In other words, on my view, by removing time-based caching or the problematic filter, my display returns.
Related: #1748386: Published or Admin filter failing
Comment #7
couturier CreditAttribution: couturier commentedInteresting. I had a filter issue that was connected with time-based cache, too, but it was different from yours in that it was a filter that required an operator setting. I posted it under comment #47 at the "7.x-3.4 Upgrade is cancelling boolean operator settings" issue that is getting a lot of comments currently.
Comment #8
dawehner#2: 1748526-cache-time.patch queued for re-testing.
Comment #9
dawehner@laura s
This is a really helpful information, as this might be a starting point to be able to reproduce the issue.
Comment #10
dawehnerOkay i reverted the previous patch to both 8.x-3.x and 7.x-3.x
There could be some experimenting about the code but this will be done later on the issue.
Comment #11
dawehnerHere is a patch which would be cool, if someone would try that one out.
Is it relative to 3.5, so basically it would just be a cleanup but nevertheless interesting.
Comment #13
couturier CreditAttribution: couturier commentedI just saw this new patch in #11, showing it already failed system testing. I'll be happy to try it, but I'll wait until a revision is submitted.
Comment #14
heatherwoz CreditAttribution: heatherwoz commentedI upgraded a dev site to 3.5 (which I thought reverted the commit that introduced the caching changes) but I am still having issues when time-based caching is enabled.
Comment #15
couturier CreditAttribution: couturier commentedCan you explain exactly what issues you are having in 3.5? My Views that disappeared with caching under 3.4 are visible under 3.5.
Comment #16
sbozhko CreditAttribution: sbozhko commentedHaving same issue with 3.5 and taxonomy argument (with depth).
We've discovered, that when cache is enabled, view puts incorrect arguments in query.
For example, i have the following query:
So with cache enabled, it would produce the following query:
And without cache:
As you can see, type and status receive wrong parameters.
Comment #17
sbozhko CreditAttribution: sbozhko commentedAfter deeper investigation, it came that the patch, that was comited to 3.5 breaks these views. Reverting to
solved the issue for me
Comment #18
couturier CreditAttribution: couturier commented[Update: see comment #19 below, this is not correct as it applies to Views.]
I just learned from this article How does caching work in Drupal? that if I have page cache enabled under Configuration>Performance, that all blocks will also be cached for anonymous users. Also:
Since all of my users are not authenticated, I could have just used the caching under Performance, turned off caching in Views entirely, and this bug would not have affected my site.
Related to this, I also learned that setting cron to run too often kills the benefit of caching. There is ongoing work at this issue to resolve the way caches are cleared in Drupal 7.
Comment #19
heatherwoz CreditAttribution: heatherwoz commentedcouturier, I don't think that's right. Views caching works separately from Page and Block caching. Having Page caching on will cache all your pages, i.e., your individual content types, but the queries and processing used to generate views, i.e. customized content lists, will run every time unless you have the Views caching on.
Comment #20
couturier CreditAttribution: couturier commentedThanks so much! I added an update to my comment. I wonder why this issue is still active since it was fixed by the 3.5 release?
Comment #21
heatherwoz CreditAttribution: heatherwoz commentedI think there were still some people (myself included) experiencing issues with views time-based caching in 3.5. I still have one set of dev sites that won't behave, but I upgraded some others directly from 3.3 to 3.5 and they appear to be working so far.
Comment #22
giorgio79 CreditAttribution: giorgio79 commentedI am using Search API Views, and the front page of the view works, but all subpages give a "Page not found" after enabling time based caching.
Comment #23
couturier CreditAttribution: couturier commentedThe things going on in 3.4 were supposed to be completely reverted back to what they were in the 3.3 version for the 3.5 release. But, several people here are saying that they are still having caching problems in 3.5. It's possible that this bug report may need to be closed and a new one started for 3.5. What I'm doing for the moment is updating the issue title and version to 3.5 since there are comments from at least 3 of you that you are having caching issues still in 3.5 (see especially #16 and #17). Someone else may want to close this and start a new bug report to be more targeted on the 3.5 problem.
Comment #23.0
couturier CreditAttribution: couturier commentedAdded a slight suggestion.
Comment #24
couturier CreditAttribution: couturier commentedThis issue is a duplicate, and people who are still having problems in 7.x-3.5 should probably continue their discussion at the issue linked below. The information from the old 3.4 release found on this current issue does not apply anymore.
See the duplicate: After upgrade to 3.5 only views with caching set to 'None' work - Time based caching gives "Page not found" errors
Comment #24.0
couturier CreditAttribution: couturier commentedUpdated status.