Fields not available anymore in fields add (cache issue)

Have you tried applying the fix at #1949178: Notice: Undefined property: stdClass::$machine_name in views_plugin_argument_validate_taxonomy_term->validate_argument() (line 1?

I had the same issue and it appears to be an issue with memcached. When turning off the memcached service, it works, and when turning it on, most of the groups are missing.

Perhaps there is some code integrating with the cache apis causing this issue.

I'm having the exact same issue in all my views. I posted this http://drupal.org/node/1961312.

I don't use memcached, but have caching turned on and the Boost Module enabled. This started happening since updating to 7.x-3.6 .

I also use Views Bulk Operations, could it be related to that?

I am also getting notice errors for variables in views see http://drupal.org/node/1959074.

Thank you.

Same thing was happening for me - spent hours googling for solution, so thanks! Downgrading to 3.5 solved the issue!

I'm able to get all of the fields back by doing the following: Checking 'Disable views data caching' and 'Disable JavaScript with Views' in the views settings tab. You then need to hit the 'Clear View's cache' button. See the attached screenshot. The fields revert to being unavailable again if both these checkboxes are left unticked.

I also upgraded to 3.7 before doing this

It's not really a workable solution or even a workaround as performance suffers considerably. Does this mean the issue is related to javascript and caching?

Is anyone else having this issue able to try this?

Thank you.

Disabling the views data caching solved the issue for me

We were experiencing the same issue. I tried disabling views cache data only and that worked for me. I re-enabled it again after and it went back to not working - but the view was saved and working.

I'm having the same issue, first with 3.6 and now with 3.7. Reverting back to 3.5 fixes the issue. I was really hoping this issue would be fixed in 3.7 but it isn't.

Same issue for me too. As soon as a view (page / block etc.) is saved, I cannot access to any of all existing fields to add a new one.
For those who downgraded the views module 3.7 (or 3.6) to 3.5, what is the procedure you used for this installation ? (I didn't find any sure way to downgrade a module). Thanks in advance.

I'm not sure, but think my question would sound stupid. After update Views from 3.0-alfa1 to 3.7 all my old views became broken and unavailable. Does that mean I should create the new ones without trying to import or smth?

The machine_name fix as suggested in #2 doesn't seem related to this issue. For lack of anything else to try, I tried applying the machine_name patches, but none had any effect.

I'm happy to try any other viable solutions. This is a critical/major issue which I'm hoping can be resolved. I would rather not revert back to 3.5 because of the security risk and turning off views caching would cripple performance on my site.

I think this issue is related to this #1955472 . In my opinion both these issues have the same root cause and this I think is due to changes in the cache.inc file in 3.6/3.7 .

#11 - For some modules, reverting back can be an issue. However, reverting back to views 3.5 should be as simple as replacing the /sites/all/modules/views folder with the 3.5 version. If you don't already have the 3.5 version on file you can find it here:

http://drupal.org/node/38878/release

After downgrading, run the update script and that should be all there is to it. Hope this helps.

#15. Thank you Scott. That is the procedure which allowed me to add views 3.5 without any problem.

Just for information : previously, I tried this procedure : desactivation of [Views Slideshow + ViewsUI + Views Content panes], desactivation of Views, then uninstallation of Views. Installation of Views 3.5. Activation of the aboves modules and udpdate script start. As a result > all my views desapeared!

I suppose the changes are too numerous so that you have to create all views again.

comfirmed disabling views caching under advanced tab works...... :)

hopefully this will be fixed for the next release.

Also fixed problem by reverting to 3.5. Disabling views cache solved the problem in 3.7 but would destroy my site performance-wise.

Thanks for the workaround in #7! I never would have figured this out. Fortunately the site in question rarely needs changes to views, and now I know not to upgrade Views on my other sites until this is fixed.

Same issue. :(

Any hopes of a fix? Seems like a major bug

Could this be a server version issue? On my localhost I didn't have any trouble adding new fields, on the live site with the same modules and database my fields list was almost empty. On the other hand, on a newly installed site with not so many modules and Views 3.7, I have no problem either.

As far as I can tell, this is still a problem for sites that have Views already installed prior to 3.6.

Given that 3.6 is a security fix, I would have thought that this is a priority issue. Is there any chance that it's been addressed in the latest dev version?

I don't want to blame anyone but due to the symptoms of the initial post, could this be a problem related with https://groups.drupal.org/node/274838 ?

Another possible issue could be #1889198: Performance problem in _views_fetch_data, multiple unnecessary cache rebuilds

So everyone who went into this problem. Can you please setup a site backup with this patch reverted (or a git checkout before the commit)
and see whether this problem still appears?

I tried to reproduce and as always I'm to dump for that, it would be great if someone could reproduce that on a fresh install and give me the database and code for example (this would be wonderful).

I have been seeing this problem for some time (the first, maybe 3 weeks ago) and decided to investigate today. Last night I was working on a new view and it happened again. I added a few fields initially and after saving and previewing, went back to add other fields only to find that add fields only contains the content type property fields (post date, sticky, title, etc.). The fields attached to the content type are no longer an option.

I did not upgrade from a previous version of views. This is a fresh install of 7.x-3.7.

When I first ran into the problem, I was able to work around it by exporting the view, deleting it and reimporting.

Today I did try disabling the cache and this does seem to resolve the issue without deleting the view.

Hi Cameron,

Yes disabling the cache does seem to work, but it's not really an 'acceptable' solution, particularly on larger sites. It kills performance.

Certainly, you should turn the cache back on once you finish adding the fields you need. I was just confirming that you can do this to work around the problem and it's faster than exporting/importing the view.

Ah, I didn't realise that - that's what comes from not reading everything properly - thanks Cameron! :)

i have same issue with 3.6 and disabling the cache solved it, temporary I guess.

We were having the same issue with 3.6 and 3.7 so I delayed updating until we did a full scale update of our website. Since updating Core to 7.22, Views to 3.7 and Views content cache to 7.x-3.0-alpha2 (related? who knows..) Views appears to be running properly, no cache disabling necessary to work on the Views.

posted by mistake.

move along.
nothing to see here... :)

I had the same problem, disable cache works in 3.7

Yep,

also solved by disabling the views data cache

Was there a working solution to this besides those related to reverting to 3.5 and disabling Views Data Cache? I am running Views 3.7, Drupal 7.22, and not using Views Data Cache and am experiencing this bug when creating views with Field Collection Items. After saving the view the first time and going back to add more fields I am only given a few fields to add.

Confirming for me too that disabling the Views cache causes the fields to re-appear as expected.

I had the same problem and yes, disabling Views' cache solves the problem but this is not a good solution.

Did someone managed to read my post in https://drupal.org/node/1954348#comment-7511477 and try to reproduce whether the change in there caused a problem?

FWIW, I was having this problem after enabling the 'memcache' module in D7, and resolved it by setting the following in settings.php;

$conf['cache_class_cache_views'] = 'DrupalDatabaseCache';

Thereby allowing Views to use the "normal" Drupal cache.

This does not appear to hurt caching of views data in Memcached, as I confirmed by enabling memcache_admin module and browsing a few pages on the site I am working on (there were still plenty of Views data "hits" on each page). I believe this is due to a separate cache class for "...views_data", which is not affected by the setting above - although I did not research that part extensively.

Updating settings.php as #38 suggests didn't work for me.

I'm not using memcache for the site I tested so it's still possible this fix may help others with memcache enabled.

I also have this issue using "views 7.x-3.7" and by selecting to "Disable views data caching" corrected the issue instantly.

I get this same issue on D6 and see no bug reports for it there. Curiously the first few fields are not in alphabetic order as well.

I was having the same issue (Fields, filters, ...) not being fully displayed on the views UI. After setting up the cache_views to use the database (mysql) as explained in #38, the field just showed up again!
I am using memcache and have enough free memory in it.

I am not using memcache so #38 doesn't apply to me. and turning off views caching doesn't fix it either.

Well, for me only works if i disable javascript in views. So, for now if i have to edit views, i disable javascript then when the work is done i enable javascript. But i hope this is only temporary solution.

Waiting for fix...

I had this problem, and noticed it started when I set jQuery Update to use 1.7 with admin pages. Once I turned back to 1.5 it seemed to work again as required. Anybody else notice this?

I recently posted that i had javascript issue. I have Clientside Validation version 1.38 module installed and discovered that this module was an issue. Here is the solution, I used #5:

https://drupal.org/node/2112073

Hope this helps anyone.

@dawehner I tried reversing the patch from #1889198: Performance problem in _views_fetch_data, multiple unnecessary cache rebuilds and it didn't seem to make any difference. The only thing that seemed to help was opening the edit page and then clearing the Drupal cache before clicking "add fields." In that scenario, clearing the Views cache made no difference, but clearing all caches would, for the first request. Subsequent requests would be missing fields again.

I'm going to try looking into the effects from https://groups.drupal.org/node/274838 since clearing the Drupal cache is the only thing that seems to have any affect on the bug.

thanks patkins,
#40 work on me

The same problem with dev version.
Killing memcached and clearing the cache fixing the issue temporary.
#40 fix by disabling views cache fixes the problem.

#40 works as a workaround for me too

For me, #38 was the best hint:

#40 is dangerous if server is on production.
And it seems that sometimes memcached or Drupal may crash and returns partial result, stored in memcached.

To fix this, simply restart memcache service

service memcached restart

So we've just hit against this on a very large Drupal project.

Symptoms were the filter drop down when adding a new field in an existing view only contained global things, was missing things like OG Membership etc etc.

Switched the caching backend to Database away from Memcached and the field behaved itself.

The fix for us was to increase the size of the slab that memcached allows. You do this via the CLI with the -I option, default is 1Meg, we've increased it to 3 which works for us. You'll get a warning, but from our point of view it is worth it. Another option could be switching to Redis which wouldn't hit this memory issue.

However Drupal shouldn't be failing to show things because memcached doesn't have a cache for it, so it looks like a bug in Views caching.

This line: http://drupalcode.org/project/views.git/blob/HEAD:/includes/cache.inc#l70 either returns back an Object or false. I think that this means that this line http://drupalcode.org/project/views.git/blob/HEAD:/includes/cache.inc#l75 will return false if $cache is false. I don't know enough about the expected behaviour here to know if that is right or not.

Hope this helps someone, was a day of tearing Drupal apart to figure this out for me!

Disabling Views Caching seems to have fixed my particular issue.

#38 fixed the issue for me.

#40 and reloading Apache worked for me. I have a Linux server. I did all the suggested fixes so I am not really sure what fixed it. But it works.

I don't know how to restart memcache service but Disabling Views Caching worked. As long as it slows down the server I tried solution #38 posted by - samtny. It works fine yet. Thank's samtny.

Why does this happen with views? hope the problem will be eliminated in next releases otherwise Drupal is useless without views module.

I found that aforementioned solution #38 which I think is still the best solution has some problem for translated content. I've content type with translations and by filter criteria of views module it is showing same content in two languages depending on which language a user has chosen. English worked, Georgian - not. Flushing all caches helped. I Still don't want to slow down the site by disabling views data caching but eventually I'll have to if the problem appears permanently.

@zura_lanch Changing the cache backend is unlikely the source of this sort of caching issue. It has likely nothing to do with using Drupal's default database based cache backend. Try reverting to the memcache backend after editing your view, I'm pretty sure you will still have the same issue.

mongolito404 I checked the site and views worked on both languages correctly. I tried to edit view but there where no fields again. I didn't save the view, just canceled and closed views edit page. But the problem accrued on front end too. After flushing all caches it started showing fields correctly on English version, then I clicked on Georgian language icon and flushed all caches again and fields appeared on this language too (these are just blocks of one view). It is strange that the "cancel" and "save" buttons are active because when you click on edit view usually these buttons are active after making some changes. Total headache....

Can you please explain how to do that in detail? What if I make a new view with same fields? will fields disappear again?

Thanks.

This isn't a great solution, but the problem only appears to exist with the PHP extension memcached.

If you use memcache instead it works.

Unfortunately memcache is quite a bit older, but it could possibly be an ok stop gap. If your site is heavily reliant on views I would've thought using memcache would possibly be better than using the druapl default views cache but I've not benchmarked this. (although is #38 is correct then it caches the data anyway).

I have the same issue, APC cache, random broken handlers, had to disable the view cache..

Same issue, I don't use Memcache or anything related, disabling views data caching fixed the issue but is not a real production safe solution.

When this happened I didn't know how to react, and the messages from the views module (your view was fixed) mislead me into clicking save, thus loosing the view (I lost 2 views until I realized my mistake). This bug should be fixed as soon as possible, as it can really end up destroying sites.

Same issue.
Disabling cache in views advanced settings (admin/structure/views/settings/advanced) make it work, but it is not a solution for production sites. Any progess on this ?

Marked #2154459: Custom fields not showing up in Views 3 as a duplicate, noted that this doesn't just affect memcache.

I have the same problem. I'm running views 7.x-3.10.
I have tried all the solutions mentioned in here but all without succes.

Hope some else has another solution.

I'm also encountering this problem for the first time in 2 years. Disabling cache in Views does fix the missing handlers/fields but is in my opinion not a solution. The weird thing is that on our local server we have the same files and DB and are not encountering this problem. The problem only occurs on our live server...

We are not using memcache.

It's possible this is related to #1944674: Improve performance of ViewsDataCache, though that would put it at version 3.8.

In any case, you could try the patch in comment #42 of that issue.

I wasn't seeing this issue until I installed the recent Entity update (7.x-1.6; using Views 7.x-3.10). Reverting to earlier version of Entity, disabling and then re-enabling Views data caching brought the missing fields back. But this is a pretty sub-optimal solution, since the Entity update is a security update.

I'm not sure it's related to the recent entity update, as this issue has been ongoing for a long time before that patch.

For me was this problem solved by changing Memcached configuration file (/etc/memcached.conf) by adding line

# Increase max entry size
-I 20M

This increases max memcached entry size to 20 MB (default is 1MB). This is better work around than disabling Memcached for Views.

Hope this helps

(offtopic a bit)
That worked @petr.hajek? I thought last time I tried to do that that it had to be added to the init.d start script if you wanted it to actually persist that item size change. I could be wrong, or they could have fixed that... It's a fairly new option (few years) and last time (Sept 2014) it wouldn't take in the config, only as an argument to the start up script.

Anyways latest versions of the memcache module have chunked out items larger than 1MB into pieces so this wouldn't happen. And you have an option to configure this chunking: #435694: >1M data writes incompatible with memcached (memcached -I 32M -m32)

Related #1945712: Fix 1MB maximum size limit for cache_set()

remember- I've got the same problem WITHOUT memcache so I don't expect it can be solved that way?

I don't use memcache either, and tried every conf changes, and memory limit increases without success. The only way to make it was to disable cache in views, wich is NOT a solution. And anyway, increasing memory limit or cache limits is not a solution either : You can kill a fly with a bazooka, it doesn't mean that it's the better way to do it, and it looks a little overreacted.
There should be a way to make it work without overloading the system.

@joelpittet Yes. It solved the problem. But as I mentioned. It is not a proper solution of the problem - its one of workarounds, better then disabling views cache.

This issue seems to be about memcache by most comments and the issue summary.

@petr.hajek thanks, I'll try that next time I use memcache!

For those who aren't using memcache, it may be a different issue, though I'd like to hear from the original poster because someone changed the issue summary to make it memcache specific.

Either way this issue "need steps to reproduce" to weed out unrelated issues.

Just created another issue which could explain the issue you see here (Patch & Tests included): #2475669: _views_fetch_data() prone to inconsistency (Especially with redis / memcache)

#2475669: _views_fetch_data() prone to inconsistency (Especially with redis / memcache) landed so I think this issue is resolved?

flush the varnish cache worked for me :

echo flush_all >/dev/tcp/127.0.0.1/11211

No, this issue isn't resolved. Even with Views 7.x-3.11 I have to clear the Cache manually every time I changa a View, because otherwise I get broken handlers.

By the way: This issue should not be about memcache cache. I've got this problem without using memcache, like others too.

This is not resolved. Even on 7.x-3.11, PHP 5.5 and MemCache this is still happening.

Based on #54 comment i was able to fix our setup.

I did set memcached to use 5M slabs and set the memcache module to split the data in some bytes less than that./
For instance:
- Drupal side: $conf['memcache_data_max_length'] = 5242000; which is less than 5MB which is 5242880 B.
- Memcache daemon: Added option -I 5M

This solved our problem with views. I have not look into the module, but my guwss is that there's some issue in the memcache procedure of "splitting" the cache data and reassembling it.
So i think the main issue is in memcache module? Just a random assumption.