As I explained in an earlier blog post, I was tasked by Acquia (specifically Dries) to identify and propose fixes to issues around integrating visual content editors (WYSIWYG = What You See Is What You Get or RTE = Rich Text Editor). Instead of rushing to select an RTE, the focus of my roadmap is to solidify input format support in Drupal so that integrating a visual editor becomes a peace of cake at the end hopefully.
Textarea and format identification
Drupal is very flexible and this makes integrating an RTE harder compared to one-purpose systems. First I tried to deliver a solution for RTEs to identify the form fields to attach to. For this to work, we need input format metadata attached to form elements, which is implemented in issue #125315 with the new #input_format Form API key. This suffers from some parenting issues still (does not support multiple format selectors in one form), which we need to solve before being able to commit. On the same angle, the RTE should know whether that format has anything to do with the format supported by the RTE, be it HTML, wiki markup or bbcode for example. Drupal uses HTML by default, and administrators need to explicitly disallow HTML. This setting however was tucked down in the "Filter HTML" filter, which made it non-intuitive to identify. So issue #24988 deals with breaking that out to its own filter for easy non-HTML format identification. This way we can easily disable HTML RTEs on such formats.
Putting permissions to place
Simplifying input format setup is quite important. Right now, there is a disconcert between setting up general permissions and input format access settings. Although the later configuration maps input formats to user roles, it is implemented in its own custom permission system. By leveraging the core permissions system for this in #110242, just like the node permissions are implemented with their dynamic names, we clean up the user interface, bring in consistency to permission setup and also simplify the API.
More fun with blocks
Finally, there are quite a few textarea based input interfaces without format support in Drupal core still. For some site settings, like the contact page help or the user registration help, I think it makes a lot of sense to just use blocks. By making the help area an official theme region, we can put the help text there as a block, and allow users to add any number of blocks to the help region to add more custom help to any page. The one-off solutions for contact page help and user registration help can be easily generalized to an admin-configurable custom help system in issue #240873. By using blocks in the help region, admins can limit and share help between different pages, provide different help for different roles and use any format for their help input. If this sounds a lot like the helpedit module or somewhat like the helptip module, that's not a coincidence, this simple change would move some of the features of these modules to core.
I was browsing around in the fresh Drupal images on Flickr, when I stumbled on this composition. While in reality I had a back scratcher in my hand at the time (which became famous on its own right that day), this edition of the photo is simply hilarious.
I am way behind in blogging about DrupalCon Boston 2008, which was truly a blast. It was the biggest and best organized Drupal conference so far, and was put together in record time. I was happy to come early to Boston and stay a bit more with people who had their flights cancelled, and others who simply live in Boston to tourist around the city as well.
The conference provided lots of opportunities to be productive on-site in the BoFs and on the code sprint which followed the conference. Honestly, I intended to work on some of my core modifications for filters which (unfortunately) are still not in patch form, but without network connection for a considerable time, I needed to look into what I have on my computer, and figured I should work on the top priority contrib issue in my projects, as identified at the BoFs. Read on to find out more.
I just arrived back home yesterday, and could happily report that this year's FOSDEM was a great experience for me. I have last been there three years ago, at the first Drupal conference (which was at FOSDEM and also in Antwerp in a hotel basement). Lots of stuff changed. FOSDEM grew much bigger, there was a huge interest in sessions going on the Drupal room, as well as other rooms I visited to check out some sessions. Some topics were not as well covered as I expected them, like the Mozilla Prism session going about what's planned, and completely without any working demo. That was not much more then what we already knew.
Staying with the Krimson guys turned out to be the best I could do. They were not only welcoming, having perfect coffee and great wines at home, we got along very well. Jo and Heidi also helped me out a great deal to medicate the flu I seemingly got on Saturday. (I sincerely hope I did not pass on that to any of them). Looking forward to meet up with you in Boston again!
I made a few photos myself, which still need to be processed (not before DrupalCon Boston I think) and our session slides (and video as far as I have heard) is also coming up later.