Closed (fixed)
Project:
Display Suite
Version:
7.x-1.x-dev
Component:
Panel view modes
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
17 Jun 2011 at 06:22 UTC
Updated:
4 Jan 2014 at 00:53 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
Shadlington commentedI'd love this.
Would be particularly useful with modules such as workbench moderation, which is all about enabling revision-centric workflow.
Comment #2
swentel commentedThe dev version has working panel view modes. Of course this is alpha code, now it's time to extend and refactor and add new features.
I've been wondering whether revisioning overrides isn't something for page manager itself. Of course, now it should be possible too. Just wondering which approach is best:
- separate view mode
- variant on the full/default panel view mode
Discuss!
Comment #3
Shadlington commentedYou're right that it probably should be handled by page manager... I just dug through the issue queue a little and found this: #515518: Optional node revision task handler to override default behavior
That suggests that it should really be in there - but it got closed because the revisioning maintainer added it to that module instead of ctools.
EDIT: Oh, I forgot about the question you were raising.
I wonder if it'd be easier to simply be able to set revisions to display with the default/full view mode. That's the most likely use case.
Comment #4
BenK commentedNice discussion!
I don't think this feature necessarily needs to be in Page Manager itself. Display Suite is doing such a nice job now with overriding by view mode that I think it's natural to have an additional view mode for the display of revisions. I personally find it very logical to think, "now that I have a full display and teaser display for this node, how would I like it displayed as a revision?"
I also don't know how likely we are to get it added to Page Manager itself because the Page Manager development cycle seems much slower than Display Suite (which is an awesome thing about swentel's work on DS).
The one question I have is about cloning a panel between view modes. Is it possible to do this in the current DS implementation? Because it would be nice to be able to clone the "default/full" panel for use a starting point for the revision view mode panel.
Thoughts?
--Ben
P.S. @Shadlington: Actually, that thread you pointed isn't quite accurate. I spoke with the Revisioning module maintainer and that feature was only discussed... it never actually got added to the module.
Comment #5
Shadlington commentedMost of the time (I would say easily 80%+) you're going to want the revisions to display exactly as they do in the default/full view mode (panels-based or otherwise).
It would be cumbersome to have to recreate a view mode in order to achieve this.
That would be solved with Ben's suggestion of allowing cloning.
However, it occurs to me that simple solution (from the site builder's perspective, that is) that doesn't restrict flexibility would be an extension of the point I edited in to #3. If you could select a view mode for revisions to use, then it'd immediately solve the most common use case without any extra work but you'd still be free to use an alternative view mode (you might choose to build a custom revision one, for example).
@BenK Huh, I thought it had been implemented in the D6 version but not fully ported to D7.
One way or another I knew it wasn't available to us in D7 and certainly hadn't been done in ctools :)
Comment #6
BenK commentedswentel,
I'm interested to hear your further thoughts on all of this... what do you think is the best way forward?
--Ben
Comment #7
swentel commentedHaven't had further thoughts about this right now. Frega is hacking into the admin interface right now to add contexts and selection rules, so I'm waiting what he comes up with first. We're sitting together next week at the designcamp and hopefully we can have a small sprint with some first good results.
Comment #8
Shadlington commentedComment #9
swentel commentedSmall follow up - cloning is supported so it's really easy to create new view modes. Now, the only way to find out if we're looking at a revision is apparently by looking at the path. There is no indication on the node object itself (unless I'm missing something). So it seems like the overriding would need to happen hardcoded. Using the contexts or selection rules is still far off (and rather heavy and difficult and adding some overhead as well).
There's another problem. The revisions callback calls node_show() which will render the node with the 'full' view mode, so no way to override that. Unless we take over the page callback and render this ourselves. This sounds like an 'extras' feature to me which I'm perfectly fine with. I'll start experimenting with this and post a patch so you guys can play with it.
Comment #10
swentel commentedHere's a patch to review. What it does:
- adds an extra option 'Revision view mode' on the Extras screen (in the other fieldset)
- adds an extra revision view mode which you can then style
- takes over the menu callback of a node revision view. It checks if revision view mode is configured and uses it than, otherwhise use full (which in that case would fallback to default).
This works both with field ui and panels layout editor.
Needs tests, but you can test the functionality on itself.
Comment #11
swentel commentedUpdated patch which has tests as well.
Comment #12
BenK commentedI've been testing the patch in #11 and it has been working very well. :-) Nice work, swentel!
The only problem I've been experiencing is that when I include a view in the Panel that takes the nid as an argument, it seems like the nid is not being passed (so the view appears empty).
I'm not sure if this is an issue with the override of node revisions specifically or more generally with Display suite's Panels implementation. Should using the nid as a views argument work with Display suite?
Also, I suppose it could be a views configuration issue: I'm not sure if the views argument needs to be configured differently for use with Display suite. I do know, however, that the nid argument in the view works fine when the view is added directly to a Panel's "Node template" (which allows different Panels per content type, but without using Display suite).
Thoughts?
--Ben
Comment #13
swentel commentedHrm I'll look into it, I thought the node was already passed in as a context, but could have been lost during refactoring.
Comment #14
swentel commentedHey,
Works fine here - I'm using the views content panes modules which comes with CTools module, the view is configured using 'content: nid' as the argument, so not really an idea what might go wrong at your installation.
Comment #15
BenK commentedHey swentel,
Thanks for checking things on your end. After seeing your reply, I did some more testing and found the cause of the argument problem...
Basically, when configuring the settings of the view within the panel, I needed to select "Content ID" as the context for the "Content: Nid" dropdown menu. (I previously had "No context" selected.) Once I changed this, everything now works properly with arguments. I also tested this with mini-panels and arguments work with mini-panels, too.
Also, I did some additional testing of the patch in #11 (I used a sandbox version of an actual production website that has pretty complex panels) and everything worked perfectly when overriding node revisions. So I'm marking this as RTBC. I'd love to see it committed soon.
Thanks for your great work on this... I'm really excited about it! :-)
--Ben
Comment #16
swentel commentedCool, I'll commit this asap, changing the status to make sure I commit this tonight :)
Comment #17
swentel commentedCommitted and pushed, thanks for testing and feedback!