After enabling views caches, all my views pages show

Fatal error: __clone method called on non-object in \sites\all\modules\contrib\views\plugins\views_plugin_cache.inc on line 258

Which is line

$query = clone $build_info[$index];

The $index is 'query', but $build_info looks like

Array
(
    [query] => 
    [count_query] => 
    [query_args] => Array
        (
        )

)

It's empty.

Doing this seems to solve the problem:

      foreach (array('query', 'count_query') as $index) {
        if (!empty($build_info[$index])) {
          $query = clone $build_info[$index];
          $query->preExecute();
          $build_info[$index] = (string)$query;          
        }
      }

Patch attached.

CommentFileSizeAuthor
#8 1364988-caching-query.2.patch1011 bytesbigjim
#7 1364988-caching-query.patch1.63 KBdawehner
#3 views_caching_query.patch1.63 KBfago
views-cache-clone.patch753 bytesAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Status: Needs review » Active

Hmm, the real issue seems related to the Search API. For some reason, you can't use caching with Search API views indexes.
We can probably close this.

dawehner’s picture

Project: Views (for Drupal 7) » Search API
Version: 7.x-3.x-dev » 7.x-1.x-dev
Component: Code » Views integration

Let's move to search_api

fago’s picture

Title: Fatal error: __clone method called on non-object in views_plugin_cache.inc on line 258 » Views caching with search api query backend
FileSize
1.63 KB

I had a short look at that. The problem is the views cache plugin assumes the default sql query back-end. Attached is a simple patch that makes it work. However, search-api provides no query in build-info what breaks the cache-key for the results - so caching results with search-api is still broken.

To properly fix I think we might want to improve the views query plugin "interface" to include a way for the query plugin to get the string-representation of the query for the cache key.

Patch attached.

fago’s picture

Status: Active » Needs work
dawehner’s picture

+++ b/plugins/views_plugin_cache.incundefined
@@ -251,13 +251,18 @@ class views_plugin_cache extends views_plugin {
+        if ($query_plugin->definition['name'] == 'views_query') {

What about looking at the class of the object? and see whether it's a certain class of one of it's childs?

drunken monkey’s picture

Project: Search API » Views (for Drupal 7)
Version: 7.x-1.x-dev » 7.x-3.x-dev
Component: Views integration » Code
Status: Needs work » Needs review

Accordingly, moving back to Views (if fago is right).

dawehner’s picture

FileSize
1.63 KB

The main reason why instanceof is used here is that people extend the views default plugin to add some features.

Here is a new patch (not tested)

bigjim’s picture

FileSize
1011 bytes

This patch worked for me

I re-factored it against the most recent 3.x branch

dawehner’s picture

Status: Needs review » Fixed

Thanks for helping on that issue.

Committed to 7.x-3.x

vladady’s picture

Status: Fixed » Needs work

It still doesn't cache properly.

If you have filters in an exposed form, if the filters values change the cache remains the same.

For example if you search for php, the views stores the cache.
If you search for other keywords you get the cached results for php.

Do you have a solution for it?

bigjim’s picture

Status: Needs work » Closed (fixed)

@vladady I believe yours is a separate issue. Views generally caches each query individually as of Views3 which leads me to believe that you issue may be related to another module, an d likely not to the issue involved here.

Can you open another issue with more info about your set-up and export your views code?