Disable then enable views displays errors

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.

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?

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.

Sure it can, php drupal views and mysql aren't perfect software

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:

• The configuration options have been saved.
• Skipping broken view

And then:

• warning: Invalid argument supplied for foreach() in /home/android1/ecafrica.androidshepherd.com/sites/all/modules/views/includes/view.inc on line 1727.
• warning: Invalid argument supplied for foreach() in /home/android1/ecafrica.androidshepherd.com/sites/all/modules/views/includes/view.inc on line 1727.
• warning: Invalid argument supplied for foreach() in /home/android1/ecafrica.androidshepherd.com/sites/all/modules/views/includes/view.inc on line 1727.
• user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY vid, position' at line 1
  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.

can you check every view, whether its broken?

The views in my case are not broken. Everything displays as it should on the front end.

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.

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.

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

Does doing a clear cache make the problem disappear?

Had about the same problem.

Finally figured I forgot to put a "return $schema;" at the end of a custom modules "hook_schema".

Still don't know why on earth Views would be involved there anyway...

Same problem when updating from 2.7 to 2.8. Never used older views versions on this site.

Just to say that I got this error too, caused by one of my custom module's hook_schema() function returning an empty value (not an array).

It seems that a non-array result from hook_schema() causes the cached schema array to get corrupted, at which point all sorts of things (not least node_load()) start failing.

Hi guys,
I'm not very familiar with Drupal's "under-the-hood" stuff, so I didn't get some parts of your discussion, but is there an actual solution to this bug/error?

I am just trying to create my first view on almost clean system, following the online tutorials, but keep recieving this error messages.

Thanks in advance

Well, #27 indicates that apparently this can be caused by other modules improperly using hook_schema(). So far that's the only known for sure cause, though there may well be another cause that we have not yet figured out.

Hi all,

This error just came up for me too during development. It happened as soon as I enabled mimemail-6.x-1.0-alpha2 (http://drupal.org/project/Mimemail latest D6 release) and Send 6.x-1.0-alpha3 (http://drupal.org/project/Send) modules. Is anyone else using Send & Mimemail module hen they get this error?

If hook_schema() is causing problems with views then maybe someone wants to notify other module developers so they can fix their modules? :)

Meanwhile, any ideas on a quick hack (other than hiding the error warning) that could fix this?

Thanks!

At this point, I am starting to think that there is a core bug with hook_schema() here that's causing this.

I can confirm #29's findings:
Just created a new module with the great Module Builder module and had an install file generated. I enabled my module before providing anything to the skeleton install file - content as follows:

// $Id$

/**
 * @file
 * TODO: Enter file description here.
 */

/**
 * Implementation of hook_schema().
 */
function assign_shifts_schema() {

}


/**
 * Implementation of hook_install().
 */
function assign_shifts_install() {

}


/**
 * Implementation of hook_uninstall().
 */
function assign_shifts_uninstall() {

}

-- edit --
The views error disappeared after deactivating my custom module.

I had similar problems, and just confirmed that I forgot to have "return $schema" at the end of schema hook. After I added that line, all warnings are gone.

I suspect there are something incomplete in the schema loading mechanism, which does not check for empty or non-returned schema hook, but let it spread to other areas of code instead.

I have made my way to this thread from taking the link in the 6.2->6.3 WSOD. I am able to upgrade from 6.1 to 6.2 without a problem. But, when I try to upgrade to 6.3, I get the WSOD when I try to run update.php or go into admin/build/modules.

Is there any fix for this? Do I need to search through all the modules installed on the site to see if any is forgetting to do a return $schema? Should I look just in the .install files or should I use grep to search for _schema in the entire sites/all/modules directory?

I really need to get at the ability to turn a field into a link and it seems that was added in 6.3 #349178 by agentrickard: Add generic link handling plus a custom text field. Also automatic trimming.

By the way, when was the "rewrite the output of this field" added? I could use that as well to wrap the field in an anchor tag and make the link myself. I notice in the changelog.txt a reference to #405130 by dereine: Make the output field rewrite a textfield rather than textarea. for 6.4. But, I don't see the rewrite ability in 6.2, just the "link this field to ..." option. Was the rewrite ability also added in 6.3 or am I missing something?

vegantriathlete: i think you are mixing a bunch of different issues please stay on topic.

can anyone confirm that this is still happening on their systems even after upgrading to 6.x.2.11?

If so, as per my converstation with merlinofchaos on irc, we'll make this an unassigned task to try and avoid the crashing, and throw out an error.

I'm still seeing the error when I disable and then enable the module and I'm running 6.x-2.12.

    * The configuration options have been saved.
    * Skipping broken view 

    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * warning: Invalid argument supplied for foreach() in sites/all/modules/views/includes/view.inc on line 1747.
    * user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY vid, position' at line 1 query: SELECT * FROM views_display WHERE vid IN () ORDER BY vid, position in sites/all/modules/views/includes/view.inc on line 1369.

As this thread says, so far as we can tell, this is always due to a bug in Drupal core + a module improperly implementing hook_schema(). There is very little that Views can do about this.

Marking as closed based on comment #39