Hi all,

Any help would be greatly appreciated, though I fear at this point there's nothing we can do to recover the original settings.

We're running Drupal 6.22 and just updated the Views module to 6.x-2.14. After updating, all of the enabled blocks that Views had created were set to disabled and all of the settings (page titles, display settings, etc.) were all lost. Given that pretty much our entire company website is constructed using those blocks, it's been a bit of a disaster.

Is there any way to recover those settings? Is this something people have seen before with this upgrade? I couldn't find any mention of such an issue in the forums, except for one issue that took place with someone upgrading to Drupal 6.22, but we did that upgrade already without incident.

Any help would be wildly appreciated!

Comments

memcinto’s picture

We had the same issue, although not all of our Views blocks wound up disabled, only some. The site I updated had several themes installed and it took me a good hours to put things back this morning. Good thing I had a testing platform with a recently updated database so I could see how things were supposed to look. Perhaps this should be changed to a bug report?

memcinto’s picture

Also, visibility settings not being obeyed. This may be a variant of this issue:
http://drupal.org/node/1330834

merlinofchaos’s picture

Status: Active » Closed (won't fix)

It appears that if you disable a module, then run update.php, block_rehash() removes any blocks not owned by active modules.

That means Views isn't responsible for this -- core is doing this because you disabled the module. Nothing we can do about that.

dawehner’s picture

Status: Closed (won't fix) » Active

One thing i realized is that many people in the other issue explained detailed how they updated. Thanks for this, it really helped to understand it a bit better.

So what is the problem with disable and then run update.php. As you see in the function _block_rehash() of core, all blocks, which aren't defined by active modules at the moment are removed from {block}. This means that if you disable views and run update.php afterwards you get all blocks removed, which where defined by views. This seems to be a possible problem here.
Maybe people read upgrade.txt, but understand it as update.txt, see #1334774: D6 UPGRADE.txt file is confusing many users for a new created core issue.

Can anyone on this issue tell, whether they updated this way?

beasley’s picture

I had the blocks disappearing issue (see http://drupal.org/node/1330834 mentioned above). I rolled back the server to a few hours before the upgrade and tried to replicate the error. I:

  1. Left the Views modules switched on as before, together with my custom theme (based on Basic)
  2. Deleted the old Views directory, installed the new one
  3. Got an error from the Views clone display module, so I uninstalled it (see http://drupal.org/node/1330704)
  4. Ran update.php

And nothing was wrong! I didn't even get the 'You have an error in your SQL syntax...' messages I got last time. The blocks were still there and everything was fine. Clearly I must have missed something out that caused the error last time. All I can think of is I'd just updated the Pathauto and Token modules before upgrading Views. I did that this time but the version of Token was different (there was a new release a couple of days ago).

I've got the results of the SELECT * FROM blocks WHERE module = 'views'; query but haven't bothered post it because nothing went wrong. I'm a bit confused, and wonder how much of an issue this is. At least in my case, it seems to result from a very particular set of circumstances or sequence of actions.

If the problem is worth pursuing I can have another go at messing up!

johnpitcairn’s picture

I'm having this problem right now for one site in a multisite setup, but it definitely isn't a Views issue - I'm losing block assignments after a simple dump from live and restore to local. This is before updating Views.

dawehner’s picture

Status: Active » Fixed

Let's mark this as fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.