Skinr / CCK field and fieldgroup level integration

Possibly in the future, but for the now the answer is no, unless someone wants to submit a patch.

Going to mark this as postponed for now.

Updating the title to be more accurate since Skinr does already support CCK content types, just not fields...

And updating one more time to include a related/semi duplicate issue for supporting CCK Fieldgroups as well:

#617650: Skinr on CCK group...

This is relevant to my interest.

Changing the priority and postponing. I think it would be good to do if it's easy, but it's not as important as the other outstanding issues and we need to release shortly. If anyone is willing to create a patch, we would be more than happy to consider it.

Changing this to active.... If time permits and this isn't too hard it would be nice to get this in.

Subscribing...

subcribing

Committed to CVS.

Theme that support skinr should add a content-field.tpl.php and fieldgroup-simple.tpl.php that include <?php print $skinr; ?>.

Port to D7.

Given that this is now fixed/committed for D6 and is now about the port to D7, can the version on this be changed to D7?

(I'm going through the queue here reading up on the issues, and I figured I'd ask).

Yes, definitely feel free to pitch in and help with changing the status/version anytime applicable (or anything else you are interested in or can help with.) I'll change it now since I'm here.

Also note, for some reason there two 7.x-1.x-dev releases listed in the version dropdown for some reason. I'm not sure why.

Thanks!

We are not porting the 1.x version to 7.

BTW, CVS is a little screwed up.

Drupal 7 code is up to date in HEAD and the tarball and issues map to 7.x-2.x-dev.

I have no idea now to being porting this because no patch was posted initially. I also worry that there will be performance implications for doing this. Anyway, since there is no patch here, marking this needs work.

The changeset is http://drupal.org/cvs?commit=377708

Fieldgroup module doesn't yet exist in D7. See #824812: Future of fieldgroup - call for volunteers.
And most of CCK is merged into core; and the fields no longer seem to have individual hooks, which makes it so they can't work with skinr very easily anymore.

Also, content module is now field_ui module.

I tried writing a patch but ran into issues because of the lack of a hook. We might have to merge this into skinr's node plugin.

I really do not think we should go as far as field/fieldgroup level in Skinr period. We already have enough performance challenges, and fields are not smart to mess with, unless there is a really good reason, and I do not see one. There's no reason at all that you cannot style fields or field groups by using a Skinr class at the node or even page level.

Marking "wont fix" unless someone can make a really good argument as to why this should exist in the first place.

Here's an attempt at an argument.

This would allow fields to act and look like separate entities... in my use case -- and I think this is enormous -- I want custom sidebar blocks/boxes on each page with content from CCK fields. So, for example, I could allow the client to upload a few podcasts, or have a downloadable pdf, as a "box" on the side of the page (without having to go to the horrible block form and create a box/block in which to put the items).

I wouldn't want to do this on the theme level, only on a page by page level. So this would allow the client to add something that looks like an extra info box to the page on the fly.

I appreciate that one could add this to the node level, but that's a little counter-intuitive for most of my clients.... besides the fact that I usually turn off skinr on the node level, using it only for blocks/boxes and views. I use it so that my clients can add a little color/styling to each sidebar boxes/blocks -- not the main page.

I know some of this could be achieved with panels, but the interface is way too complex for my clients -- even with the in-place editor (which I could not get working with skinr2).

I am using Composite Layout so that each "page" content type can be laid-out & customized to some degree by the client. The ability to treat fields like "blocks" to be styled and moved around as such, is enormous!