My theme (7.x-3.x) includes Panel layout plugins, and they work fine, thank-you DS you rock, however on the Layouts tab the $suggestions
returned by _ds_field_ui_table_layouts()
append "panels-" to the suggestion names, this I traced back to _ds_ds_layout_info()
i.e.
$layouts['panels-' . $key] = array(...
My layouts are not called "panels-foobar_layout", they are simple called "foobar_layout". I don't even know if I can call them panels-foobar_layout without causing something to blow up :/
I don't know if this can even be fixed, its looks like the "panels-" prefix runs pretty deep in DS, although the code is escaping me at this late hour.
Can this be fixed, is it even possible? Mainly because for users of my theme this is a wtf, although I can document this and even push templates with the theme.
A nice workaround for me would be to push one template for all node suggestions, a sort of "panels-ds-node.tpl.php" thing, any info on where I can hook into the suggestions to do an array_unshift and push a suggestion to the front of the queue would be helpful also.
Comment | File | Size | Author |
---|---|---|---|
#5 | 1514216-4.patch | 1.13 KB | swentel |
#4 | 1514216-4.patch | 421 bytes | swentel |
#4 | Screen Shot 2012-04-07 at 22.12.52.png | 54.52 KB | swentel |
#3 | 1514216-3.patch | 1.2 KB | swentel |
Comments
Comment #1
Jeff Burnz CreditAttribution: Jeff Burnz commentedOK, for now I am kinda hacking my way around this by looking in the suggestions array in hook_process_node() and listening for a match, if so something like this:
So I have some empty variables for printing markup in the actual plugin template, could come in handy actually, I can initialize them via the plugins own preprocess function when not being used by DS (the coming in handy bit, maybe useful for panelizer or other etc).
I think this will do for now, unless we can fix that issue, at least I can ship the theme with my panels layouts auto-magically wrapping the planels plugin template in the right markup when being used by DS, which BTW is HTML5 and is required to keep the semantic structure of the page intelligible to machines and why I am being a bit anal about this ;)
I hope my ramblings are making some sense.
Comment #2
Jeff Burnz CreditAttribution: Jeff Burnz commentedIn the end, to save users of Adaptivetheme a wtf moment when their template suggestions fail to take I have implimented my ideas in #1 so now any node that uses a Panel layout through Display Suite (a Panels plugin layout supplied by Adaptivetheme core) will automagically get wrapped in article elements with the node id, classes and attributes.
I really do think this is a bug after all, although I can concede its one we may have to live with and simply provide such workarounds and document it.
My workaround is a wee bit of a hack but it works, and I can't see another way of detecting if we're looking at a display suite rendered node.
In my code below
responsive_panels_plugin_names()
returns a list of Panels layout names supplied by Adaptivetheme or any of its sub-themes, if themers want to do something like this in their theme they could hard code such a list like in #1, this code runs in hook_process_node(). It requires additional variables to print inside the panel plugin template, namely$panel_prefix
and$panel_suffix
, and these must be initialized or checked etc.Comment #3
swentel CreditAttribution: swentel commentedhmm, looking at the code, I shouldn't actually show those template suggestions as I don't even add those during rendering. The 'magic' happens in ds_extras_render_panel_layout() in ds_extras. ds_entity_variables() at the top stops when it detects a panel layout.
So, in that case, just removing the suggestion is probably going to save a lot of headaches no ? Patch attached removes the suggestions for panel layouts. Let me know what you think. If there's anything I can do in ds_extras_render_panel_layout() to make your life easier, let me know!
Comment #4
swentel CreditAttribution: swentel commentedOk, so in fact, the template suggestions in ds_entity_variables are right I think, it was the preview showing them completely wrong.
This patch should fix it. As a bonus, in the second branch, the preview icon is also showed :)
Also added $vars['rendered_by_ds'] = TRUE;
Could you give this a quick run ?
Comment #5
swentel CreditAttribution: swentel commentedOk, better patch.
Comment #6
Jeff Burnz CreditAttribution: Jeff Burnz commentedYup, that's the shit swentel, working perfectly here, and yes the icons are a nice touch!
$vars['rendered_by_ds']
does me a lot of favors and will be very useful I am sure.The whole new version/improvements you guys have done over the past days are fantastic, I mean it was good before, now awesome-er.
Comment #7
swentel CreditAttribution: swentel commentedok great, committed to both branches!