Plans for determining which fields get editor
The biggest hindrance at the moment to adoption of WYSIWYG is that i don't think there is any current viable solution for controlling which fields get which editor instance assigned to them. I recall this being such a huge PITA back in 4.7 days and when D5 came along and FCK editor had a decent option for this it was all i needed to drop Tiny as my editor of choice and go with FCK.
But now we are at D6 and, if getting on the wysiwyg bandwagon, are taking a step backward to 4.7 days. I don't see much discussion about this on the forum; so thought it needed to be brought up.
not sure i'll have all the terms right; but i'll take a shot:
Tiny has concept of a theme and a profile (from what i can tell themes have finer grained control of editor features than profiles do; profiles simply control which buttons; but themes control other non-button features). Not sure if other editors have this distinction as well.
so things we need:
- theme and profile management on a field/field (and role) basis
- control on which editor instance is assigned to cck fields, node fields (title/body), other form fields
Current ideas that i have seen:
-
Better Formats - only provides cck profile management
-
FCK module (not WYSIWYG based) - provides profile (not theme) control on any fields (good option; but we lose this if we go with wysiwyg and fck editor)
-
back in D5 days i designed a TinyFields module that used UI simiilar to FCK module and therefor gave control over any field but also allowed for creating/assigning Tiny themes
Ideally what we need (imho) is a version of TinyFields which works within wysiwyg; but i am holding off on starting down this road until i hear more about current plans/direction by the group.
What do you see missing?
This is the state as I see it:
Wysiwyg module allows you to create as many editor profiles as you want, even multiple profiles of the same editor.
Better Formats allows you to choose which editor gets use where by controlling the format the editor is attached to.
Areas to improve upon:
More granular ability to control formats. Work on this is going on:
http://drupal.org/node/350696
http://drupal.org/node/366015
More control of the editor specific features through Wysiwyg API. Work on that is going on in the 3.x version of Wysiwyg API.
That is the state in D6. D7 offers some new features to help us achieve the same result better and hopefully more.
thanks
yup, but better formats doesn't do fields (in general) just cck.
i knew of first post you listed; and made this same point there.
2nd post seems more to the point... hadn't seen that thread, thanks.
just seems scary that in D6 we are taking such a big step backwards from D5 (and yes, many steps forward as well)
our project is pretty big (and by that i mean massive, funded by the NY Times and over 160 modules) so we need to make final decision (which i think we have made) as to whether or not we are on the wysiwyg bandwagon (pretty sure we are as i have converted a few of our old D5, Tiny modules to now work with wysiwyg); and, if that's the case.. then we'll throw devel resources at getting this sorted out... which in the end means i'll likely be working on solution for this over next few weeks - hopefully work by Gabor and others will be a good starting point.
thanks again,
Peter Lindstrom
LiquidCMS - Content Management Solution Experts
Just CCK?
What do you mean by:
Better Formats controls core body field, CCK formated fields, comments, and blocks. As shown in the above issues work is going on to expand that further into fields that Drupal does not provide formats for in core.
D7
btw, before you go ahead and put countless of hours into this, I'd recommend to have a in-depth look into the entirely revamped filter system in D7 (which probably covers 90% of better_formats), but also into the new text format enabled text field handling.
D7?
what's Drupal 7? sorry.. don't mean to joke.. but massive undertaking for us to convert to Dr6.. like i said.. 1-2yrs before anyone even mentions D7..
but maybe you meant look at existing work there to consider backporting? maybe that's possible.
Peter Lindstrom
LiquidCMS - Content Management Solution Experts
Yeah, I have been keeping up
Yeah, I have been keeping up with it and will adjust as need. I've noted these changes on the BF project page since day one. Also as noted on that page BF is a solution for D6, so in that respect I am willing to put work into it as long as D6 is a solution to my work.
still maybe silly
i guess, technically, you might not have been suggesting backport (which i'd bet is difficult to say the least), other (scary) options include:
i think our solution will end up being redoing my "tiny fields" module and hope i can fit it into wysiwyg (i think it will fit)
Peter Lindstrom
LiquidCMS - Content Management Solution Experts
...
I was replying to
Drupal 7
For Drupal 7, this is mostly sorted out.
Thanks to this post, I just realized that we one piece was still missing, so please help to get Taxonomy term description has no text format done.
title?
hmm.. ok.. perhaps my bad.. last time i looked i could only see better formats doing cck fields, not title, body or any non-node fields.. i'll take another look.
great that things are sorted in D7.. but 1-2 yrs away for us.
Peter Lindstrom
LiquidCMS - Content Management Solution Experts