7.x-3.5 upgrade affecting some Views with time-based cache enabled

+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

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.

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

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

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.

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.

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.

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

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.

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.