To get the simple one out of the way: BBCode is definitely out of the question. Introducing yet another markup language is not an option.

Having an editor like Kupu available might be an option, as long as it's stripped down a bit and doesn't offer the full range of formatting options.

In my opinion, it's no less readable as plain text. If your forum post requires headings, subheadings, image inserts - you should use a document to get your point across instead.

The ideal thing would be to have a simple transform that did the following:

• Any inserted HTTP links are hyperlinked + formatted for display so that the link doesn't exceed 30 characters. The resulting link would look like: http://plone.org/documentation.../introduction
• Any email addresses added would be obscured using HTML entities to offer a rudimentary level of spam protection, and hyperlinked.

That's all that is required, IMO.

Again, this comes down to whether you want to do content management within forum posts (formatting, attachments, the whole enchilada - aka. the CMFBoard approach), or whether you want to make it as easy as possible for people to participate, and keep the content compatible with mailing list integration.

Didn't think that you'd think BBCode was a good idea. ;-) For the record, I don't really either. Just thought it was worth floating.

Just to be clear, I'm not advocating for "full formatting" options (e.g. images, headings, etc.) either.

However, I do think that minimalist formatting, which I define as:

• bold & italic blockquoting basic bullets * hyperlinked phrases -- not just URLs

Really helps improve usability/readability for users, especially in longer posts.

I agree that a stripped down Kupu would be a good way to do this

that we we'd reuse a tool we've already got.

Substituting other content types doesn't really seem like a viable substitution to me.

That said, auto http:// and mailto:// linking would be a useful step forward.

I agree that most of the time images and complete formatting are more annoying than serving a forum. But in some cases it can be necessary. We need it in our intranet when discussing prototypes improvement.

My point is that it's more a functionnality which is to choosen by the site manager. I would prefer a tunable version of kupu with choices to enable images, formatting, ...

It's either Kupu or plain text (with utility to auto format http:// and mailto: content), depending on their preference setting. Having other options, whether transparent or not, is too confusing for the user.

I completely agree that allowiing kupu integration is needed. I for one despirately want users to use kupu to edit conversations and comments, to be consistent with the rest of my site. I understand other people may not want kupu, or all of kupu's features, so I guess this should be a feature similar to kupu's use in the rest of Plone (ex: the admin sets an option to use kupu or not).

Now, as far as the feature set of the used kupu, I don't mind allowing the full, unmodified kupu. My users will be used to it from the rest of the site, and I as an admin don't mind complex formatting in comments.

I've never used BBCode personally, and I think that if HTML editing via kupu was available, none of my users would want BBCode anyway.

I think there is already some code to make this pluggable. We should just provide very basic stuff.

Offering kupu to manage forum messages is way overdone. I agree with limi to use plain text and transforms for basic markup only.

One common remark to the development of Ploneboard. I think we should keep Ploneboard minimalistic and focused to the most common use case. Let's prevent Ploneboard from drowning of features like CMFBoard did.

I'm not for CMFBoard-overboard. Nor am I into mandatory minimalism. I agree that my communications would be augmented by having the standard, rich text options provided by kupu. Standard Plone kupu options aren't 'overboard'. While I generally prefer the text editing allowed by FCKeditor, I would be quite happy with standard kupu. I can see that there are strong feelings on both sides, so why not let site admins decide with a simple control panel to turn options on or off? I know it means work/money--and that is a good reason. However, let's not limit ourselves because we think minimal is good enough because it is good enough for 50% of plone users. BTW has anyone taken a poll on editing capabilities? That could be some interesting research...

David,

Note that this PLIP is now "completed and merged." We decided to use Kupu, but to strip out a bunch of unneeded formatting controls (which could be added back in).

Jon,

I'm looking forward to upgrading my ploneboard and trying it out. Actually, I did know that this particular issue had been solved. I guess I was weighing in on the larger issue I see in the plone community of whether to permit admins to decide on how much text editing control to allow their users. Over the last 3 years that I've worked (on a very superficial but extensive level) with Plone and with this issue, I've gotten the impression that Plone developers don't want 'big pink letters' on a site that uses their cms and I'm a big advocate for pragmatism.
David

I agree that an add-in is in danger of drowning from add-ons. But unless the code changes and maintenance are horrendous, I don't see the issue with Kupu.

I recognize that other forms of discussion are possible in Plone, but that means then that you have two separate threads going on. And, the built-in discussion model assumes one is discussing a piece of content. It would be nice to have a discussion board implementation within Plone. If that's not the goal of Ploneboard, then why have Ploneboard at all.

Also, the Plone discussion model is not as familiar as the Ploneboard model.

I think I'm trying to say that if one constructs an add-on to implement a particular feature in Plone, then one must confront the minimum feature set that customers expect in that feature, especially if the feature is well-known in the community. I haven't yet seen a discussion board that didn't offer rich text. If Ploneboard doesn't offer it, then why have Ploneboard at all?