Using content_build_modes hook one can have as many contexts/build modes as one desires; however one cannot configure different label text per each build mode, which I see as undesirable.
Is it a limitation or just not desirable? Perhaps if certain build modes, like search index, do not want labels then there can be a reliance on "has labels" like there is for "has views"?
While I haven't been using 3.x looking at the CSS repo it appears to same as 2.x as far as basing labels off of context "basic". Sorry if this is a duplicate, and if it is I'd be damn disappointed in my searching skills.
Good day
Comments
Comment #1
markus_petrux commentedThis is not a CCK3 issue per-se. So it should be first addressed for CCK2, then ported to CCK3.
I think this is somehow related to other issues that talk about the fact that there's no UI for formatter settings. If we add a text field for the labels in "Display fields" screen, then that table could end up unmanageable.
Also, I think it's too late for such a change for CCK for D6. Something like this would have to be addresses first for D7.
Comment #2
hefox commentedSorry for being unclear, but I meant to refear to the label display not the label text; I believe there is another issue specifically for configurable display text (which would make this a duplicate if it was, but it isn't).
In "context" basic, the label field can be set to inline (normal?), above, and hidden; however in other build moods (declared via hook_content_build_modes) those label settings cannot be configured because there is hard coded checking for context basic.
I do not think these changes would require a ui other than what is already existing. Other than removing the hard coded context basic checking in the form and tpl for the display fields form, I'm not sure if there are many other changes that would be needed; I suspect a change would be needed in what tells build modes what the label display is (if labels are provided for other build modes).
Does this change whether it would need to be implemented in 7 first?
Comment #3
yched commentedD7 already has this.
Not a trivial change in D6, though, since it's not only a UI change, but would also require updating existing field structures.
Also not simple with exported field definitions included in a couple contrib or custom module installs.
I'd tend to mark as "won't fix", but I'll leave markus decide.
Comment #4
hefox commentedI see what you mean; looked at it closer and played around a bit after the last post
Per build mode/context (flat) could be done without needing to alter previous field definitions by retaining the normal basic label setting and adding one new one label per build mode with the extra label display of 'inherent from basic' (to keep old exports and functionality).
While it have been easier to do in CCK, I just did it in contrib with some horrid, ghastly use of theme_register_alter (sigh!), form_alter, node_api, and hook_fieldgroup_view. Now if I only had a use case for it atm; I just wanted it because it felt missing u.u
Thanks for the time, mark away as won't fix I guess :>