I am not sure whether this is the right place to present/contribute a module to the ND-ecosystem, but i'll go ahead, anyway :)

We were looking for an easy way/interface to switch between different build modes (or override the default) for the individual node full page view; this may seem unneccesary but consider this: one story-node should have a large image on the right, but all other story-nodes should use the default full mode (with e.g. image on the left etc.) In Drupal there are, of course, many ways to archieve that: e.g. a tiny custom module or using views to display a single node (via a nid-argument) in a different build mode ... but we found that overriding a node's full buildmode provided a minimalistic and convenient buildmode/"template" switching interface both for (non-technical) sitebuilders and end-users ...

The tiny module attached (nd_override) provides the following:
1.) On the content-type admin-page (admin/content/node-type/%): configure which other buildmodes will be exposed as override-options for the default full buildmode (per node).
2.) If any build modes have been exposed under 1.), a fieldset on the node edit form (node/%node/edit) allows to select the overriding buildmode. If an override is selected, hook_nodeapi "switches" the buildmode used for a "full" node view accordingly.

Maybe this approach is totally whack, but if you find this to be a meaningful addition/approach, i'd be happy to put it up as a module somewhere ... a tar-ball of the module is attached.

best,
fredrik

notes:
1) couldn't find any definite info potential side-effects of switching buildmodes "in-flight"; there could be really bad ones - we haven't tested or deployed this extensively yet ... we set the module weight to -99 to be "the first to alter"; some might consider this a little too hacky ...
2) this module uses variable_get/variable_set for storing overrides; this obviously doesn't scale, but the change in logic for "large-scale" overriding would be minimal (s. module.install) ...
3) not really happy with the name of the module (but nd_fullbuildmode_override isnt really great either :) maybe something that makes more sense from a non-coder perspective ...

CommentFileSizeAuthor
#3 nd_switch_bm.tar_.gz2.01 KBfrega
nd_override.tar_.gz2.19 KBfrega

Comments

swentel’s picture

swentel commented
Priority: Minor » Normal

It's a really valid use case - I've also been experimenting with code being able to override an individual object (in the complete display suite ecosphere of modules) but got stuck with CCK being very annoying. I was creating a new tab on the edit of say a node or user and you were able to override all build modes for that object individually with the drag and drop screen so you wouldn't need have to create a dozen of build modes, in short, total freedom, but it's not easy - probably impossible.

However, this is a very nice alternative and the code isn't that hacky/wacky at all in fact - and CCK listens, that's pretty important!

A few notes/thoughts:

- ds_get_build_modes() : you can pass 'nd' as the first argument, will return all build modes from nd.
- info file: use 'Display suite' as the package, nicer to find it there.
- maybe nd_switch_bm() as module name ? This opens up future patches (either an extra tab or more in the fieldset to override it for other build modes too)
- instead of a separate table or using the variable table, you could use an extra field on the node_revision table. This way, even revisions of the override value will be stored. All doable with hook_schema_alter() - would make the module even more way cooler - and ready if we'd want to extend it to other build modes too. And we don't need extra queries, because node_load() will fetch that field from the table - win win if you ask me (to be honest, that's what I've done like I described above to minimize overhead)

I'd be happy to commit this to nd_contrib unless you want to host the code yourself of course - I'll do some minor coder checks and if you have updates, simply post some patches and I'll commit them. It's your call, let me know, but I like this already!

frega’s picture

frega commented

Cool, would be happy to contribute and it'd sure be nice if you'd accept / host it as part of nd_contrib.

I like the nd_switch_bm name and will change it accordingly. Definitely altering the node_revisions-table by means of hook_schema_alter sounds like the correct place for that kind of thing - hadn't thought of that :)

Willl post an updated version in the course of today or tomorrow.

Thanks & best,
Fredrik

frega’s picture

frega commented
StatusFileSize
new nd_switch_bm.tar_.gz2.01 KB

Refactored the module (renamed to nd_switch_bm, storage in node_revisions, minor cleanups). The helptexts and field titles are still pretty raw, i.e. maybe not really "intuitive" for non-techies ...

Would you be interested in another module (working title: nd_context_bm), that exposes nd build modes as context-3.x-conditions and reactions? e.g. if a node is being viewed in a full page node view with build mode "XYZ", trigger some reactions "ABC" (like add a block somewhere); and vice versa: if some context condition is met, switch the build-mode to "XYZ" instead of full build mode. Again I would start / restrict myself to full build mode node page views (i find overriding node build modes in e.g. views kind of freaky :)

best, fredrik

swentel’s picture

swentel commented

Woohoow, that context module sounds awesome, was thinking about that too, but I'm to busy with a D7 port now - fire away, looking forward to it !

I'll test the switch tonight and - with your permission and credits of course - commit it to nd_contrib. I'll try to come up with some more friendly help texts if possible :)

swentel’s picture

swentel commented

Ok, did a review, tested it and did a quick 'Coder' check. Looks good for me, let me know if I can commit this to ND Contrib!

frega’s picture

frega commented

yes, please do go ahead and commit the module. i'll upload the nd_context_bm.module in another issue shortly.

swentel’s picture

swentel commented
Status: Active » Fixed

Alright, committed, thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.