Notice: Undefined index: data in views_plugin_cache->restore_headers()

following

+1

+1

+1

The same change needs to be done in line 233, yet I believe these changes may be hidding the true root of the problem.

Hello, i have got the same problem, but with slightly different lines.

Notice: Undefined index: data in views_plugin_cache->restore_headers() (line 242 of /var/www/clients/client1/web2/web/sites/all/modules/views/plugins/views_plugin_cache.inc).
|Notice: Undefined index: data in views_plugin_cache->restore_headers() (line 236 of /var/www/clients/client1/web2/web/sites/all/modules/views/plugins/views_plugin_cache.inc).

PHP 5.4.20 (cli) (built: Sep 18 2013 19:55:33)
MariaDB Server 5.5.33a-MariaDB-log
Drupal 7.23
Views latest 7.x.3.x-dev from git

patch #5 fixes it for me, but i guess it needs to be rerolled so it can work from inside the views folder so it can apply cleanly (it must refer to plugins/views_plugin_cache.inc not /views/plugins/views_plugin_cache.inc).

Works for me, thanks!

Marked #2083151: Cache plugin, Undefined index 'data' as a duplicate, but it contains a better patch in #5:
- To follow coding standards, curly braces should always be used
- !empty($args['data']) is simpler than is_array($args) && isset($args['data'])

Attached is the pach from #2083151-5. It has better code style.

That many errors? That cannot be true. Retest.

Same here.

Patch at https://drupal.org/comment/7905923#comment-7905923 appears to be working. Maybe we should consider reopening that thread and closing this one?

@Branislav Bujisic, the patch you mention is already copied to this issue (in #10).

subs

10: views_2018737_10 undefined_index_data.patch queued for re-testing.

The proposed patch is not the right approach. The PHP notice is correct that something is wrong in the stored JS/CSS as they are incomplete (missing the "data" key for example). The problem is in views_plugin_cache::gather_headers(), which populates the storage with a broken array diff. The function uses drupal_array_diff_assoc_recursive() which can return partial arrays, but we always want complete CSS/JS definition arrays.

We cannot use array_diff_key() instead since we also want to check if the value (the JS/CSS definition array) is different.

So I propose to use a helper method to cleanup the diff array after drupal_array_diff_assoc_recursive() (which was introduced in #1511396: php 5.4 and "Notice: Array to string conversion"). That way we can throw out entries where only the JS/CSS weight is different.

Patch attached.

21: views-asset-diff-2018737-21.patch queued for re-testing.

21: views-asset-diff-2018737-21.patch queued for re-testing.

patch # 21 work for me

Works for me too. RTBC?

RTBC!

There's a small typo: $diff_funtion instead of $diff_function. But this does not affect the functionality.

#21 works well for me with latest release version of views.

#21 works well for me.

#21 worked on 7.x-3.8

#21 worked for me

Same notice with PHP 5.3 and #21 works

Small typo #30 fixed

Patch from #37 (same as #21 with a fixed typo noted in #30) + clear cache did fix the problem.
RTBC++

I applied both patches in 21 and 37 and the error goes away but functionally the view is broken. I'm using views to display a list of products from Drupal Commerce. When I add an item to the cart its an ajax action and with the patches applies I don't get the error - but I also don't get anything added to the cart. Without the patches the first item is successfully added to the cart, but subsequent add to cart activities throws:

Notice: Undefined index: data in views_plugin_cache->restore_headers() (line 242 of /srv/bindings/46ab388bab8443b783b8a5b40d3c9c0c/code/profiles/panopoly/modules/contrib/views/plugins/views_plugin_cache.inc).

The view is cached, without caching this view everything works perfectly. Not sure if this is a commerce product issue (add to cart) or a views caching issue, but listing here since people have reported the same error.

#37 worked for me as well.

RTBC++ I didn't find the error that @toddtomlinson describe, I'm not using Drupal Commerce so could have some relation.

Patch #37

I have this bug in Views 3.8.

Installing Views 7.3.8 has also introduced the bug for me too on a multisite stack. Drupal 7.28 already applied. No Commerce in the site. I'm only getting the Notice on one of the multisite sites (which uses a cached XML share feed View). PHP 5.3. Not sure what we can do. Can we roll back to previous version of Views meantime or can we turn off and ignore the Notice meantime?

Q.

I just applied #37 against views-7.x-3.8, and it cleared up my error.

Odd. I applied #37 against my views-7.x-3.8 and (after clearing caches) the error persisted. So I'm back on 7.x-3.x-dev.

Applied patch #37 on views-7.x-3.8, cleared the caches and it fixed the error notice I was getting.

Thanks.

Applied #37 on Views 7.x-3.8. The error went away.

Confirming that the patch works also for the 2014-Jul-12 version of 7.x-3.x-dev, but I still can't get it to work for 7.x-3.8 for some reason.

@silurius

Which PHP version are you using? Thanks.

I have updated to latest Drupal 7.30 and currently using View's dev ver. from Jul 23. No need to patch anything. The error problem went away. I am using PHP 5.5 / Apache on Windows 8.

@W.M., I'm on PHP 5.4.12 and was running Drupal 7.26 and just upgraded to 7.30. The error appears only on one of two twin load-balanced servers, which is odd.

Patch #37 fixed it for me in views 7.x-3.8

#37 corrected the issue for us as well.

#37 works for me with Drupal 7.31 and views 7.x-3.8. Thank you very much.

With patch #37 I got the following errors and WSOD:

	Notice: Undefined variable: array_mapping_func in views_plugin_cache->gather_headers() (Line 206 of /sites/all/modules/views/plugins/views_plugin_cache.inc).

Patch from #37 works as expected.

Confirming patch #37 is working

can this be included pls? I hate to have errors and notices around for no real issues..

Patch provided in #37 works for me.

Please commit this.

Thank you very much

Still got same error with #37 applied... :-(

Searched for same errror as indictated in #2018737: Notice: Undefined index: data in views_plugin_cache->restore_headers() and led me to this thread (top of search results). I tried the patch in #37 and it didn't help.

I was using a view with draggableviews and ran into this. Don't recall the steps that caused it. However, later in my workflow I built a feature with the same view which led me to: #1363458: Using an Exported a Draggable View does not work.

Ultimately I rebuilt part of the view by removing and re-adding the draggableviews field and sort weight which resolved the problem. I hope it helps someone else with this error. But doesn't seem to be the same problem/culprit that most others are encountering, since this is the only mention of draggableviews in the thread.

patch in comment #37 works for me. thanks!

Patch #37 also works on a second site.

#37 worked great for me as well.

Works for me. Commit?

Are you tested it in dev version of Views? I think this patch needs reroll.

I applied the patch in #37 to the latest dev of views, and it applied cleanly. It seems to resolve the issue. Since several people have said it works previous to my post, I'm marking as RTBC.

I can confirm the patch works great. RTBC +1 ;)

Worked for me. + 1

Patch #37 works good. RTBC +1

Pacth #37 works for me too... with PHP 5.6.1

Thanks for the patch, works for me!

@All for whom the patch did not work: did you empty all caches after applying? Flushing Views caches only is not sufficient since it does not clear the cache_views_data table.

Background info: the Views cache plugin initially stores a full JS array returned by drupal_add_js() so it can later compare it recursively with the at that time current version of the JS array. The problem lies within drupal_add_js() which always adds a small float to the weight so javascripts with the same weight will be loaded in the same order as they were added to the JS array, see drupal_add_js():

  // Tweak the weight so that files of the same weight are included in the
  // order of the calls to drupal_add_js().
  $options['weight'] += count($javascript) / 1000;

If a script has a weight of 0 and is added as the 15th script, it's weight will become 0.015. If the same script is added again later on during the same page call and in the mean while 2 other scripts have been added, it's weight will become 0.017. This difference is noticed by views_plugin_cache::gather_headers() using drupal_array_diff_assoc_recursive() which adds an array to the diff array for this script with only the weight element. The array has no data element, hence the PHP warning.

The patch from #2018737-37: Notice: Undefined index: data in views_plugin_cache->restore_headers() seems to work great by removing script arrays which only contain a weight element.

Thanks! #37 worked for me after a clean cache (all)

Can we have a stable release?

#37 worked for me.

This patch is not commited to any views branch AFAIK

Deja Vu... Almost one year ago I was applying this same patch. So when is this going to get into views? v3.10 was just cut this week for a security issue.

I can confirm as well the patch did NOT make it into 7.x-3.10 ... re-re-patching.

Confirmed - also needed to re-patch after security update.

Confirming that the patch in #37 works for me too.

Patch in #37 works for me.

#37 did not fix this for me. I did clear all caches, multiple times.

Drupal 7.34
Views 7.x-3.10

This bug needs to be squashed. Lets elevate this to a critical issue because there have been so many of us that have to keep re-patching views ever time a new version of views is released. It's a simple patch with multiple people reporting success in production environments. This is read to be committed. Please commit or report a reason it should not be.

confirmed working.. please commit

Drupal 7.34
Views 7.x-3.x-dev

+1 for commit and consideration in next stable release to get this away :)

37 worked for me. Every time I install a new site I need to remember to apply this patch. Commit? :)

To avoid that problem I use a drush make file to download all the modules with the patches I need

+1 - Hope to see the patch included in #37 included in the next major release. This really makes our sites fly, without errors!

Have been using #37 on a large university website. Works like a charm!

Thank you for your patience.
Committed to 7.x-3.x

.

Is it possible to have this in the next stable release too? The message is really annoying.

Just patched my site. Everything is fine and the error is gone. Hope this can make it to the stable release so when Views gets updated, I won't need to reapply the patch.

@Anybody and @dmegatool: this patch has already been committed to dev, which means it will be included in the next stable release of Views. In the mean time, you can either manually patch 7.x-3.10, or install 7.x-3.x-dev.

I didn't know that if something make it to the dev version it will absolutely get on the next stable release. Thought it was more of a testing process. It sure looks like everything is fine but I guess if someone would find something, it would get pulled.

Anyway I'm cool with my patched 3.10. Thanks for the clarification.

@dmegatool: The dev release just represents the latest commit in the 7.x-3.x git branch. Patches are generally only committed after they have been reviewed and tested by the community. Then at some arbitrary point in the future, assuming no more problems are found, the maintainers will tag a commit as the next stable release, but that all happens along the same branch used for development.