Closed (fixed)
Project:
Views Bulk Operations (VBO)
Version:
7.x-3.0-alpha3
Component:
Core
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
21 Jun 2011 at 21:02 UTC
Updated:
7 Jul 2011 at 14:41 UTC
After updating to the newest VBO (alpha 3), the "Emulates the Drupal content administration page" VBO view at /admin/content2 stopped working, saying the style plugin was invalid. I assume this was because of the move to Views form elements (although I don't fully understand that yet, so maybe I'm wrong).
Even after disabling that view, though, it still shows up in my list of views (disabled) -- ready to be enabled and nonfunctional once more. If this view really is getting killed off, shouldn't it be removed from the list of enable-able views?
If, on the other hand, it's not the intention to kill of this view, it seems like there needs to be some kind of upgrade path that updates the VBO content administration view.
So perhaps this is more of a task or feature request than a bug -- but having a view that was working stop working with an update feels like a bug to me.
Setup:
- Drupal 7.2 with the patched update.php
- Views 3.0rc1
- VBO 3.0a3
- Chaos Tools 1.0b1
Let me know if I'm missing some key info and am wildly off-base here...
Comments
Comment #1
bojanz commentedNo, the intention is to have a fully functional default content administration view :)
It works for me, so I'm guessing you made changes to the old view (before the whole move to VBO-as-a-field happened). Can you try reverting it ("revert" link in the same dropdown where enable is, in the Views UI)?
Since this is a default view provided by a module there can't be any talk of updating modifications done (it's just not how Views works when it comes to default Views).
I'm not planning on having any upgrade path for non-default views, since the D7 branch didn't even have an alpha release out before the break happened, and fixing a view requires 2min of manual clicking. Of course, if someone else wants to write an upgrade path, I won't mind including it in VBO.
Comment #2
rootworkYes -- you're right, I had made changes, and that's key. And obviously I think it's reasonable to not necessarily support any and all customized views.
So the bug, then, is that even after I reverted it, disabled it, and enabled it, it still used the old invalid style formatters, and didn't work. I had to remove the style formatter, and then add the VBO field, even after revert-enable.
I'm not sure what the best solution here is. You could automatically revert people's customized views, and mention this with some sort of big warning. You could somehow insert helptext into no-longer-functioning customized views, explaining what the person has to do or linking to a doc page. Or you could list in the release notes that there is no upgrade path for customized views, which I'm sure is the easiest option.
I'm not sure if this should be split into a bug and a feature request -- I'll do that if you want.
Comment #3
bojanz commentedRevert means "go back to the version in code", if it didn't work and you had to make changes yourself, then that sounds like a Views bug. I'll see if I can reproduce it in order to file a Views issue.
I will add a note to the README file. The release notes for the first two alphas said something similar, but it needs to be in the README.
Comment #4
rootworkThanks. But just to clarify, could it be a bug in which it goes back to the original (pre-views form fields) version, rather than the new, VBO-fields version?
Comment #5
bojanz commentedWell it can't go back to the pre-views-form version because that VBO code was replaced by the new VBO code (when you updated the module), which only holds the new views.
The default views are fetched from the code, if you update the code, the views update as well...
Comment #6
bojanz commentedAdded a note to the README.