Configuration page: 'Content authoring' category

PDF and print versions is not a content authoring but rather an export service module, right? I'm not seeing a compelling list of contrib items for this category, even though I see this as being a perfect candidate for a category to house text formats under. Tough indeed.

PDF and print indeed wouldn't belong here.

I'm wondering if Mollom / Akismet / Captcha / ReCaptcha and similar modules might fit though?

Content authoring:

- Text format configuration (core)
- All wysiwyg editor integration modules
- All input filters providing advanced configuration

- Potentially spam filter modules (like catch mentioned)

But not:

- Any modules related to "User interface": Many contributed modules for D6 use this package already; boils down to nifty JavaScript and CSS stuff.

@sun: I probably lack an intimate relation to advanced input format modules, but the input format screens themselves allow for their configuration. What's so advanced that it does not fit here?

Attached is a patch which implements the suggestion. Hopefully found all arg() and $arg[] items which also needed to be changed. The testbot will inform us.

Ok, so I did miss updating one number.

Ok, no one reviewed this other then me - it didn't break anything here. So I am going to mark this RTBC, I think its reasonable to assume that WYSIWYG are so important they need their own compound to live in, this patch makes that happen.

As portrait in the initial issue, the name is somewhat bad - but I dont see us comming to a better title without user testing.

Right, the most important part of my message I forget. D.O please be aware of intend, tnx

Re #2: I'd think Mollom would be in 'Web services' but maybe it is better to think of Mollom as 'Content authoring'? To some extend, 'Web services' refers to implementation details, whereas 'Content authoring' refers to the actual feature (and end-user experience).

@Dries - yeah it's a toss-up between the two but I'd imagine most users of Mollom don't think of it as a webservice - same as any other mdoule which integrates with a service rather than turning Drupal into one (gmap, twitter etc.). If spam/captcha modules end up in Services rather than content authoring that'd also be fine though, and it'll just be a category with less items in.

It looks like this patch might need a re-roll. Asking for a re-test.

Yup, some hunks in filter.test and filter.admin.inc were in conflict due to recent filter module changes. I've regrepped for admin/settings/formats/ and no new appearances of that in core. Some of the conflicts even arised from the removal of them.

Ughm, so there was one ' missing in the patch. Doh. Sincerely hoping this one will be fine finally.

Trying to request a retest.

Ok, turns out the menu block access callback was removed in favor of simple access admin pages.

Committed to CVS HEAD. Thanks!