Error upgrading Views 6.x-2.12 to 6.x-2.14

Do a cache clear. This usually indicates some kind of broken schema cache.

Not the Views cache. I said schema.

There is only one change from 6.12 to 6.13 and that has to do with a db safe value; there must be something else going on as part of your rollback/upgrade process.

Typically I use drush and 'drush cc all' will happily clear all the caches.

There's a button on the...I think it's admin/config/performance (not completely sure) that will also clear all caches.

I don't know what to tell you. The upgrade from 2.12 to 2.13 had just one patch which shouldn't have any effect like this.

I had the exact same issue this evening.

Current hypothesis is that somewhere along the way, the Blocks to which Views are assigned went missing. Manually assigning them back seems to be working, but need to vet that approach still.

Not sure how or if the schema update 6011 did it, but the {blocks} table seems to have been damaged in the upgrade - the 'region' and 'pages' fields are blank, which would of course make those views vanish. Rolling back to an earlier {blocks} table seems to help that.

I had the exact same issue. Same error message. I just rolled it back in Drush though.

I'm going to run it on a dev site.

*Edit*

On the dev site the upgrade went perfectly. Update.php ran correctly and it went from 2.12 to 2.14 just fine.

This smells like a module conflict maybe?

I had the same error message and my Views-driven blocks disappeared, too. I rolled back to a snapshot of the server and started again, this time with more caution. Here's what I did:

1. Switched off all modules that depended on Views (Calendar, Views RSS etc), which allowed me to uncheck the Views module
2. Deleted the old Views directory and installed the new one
3. Turned on just the Views module and got the error message ("Invalid argument supplied for foreach()...")
4. Went to /admin/settings/performance and cleared cached data. This got rid of the error message.
5. Turned on all the modules dependent on Views
6. Ran the database update script

That worked for me. I'm guessing it was having the Views and its dependent modules enabled that messed up my blocks. It's fine now.

I'm not too sure. Personally, I don't turn them off at all unless it's a major upgrade. See this:
http://drupal.org/node/672472
Perhaps that's why I ran into trouble this time. Incidentally, I threw my instructions in fairly randomly - I see now they don't really address your problem because you've said before you tried turning Views off. I can't think what's causing your problem, I'm afraid. Is it worth going through the painstaking process of turning all the other contributed modules off before upgrading, if you haven't tried that already? Or disabling all the blocks before upgrading?

All I've ever been able to figure on Tytest's problem is that, somehow, some module is messing up hook_schema and when Views goes to load its data, it asks Drupal for the schema to use and its' not available; this causes all Views to fail to load. That's what that error means, anyway.

When the error is not showing up, then I'm *really* uncertain what might be going on. I can't duplicate this on my test systems at all. I suppose if you want to try to explore you might put some debugging messages in views_block() and views_menu_alter() to see if you can see what data it's giving back to Drupal. Perhaps posting a comparison of pre-upgrade and post-upgrade results from these functions might give us some information?

One thing -- check the schema of views_view directly in the database. Did update properly add the 'core' field?

You should see something like this:

mysql> desc views_view;
+-------------+------------------+------+-----+---------+----------------+
| Field       | Type             | Null | Key | Default | Extra          |
+-------------+------------------+------+-----+---------+----------------+
| vid         | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| name        | varchar(32)      | NO   |     |         |                |
| description | varchar(255)     | YES  |     |         |                |
| tag         | varchar(255)     | YES  |     |         |                |
| base_table  | varchar(64)      | NO   |     |         |                |
| core        | int(11)          | YES  |     | 0       |                |
+-------------+------------------+------+-----+---------+----------------+
6 rows in set (0.00 sec)

Hmm. I wonder if this indicates that there is something mistaken in the update. It's trying to correct for mistaken block configuration but it should only be for exposed filters in blocks, not views blocks in general.

Can you provide the results of this query both before and after:

SELECT * FROM blocks WHERE module = 'views';

Any resolution on this? Was about to upgrade to 6.x-2.14 from 6.x-2.12, until I read this thread. Tks all for posting.

Still waiting for someone affected by this to post the results of the queries I asked for.

Sorry - perhaps I should have mentioned that I've asked an IT guy to roll back a test server to where it was before I upgraded. Then I'll have a go at replicating the error and getting the results of the SELECT mentioned above. I was just waiting for that - it should be tomorrow (Tuesday in the UK). The weekend delayed things.

Ok, rereading the thread, the 'blocks' issue is not related to the original post. Let's handle that at http://drupal.org/node/1332348 -- please post the block information there.

That leads me to not being sure if the original issue this post is about (and is titled about) actually is still a problem or not.

All right. I'll see how persistent a problem the original one is when I try to upgrade. Meanwhile, I'll post the blocks information on the other thread.

Mh this changes can't be explained by http://drupal.org/node/1332348#comment-5215472

When I just used drush to update now from 6.x-2.12 to 6.x.2-14 - when a create a brand new view, vanilla install of Drupal 6.22, my view won't save.

The first part of the warning is:

user warning: Unknown column 'core' in 'field list' query: INSERT INTO views_view (name, description, tag, base_table, core) VALUES

I then downloaded 6.x.2-13 and the views now save.

@sideswitch
If you have this error you didn't runned update.php

#35: Please don't hijack issues.

Tytest: Well I'd asked that we move the 'blocks' conversation over to #1332348: After Updating Views, All Enabled Blocks Disabled and Settings Lost.

In your post the only thing that's changed are the block IDs. I don't see how the blocks should've disappeared or anything. That data is correct. So we're kind of back to zero, having no idea why you're seeing what you see.

I have the same original problem "Error upgrading Views 6.x-2.12 to 6.x-2.14"

Trying to update from Views 6x-2.12 to 6.x-2.14 completely broke my site. I could not even access the update.php page.

Cannot afford to loose blocks or ANY views settings.

any solution ?

#37 @merlinofchaos: Terribly sorry! I thought the title "Error upgrading Views 6.x-2.12 to 6.x-2.14" was the same as mine. I was mistaken. Should have read more thoroughly.

PS: #36 @dereine Found that drush updb, run (multiple times) didn't fix the problem, manually running update.php did fix my problem.

I also got an error on the update itself that stopped the update script from running.
"aborted prematurely while running update #6013 in views.module"
then there were no log errors and the DB didn't have the fields updated.

I tried removing the 6013 update from the install.info and ran it with just the 6011 but it still aborted before anything was done. I then removed the 6011 update put the 6013 update back in..same result.

I have since updated the db manually as I have not had time due to it being a live site to muck around anymore. But even still with the update done manually I've tried run the update script just for the heck of it and its still getting aborted..

Any thoughts? I'm hoping this is still on the same issue. Seems to be.

Modules Installed(all update versions):
ubercart
nodewords
ckeditor
pathauto
Contact Save
token
image cache
node import
date
admin menu
cck

So, what's the upshot of all this? What is the best way to upgrade from 2.12 to 2.14? Don't disable Views before updating it? Disable views-related modules before? Follow the protocol in #19? Is it improper to disable a module before updating it? Thanks.

So far as we can tell, don't disable Views before upgrading and it'll go more smoothly. Always perform a backup.

Hi all,

I'm trying to figure out why upgrading Views from 6.x-2.12 to 6.x-2.14 is causing my content to disappear from my site Taxonomy term template (/taxonomy/term/%term) pages.

I've followed the steps in #19 with the exception of disabling the Views module (#42). When I go into my view and do a preview the list of nodes appears fine but when I try to preview my page with the argument for a valid term ID that I know should have viewable content the preview is empty and template page is empty when viewed through the URL alias:
http://example.com/my-category/my-term.html

But if I view the page via the drupal path the list of node content will show up as expected:
http://example.com/taxonomy/term/6

Does anyone know why this would happen and what I can do to resolve the issue. I'm sorry that I can't provide links to a site that displays this but I've rolled back to 6.x-2.12 on production and only have the problem available on my development environment right now.

Hi all,

Just after I posted this I edited one of my URL aliases, did not make any change but clicked the "update alias" button and voila all my content was displaying fine. Before you say "it was a cache issue then" that may be but I did clear all my cache more than once. This seems like a bug to me. Anyway, I hope this post helps someone else.

-johnny;j

Views has no interaction with the aliases. I don't understand why that would be happening but I don't think it could be Views' fault.

Hi All,

Firstly thank you for the most incredible module ever !

Finally got it working updating from Views 6.x-2.12 to 6.x-2.16.

Here is what I did.

1. Delete old views module
2. Replace with new views module
3. Ran the update script and got Error 500 - internal server error.
4. Deleted all views related modules - in my case (views_attach, views_clone_display, views_customfield, views_groupby, views_hacks, views_rotator, views_slideshow, views_two_column_table)
5. Ran the update script again, this time it worked and views updated.
6. Uploaded all the deleted views related modules back to server. (see 4.)
7. Site working perfectly after update.

update: on one site after the update of views - views_clone_display broke the site blocks. I deleted the views_clone_display module files and all block were fixed magically. So it seems this was preventing the update script to run and views to update correctly.

- Simply uninstalling views_clone_display was the answer - views updated perfectly.

Yes, that module might have been my problem, too. See http://drupal.org/node/1332348#comment-5218804.

It's incompatible with Views 6.x-2.14 and above, and not necessary now anyway.

May I ask you guys if it safe to install views version 7.x-3.0-rc3 ? I did and I can not see my views at all under structure. It seems missing. I tried clearing cache and reinstalling, nothing.

@goldcrusaider
Please don't hijack issues. I would recommend to install views_ui and clear cache as well.