Nodequeue by default creates a view for every nodequeue that exists. In my experience, though, that view only causes me headaches. I cannot use it directly, because the name is nodequeue_X, and if I try to export that view to code in my own module with that name then Views breaks. So I have to clone it, rename it, and disable the original view. So I now have twice as many views as I actually need, including a dozen that are disabled just taking up screen space.
Of course, that cloned view has a whole bunch of stuff in it by default I have to rip out, like the name and the mundane listing page, because I have never once had any use for it. So I'm better off just building the view from scratch and ignoring the nodequeue-based ones. Which means I still have a dozen views sitting around doing nothing but taking up space and distracting me.
And of course none of these problems are intuitively obvious, so every time I work with someone new I have to re-explain to them why to avoid the nodequeue-provided views like the plague, usually after they've already modified them so we have to take the time to clone, rename, and clean them up.
So can we just eliminate the problem by eliminating the never-useful-in-my-experience default views? Please?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | nodequeue-disable-automatic-view.patch | 753 bytes | dawehner |
Comments
Comment #1
ezra-g commentedI see what you're saying. I once proposed replacing these with a single view that accepts arguments.
I'd rather make the generation of default Views a configurable option since it saves casual users a lot of time. I'd be happy to review a patch that makes this a simple checkbox under the main nodequeue settings.
Also, I'm not sure what you mean by :
"I cannot use it directly, because the name is nodequeue_X, and if I try to export that view to code in my own module with that name then Views breaks."
How and why does it break?
Thanks!
Comment #2
merlinofchaos commentedProbably because having multiple views with the same name in exports is bad. But at that point you should be cloning the view. =)
I think the automatic view generation is necessary to have available, but I have no issue with turning it off.
Comment #3
Crell commentedTurning it off would be good enough for me, especially if it's off by default. Or a single argument-based view would be easier to disable once and then ignore. That may even be the best approach, because then I can just disable it once on the site and be done with it. :-)
And yes, it breaks because when you have two views in code with the same name, mysterious bad things happen. But if you start with that view there and ready for you, then it's soooo tempting to just tweak that, and you don't realize until much later just how much trouble you cause yourself that way.
Comment #4
dawehnerwhat about a variable called
'nodequeue_automatic_views_generation' and this is placed in hook_views_default_views.
this should be all, so the developer can disable if needed
Comment #5
Tri commentedHello everybody.
For everyone trying to store his overridden default views in code while avoiding the clone-disable trick above, there is a views hook that can help.
It's hook_views_default_views_alter(&$views) and although undocumented it's use is similar to this hook_views_default_views().
An implementation could go like this
Where
xxx is your views code holding module and
export_tab_dump.php is the output for the views export tab for a view.
I have tested it with nodequeue as well as with other default views and works nicely.
Comment #6
sheldon rampton commentedActually, that code isn't quite correct (although it probably works). hook_views_default_views_alter works by altering the views array that it receives as an argument. It therefore doesn't need a return value.
Personally, I like to keep each view in a separate file in a subdirectory, rather than exporting a whole bunch of them into a single big file. I also like to keep views that I've created via the web interface in a separate subdirectory from other modules' default views that I'm overriding. I therefore create two separate subdirectories in my views code holding module, named "includes" and "alter_includes" respectively. I pull them into my site using the following implementations of hook_views_default_views() and hook_views_default_views(&$views), respectively:
Comment #7
dawehnerHere is a initial patch
Comment #8
ezra-g commentedThe proposed patch gave a fatal error: Can't use function return value in write context, but I committed a slightly different version. Just set nodequeue_automatic_views_generation to '' and you're good to go! When this variable isn't defined, the views are created. If end users want a UI for this setting, we can always provide one later.
Comment #9
Crell commentedezra, just to check, you're only checking against whether or not the variable exists? That's wrong. :-) If you're going to use an undocumented variable for it, you should be checking it's boolean value, not its presence. Setting that variable to TRUE or 1 should enable it.
Comment #10
mrfelton commentedPlease don't use an undocumented variable for this. If you'r going to add the feature, at least add a checkbox for it in the settings page.
Comment #11
mlncn commentedThere should also be a way to delete views that are created?
Comment #12
ezra-g commentedOk, this is now a configurable option. To remove old views you can clear your Views cache if you haven't overridden the default views, or, feel free to submit an issue for any new features related to this change.
Comment #13
ccoppen commentedSo, if this has been dropped, how do you get a view of your nodequeue to display. I don't see it as a configurable option anywhere.
I would like to use this, if possible, esp. the views part of it.
Comment #14
dddave commentedFollow-up: #743280: View not generated upon creating a Nodequeue
Comment #16
joachim commentedAny chance of a release with this in it? A fix isn't really much good until it's actually released.