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.

Files: 
CommentFileSizeAuthor
#11 1748526-time-based-try.patch715 bytesdawehner
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1748526-time-based-try.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#2 1748526-cache-time.patch668 bytesdawehner
PASSED: [[SimpleTest]]: [MySQL] 1,555 pass(es).
[ View ]
Set cache to none31.79 KBcouturier

Comments

+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

Status:Active» Needs review
StatusFileSize
new668 bytes
PASSED: [[SimpleTest]]: [MySQL] 1,555 pass(es).
[ View ]

There 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.

Status:Needs review» Needs work

The last submitted patch, 1748526-cache-time.patch, failed testing.

Status:Needs work» Reviewed & tested by the community

Yes, this patch works. Thank you!

Status:Reviewed & tested by the community» Needs work

I'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.

I 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

Interesting. 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.

Status:Needs work» Needs review

#2: 1748526-cache-time.patch queued for re-testing.

@laura s
This is a really helpful information, as this might be a starting point to be able to reproduce the issue.

Status:Needs review» Active

Okay 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.

Status:Active» Needs review
StatusFileSize
new715 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1748526-time-based-try.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Here 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.

Status:Needs review» Needs work

The last submitted patch, 1748526-time-based-try.patch, failed testing.

I 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.

I 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.

Can 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.

Having 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:

SELECT node.nid                 AS nid,
       node.title               AS node_title,
       node.created             AS node_created,
       'node'                   AS field_data_field_image_node_entity_type,
       'node'                   AS field_data_field_intro_node_entity_type,
       'node'                   AS field_data_field_rubric_node_entity_type,
       'latest_article:default' AS view_name
FROM   node node
WHERE  ( (( node.nid IN (SELECT tn.nid AS nid
                         FROM   taxonomy_index tn
                                LEFT OUTER JOIN taxonomy_term_hierarchy th
                                             ON th.tid = tn.tid
                                LEFT OUTER JOIN taxonomy_term_hierarchy th1
                                             ON th.parent = th1.tid
                         WHERE  ( ( tn.tid IN ( :db_condition_placeholder_0,
                                                :db_condition_placeholder_1
                                              ) )
                               OR ( th1.tid IN ( :db_condition_placeholder_2,
                                                 :db_condition_placeholder_3 )
                                  ) )) ))
     AND (( ( node.type IN ( :db_condition_placeholder_4 ) )
            AND ( node.status = :db_condition_placeholder_5 ) )) )
ORDER  BY node_created DESC
LIMIT  1 offset 0

So with cache enabled, it would produce the following query:

SELECT node.nid                 AS nid,
       node.title               AS node_title,
       node.created             AS node_created,
       'node'                   AS field_data_field_image_node_entity_type,
       'node'                   AS field_data_field_intro_node_entity_type,
       'node'                   AS field_data_field_rubric_node_entity_type,
       'latest_article:default' AS view_name
FROM   node node
WHERE  ( (( node.nid IN (SELECT tn.nid AS nid
                         FROM   taxonomy_index tn
                                LEFT OUTER JOIN taxonomy_term_hierarchy th
                                             ON th.tid = tn.tid
                                LEFT OUTER JOIN taxonomy_term_hierarchy th1
                                             ON th.parent = th1.tid
                         WHERE  ( ( tn.tid IN ( '270', '641' ) )
                               OR ( th1.tid IN ( '270', '641' ) ) )) ))
     AND (( ( node.type IN ( '270' ) )
            AND ( node.status = '641' ) )) )
ORDER  BY node_created DESC
LIMIT  1 offset 0;

And without cache:

SELECT node.nid                 AS nid,
       node.title               AS node_title,
       node.created             AS node_created,
       'node'                   AS field_data_field_image_node_entity_type,
       'node'                   AS field_data_field_intro_node_entity_type,
       'node'                   AS field_data_field_rubric_node_entity_type,
       'latest_article:default' AS view_name
FROM   node node
WHERE  ( (( node.nid IN (SELECT tn.nid AS nid
                         FROM   taxonomy_index tn
                                LEFT OUTER JOIN taxonomy_term_hierarchy th
                                             ON th.tid = tn.tid
                                LEFT OUTER JOIN taxonomy_term_hierarchy th1
                                             ON th.parent = th1.tid
                         WHERE  ( ( tn.tid IN ( '270', '641' ) )
                               OR ( th1.tid IN ( '270', '641' ) ) )) ))
     AND (( ( node.type IN ( 'article' ) )
            AND ( node.status = '1' ) )) )
ORDER  BY node_created DESC
LIMIT  1 offset 0;

As you can see, type and status receive wrong parameters.

After deeper investigation, it came that the patch, that was comited to 3.5 breaks these views. Reverting to

if ($build_info[$index] instanceof SelectQueryInterface) {
  $build_info[$index] = (string) $build_info[$index];
}

solved the issue for me

[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:

If you enable block caching, without enabling page caching, the block cache settings will be used (for anonymous and authenticated).

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.

couturier, 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.

Thanks 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?

I 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.

I 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.

Title:Upgrade from 7.x-3.3 to 3.4 makes time-based cache break Views7.x-3.5 upgrade affecting some Views with time-based cache enabled
Version:7.x-3.4» 7.x-3.5
Status:Needs work» Active

The 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.

Issue summary:View changes

Added a slight suggestion.

Status:Active» Closed (duplicate)

This 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

Issue summary:View changes

Updated status.