Disable then enable views displays errors
hga77 - November 8, 2009 - 15:03
| Project: | Views |
| Version: | 6.x-2.7 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Description
Hi,
After updating to views 6.x-2.7 from views 6.x-2.6, I get the errors generated on the image attached.
I also disabled views module, then re-enabled it but still same errors again.
It seems to be working though but I'm not sure we should be getting errors.
Does any1 know whats going on?
| Attachment | Size |
|---|---|
| Modules - Momentumww UK_1257692549769.png | 539.48 KB |
#1
#2
The last sql looks like views_view is empty. Can you check this?
I think this error is not really easy to reproduce.
Can you try to reproduce it on a clean drupal, perhaps it is possible that the error is only on acquia drupal.
We have to be able to reproduce it. I hope you understand it.
#3
The table 'views_view' isn't empty (image attached).
#4
I can also confirm that on a new Acquia Drupal install (which initially has views 6.x-2.6), updating to 6.x-2.7 works as expected without any errors.
[EDIT]
However, I'm not sure this is true since I didn't add any display views when I did this test. So probably this is why there were no errors. If you'll notice what was said below, the warnings show up only when display views exist and are enabled.
#5
Note that I made a backup copy of the database before I attempted the views update. I reverted to that database copy (i.e. back to views 2.6). I then attempted the same process to update to view 2.7, but still same errors.
It must be something in my database thats causing the update to break!
#6
Could it be a conflict with another module? Maybe workflow or revisioning!
#7
Ok, I just tried another test and now it's more strange.
I reverted to my 'working' database copy (so again, back to views 2.6). Ofcourse when reverting database, I also revert the source files. On the modules page, I disabled view 2.6 then re-enabled it (without updating views or anything else). I get the same error!
So this issue is nothing to do with views 2.7. Something went wrong in my current views 2.6 :(
#8
I've attached image of errors when disabling/enabling views 2.6. Notice the sql error is now on line 1318
#9
I've attached the views_display table
Does anything seem wrong?
#10
How do you do the updates?
I'm wondering why you are at admin/build/modules
Could you try once, to reproduce it on a normal (non-acquia) drupal?
#11
I take the following steps to update,
- go to admin/build/modules
- disable the module that I want to update (by un-ticking the box), click submit
- delete the views module folder (modules/acquia/views)
- add the latest views module folder
- from admin/build/modules, enable the views module, click submit
- here I get the error
I would then goto update.php
But I don't think it's the update thats the issue now. Even if I don't update to 2.7, and just simply disable then enable 2.6, I get the same error.
#12
I tryed this too, and it does not appear.
Did you checked after the update, whether the views you have defined work well? There could be a distinct between acquia-views2.6 and views 2.6 i didn't tested yet.
#13
I deleted all the view displays I created from the Views UI. This deleted all the rows from both views_view and views_display table. I then disabled/enabled 2.6 and it didn't show any errors.
Looks like I have some corrupt views stored in my views table. Can this happen?
#14
Sure it can, php drupal views and mysql aren't perfect software
#15
#16
This is so wierd. I disabled and uninstalled most modules. I also uninstalled views module (this deletes all views tables).I then enabled views again (I don't get errors here since we don't have any stored display views at this point). Then I added a new view display using views UI. Disabled then enabled views, again I get the errors...
This is so annoying
Looking at the error:
"Invalid argument supplied for foreach..." I debugged this and it is recieving a valid array, $schema['fields'].
But it still generates this error, in views/includes/views.inc:
function load_row($data)
{
$schema = drupal_get_schema($this->db_table);
// it's complaining here that $schema['fields'] is invalid
foreach ($schema['fields'] as $field => $info)
{
...
}
}
I just don't get it!
#17
I also noticed this issue when I upgraded Views on a (non-Acquia) development site of mine.
Drupal: 6.14
PHP: 5.2.9
MySql: 5.0.67
The first time I re-enabled the module after upgrading, I got the same series of foreach warnings and the additional error mentioned. Since then, if I disable, then enable Views, I see the warnings and errors again. The only thing I can add to this is that the number of foreach warnings seems to correspond to the number of enabled views. So, in line with what was mentioned above, deleting all the views on the site kills the warnings.
Status Message:
And then:
query: SELECT * FROM views_display WHERE vid IN () ORDER BY vid, position in /home/android1/ecafrica.androidshepherd.com/sites/all/modules/views/includes/view.inc on line 1352.
#18
can you check every view, whether its broken?
#19
The views in my case are not broken. Everything displays as it should on the front end.
#20
I'm not alone.
acephale, I have exactly the same problem. And I can also confirm that the number of the foreach warnings are the same as the number of enabled views. And deleting all views kills all warnings. It's obvious that the query successfully loads all enabled views, but why can't it use the loaded views data?
My views are also not broken and work as expected.
I'm not upgrading to views 2.7 until this issue is resolved.
Drupal 6.14
PHP 5.2.9
mysql 5.0.51a
#21
In #15, when the schema fields is coming up invalid, can you do a dsm() (or equivalent) on $schema and see what is being returned?
If drupal_get_schema() is failing, there's something very strange going on in the database.
#22
Marked http://drupal.org/node/388598 as duplicate.
Turning this to active, though we still need to figure out what is causing drupal_get_schema() to fail.
#23
I inspected $schema with dsm(), dvm() and firep() (image attached for each).
dsm($schema): returns nothing
dvm($schema): returns bool(false)
firep($schema, 'Schema'): returns the $schema array. Why does this return the array but dsm/dvm doesn't?
These results are after enabling Views module (i.e. ticking the checkbox for Views module) and clicking 'Save configuration'. This ofcourse is where the warnings occur also.
I placed those functions individually on seperate code runs, in views/includes/views.inc:
function load_row($data)
{
$schema = drupal_get_schema($this->db_table);
dsm($schema);
dvm($schema);
firep($schema, 'Schema');
// it's complaining here that $schema['fields'] is invalid
foreach ($schema['fields'] as $field => $info)
{
...
}
}
I also tested $schema (and $schema['fields']) with the php function is_array(), returns true.
#24
hga77, first, thanks very much for the extensive debugging you're doing.
The results of your debugging are even weirder. I have no explanation for why 2 of the 3 debug methods would show no schema, but one would. I have no explanation for why the schema is even not present.
The schema files are cached, so the implication is that perhaps something is failing in the schema system. Perhaps the cache is failing (are you using a non-standard caching mechanism) or perhaps you have a module that is trying to load a view so early in the bootstrap that something is causing the schema read to fail? Putting in a vsm_trace() might tell us where the views are being loaded from, though I'm not sure how helpful that information really is. It may be worth something.
At this point, I am tempted to ask for a copy of the database you have and see if I can reproduce this on my local system and do some tracing as well. It is possible that we're looking at a core bug in the schema system, but it is also possible we're looking at some kind of race condition that isn't really a bug.
A complete list of modules that you have active on the system might help as well; this may be caused by some other module interaction, since I"ve never seen this and most of the people I work with have never seen this, yet these things are reported sporadically. It may also be related to install profiles, as in the past people have had issues with Views and install profiles if the order isn't right (and the 'right' order seemed random).
#25
merlinofchaos, Thanks for the reply.
I'm not using a non-standard caching mechanism, as far as I'm aware.
About a list of the modules I have, they are on the images I've attached.
I was thinking, maybe this problem occurs after I import the database (i.e. restore, revert the database). Maybe something gets screwd with the db schema, table indexing, collation or something of that sort.
I'm really behind on a few things at the moment but will post anything new I find soon.
#26
Does doing a clear cache make the problem disappear?