Closed (fixed)
Project:
Contextual View Modes
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
3 Dec 2012 at 22:53 UTC
Updated:
7 Feb 2013 at 06:40 UTC
This a great module with one minor feature missing (at least for me!). :o)
I have a site with lots of nodes for particular content types and I would prefer not to set up a contextual view mode for each node. Would it be possible to set a default set of view modes for a content type that would be inherited by each node if they don't have their own setting?
Thanks
Comments
Comment #1
sherakama commentedYour request makes complete sense.
Shouldn't be too difficult to do. I will see if I can find some time over the holidays to add this functionality.
Thanks for the idea.
Comment #2
PedroKTFC commentedThanks for the encouragement! :o)
I've had a go at putting something together (my first attempt at php of any significance!). I used your module and view_mode_modal as guides and came up with my attempt below. It works for me but it obviously needs a proper review and testing. It's also untidy so far. For example, if you delete a context or view mode, I don't clean up what's stored for the content type. It doesn't seem to cause problems (Drupal seems to handle the case with reasonable defaults) but ideally it would be better tidied up.
Anyway, comments welcome!
Comment #3
sherakama commentedHmm. Interesting approach.
I'm not so sure adding it to the field ui was the right choice.
You have also given me some inspiration to actually make this properly instead of a bunch of variables loaded into a node. I think I will go about creating a proper settings page where users can enable which content types they would like to have available to use the CVM as well as turn the select fields into a real field instead of a hackey bunch of form settings.
On that configuration page we can also have the default settings for the enabled content types.
7.x-1.2 will be the release for these.
Thanks!
Comment #4
PedroKTFC commentedAs I said, I used view_mode_modal as a guide as well as your original. I'll be happy with whatever you decide. Just need to be sure that there's a hierarchy of settings so that if you set it up for, say, an individual article, it "trumps" the setting for articles in general.
I'm using my approach at the moment but I'll move over to yours when you release it.
Fun, fun, fun!
Comment #5
kingswoodute commentedSubscribe - would love to use this feature or to be able to bulk apply the setting to all existing nodes of a content type.
Thanks very much for the work you're doing!
Comment #6
sherakama commentedThis is now available in the 7.x-1.2 release.
Enjoy!
Comment #7
sherakama commentedComment #8
dman commentedThankyou. I was looking for this and couldn't find it at first.
It turns up on the global config screen admin/structure/cvm *after* we've selected the content type to work with.
Conceptually, I was really expecting this to turn up to be managed through context UI.
- if this context is set
- then use this layout
But I can see how this works too.
I got into the code, and found it's still really assuming that we'll be using the per-node settings. As my only use case is global, that might be overhead that could be optional.
Comment #9
sherakama commentedYou raise good points. I don't really like the way that the admin form works anyhow. It was a bit of a rush implementation to begin with. I think a context managed plugin would be a good idea. I will create a new ticket for that.
Comment #10
dman commentedI had to patch it three times to get it working as needed for me. (including an alternate parsing fix for #1887908: Error when trying to set global settings)
I've not got a clean patch, mostly because the way settings form currently works with the concatenated tokens - is pretty awful.
I'd prefer we refactored it and used a $form['#tree']=TRUE then the global settings array would be more consistent. It would also mean we don't have to unpack it when saving.
I've got some dirty patches that I'll try to clean up a little maybe.
My current work is a quick&dirty proof-of-concept - using this for some A/B user testing on a site - "Which of the display layouts works best". This is handy to set a global switch to change the displays, but client doesn't want to invest in really fixing it beyond "works enough".
But I've got the issues in my hot-patched code...
BUT, this does do a good job at what I think is a really handy idea, so I'm interested in following up a little.