Drupal related posts by Gábor Hojtsy.

I am invited to speak at "Do It With Drupal"

A little bit before Drupalcon Szeged 2008, I was invited to take part in Lullabot's event, called Do It With Drupal. Being a co-lead for Drupalcon Szeged, I was completely overwhelmed with organization stuff there, but now that it was well done, I can move over to planning for future events.

Do it With Drupal website header

Do It With Drupal is going to be held in New Orleans, mid-December this year, and is basically a three day training event. Or as the FAQ puts it, it "is an expansion on the Lullabot workshops. Attendees can get much more in-depth and topic-specific information [compared to] the workshops. [...] Do It With Drupal is a very learning-focused event." I was invited to speak about multilanguage solutions, and I am going to again join the company of speakers such as Earl Miles, Karen Stevenson, Ryan Szrama, Moshe Weitzman, John VanDyk, just to name a few.

This event is quite a bit different to a Drupalcon, Do It With Drupal works with invited speakers whose hotel rooms and some of the travel costs are covered, and this is offset by having quite a bit higher entrance fees for attendees (starting at $795) on the other end. While Drupalcon's are characterized by anyone being able to be involved via BoFs and adhoc meetings, this event is about cherry-picking mainstream topics and closing in on them, so you get a different and very tight focus. This is the first event of this kind, and I am excited to see how this model works out. I am looking forward to be there and be involved.

Drupal Conference Hungary is on: November 15th in Budapest

As it turns out István Palócz, a lead in the Hungarian Drupal community was just energized again by Drupalcon Szeged 2008, and would not let the Hungarian community to skip this year's Hungarian Drupal Conference (you might call it a Drupalcamp). He already announced the date to be November 15th, and the location to be the usual Central European University Conference Venue in Budapest, which was the host of our previous local Drupal conferences the past years.

Do not let WYSIWYG editors rule our textareas!

Dries said (again) in his State of Drupal keynote this past week that a whole lot of people want WYSIWYG editors in Drupal. He also highlighted FCKeditor as the most popular one used for this job in the Drupal community (based on call-home data from Update Status module). So you'd say this is just too easy, move FCKeditor to core and we are done. Well, going the simple and quick way would just alienate those from RTEs (another nice acronym for these editors), because these editors are just too aggressive when it comes to pushing themselves to your face.

FCKeditor profile configuration screen annotatedThe assumption in these editors is to treat all textareas as fields with HTML input by default, so you'll obviously need the HTML editor on them. But this is not the case. In previous times, if you installed an RTE, and went to a block's configuration page, the textarea where you can provide a list of paths on where the block will show/hide was taken over by the RTE. Through time, the RTE authors realized this is a problem and built in tools to limit their reach. If you look FCKeditor's profile editing interface (image on the right), you'll find settings to exclude certain form item IDs from FCKeditor's work. But who knows the form IDs? Well, FCKeditor authors built a tool which tells you about the form IDs on forms, eg. on the block configuration page, it says: The ID for excluding or including this element is: edit-pages - the path is: admin/build/block/configure/user/1. Then if you need to modify your configuration on this field, you need to remember these values, go over to the linked "excluding or including" page and alter the list of items there.

There are a couple of flaws with this approach:

  • End users need to deal with (internal) form item IDs to configure their site for forms which are not covered by the default settings.
  • What guarantees that "edit-pages" will not be used as a form ID for HTML input in another form? Nothing. If we block it out, we block it out in all forms.
  • Blacklisting keeps textareas open to FCKeditor by default, so if a contrib module comes requiring text input in a field, there is no way to tell RTEs not to process that field, the user will face the pushy RTE and submit a bug against the contrib module such as http://drupal.org/node/293502 (and will get users hack as hell).
  • If this all was not enough, FCKeditor also has a simplified toolbar view, which is used for text input using the filtered XSS admin processor (when input format is not selected, but some HTML is still allowed). Again end users set up which textareas are using this method (beyond some defaults included). How they get to know that? Well, trial and error, or they need to look into the code.

All these ugly hassles for the end user, while we programmers know exactly that input from a textarea will be plain text (eg. email text, a list of paths), passed through filter XSS admin or filtered via one of the input filters set up. Not only that, but we know if a textarea is passed through input filters and the particular input filter used escapes HTML, it is pointless to display an RTE for HTML. So it is not only the page the textarea was displayed on, it is not only the ID of the textarea, it is also the properties of the selected input format for that textarea (when applicable) which defines whether FCKeditor should be there or not.

These are all things programmers can tell Drupal about without any user interaction, completely removing these settings and making WYSIWYG editing really seamless for the user. How do we tell Drupal what type of input is on the textarea? Well, we tell it to use a specific format. There are two competing proposals on how this should work, both in the issue: Textarea with input format attached. If you care about WYSIWYG editors in Drupal core (for Drupal 7), please help do quality reviews and provide feedback on the approaches proposed. This is a prerequisite to making RTEs integrate seamlessly to Drupal.

I will teach you port templates to Drupal 6 themes

If being a co-lead organizer for Drupalcon Szeged 2008, getting married in three weeks, moving flats and of course building products and services with Acquia would not be enough, I thought I'd top my Drupalcon participation with a nice surprise session submission.

If my session makes it (vote!), and you come to Drupalcon Szeged (you should), I'll teach you how can you convert an existing HTML/CSS template to a Drupal 6 theme in a matter of 45 minutes, with the full live demo from the ground up included with instructions. I've managed to do this before, so I am confident it should be lots of fun. We will break our Drupal site numerous times, and learn to live with it while the tough time constraints are looming on us, and should of course get to a gorgeous end result. We will convert the Modern World template by Solucija and will get to a Drupal 6 theme with blocks, menus a theme screenshot and all.

I'll also tell you how can you contribute the theme to drupal.org or through other means if the template license does not allow you to upload to drupal.org. This is of course not a requirement, since you might as well only work for your own client. You decide!

Just make sure to vote on my session, to help me get into the program and come to Drupalcon not only for this great session, but all the other fun programs which are on offer. You definitely should not miss it!

2008, the year of Drupal themes

Looks like people are finally realizing the enormous business opportunities lying in doing themes for Drupal sites. There is the http://www.topnotchthemes.com/ team building truly nice themes with support for common modules, knowing Drupals ins and outs.

At the same time http://www.templatemonster.com/ is picking up Drupal in their CMS section, selling Drupal themes for all kinds of focus areas. Although some of their demos have the "Mambo license" menu item running, which is quite frankly not a testament to their understanding of Drupal. However, starting off from a ported theme could still be nice, those buying Drupal themes might not want to fiddle as much customizing the theme further (update: and there are possibly other problems my soft blogging style did not uncover here, see: http://www.drupal4hu.com/node/146 and http://www.drupal4hu.com/node/141 for notes).

If you'd be interested in ported themes though, you might want to just start off from a theme downloaded for free. There is a new site coming up, started by a Hungarian Drupal enthusiast Ádám Boros. He is going through some of the exciting existing HTML templates and converting them to Drupal themes, providing for you to download for free. Why another theme site, you might ask? Why not just submit to Drupal.org? Well, although free to use and take, some of the HTML templates are not released under the GPL, so they are not suitable for submission on drupal.org. This requires people to either host them on their own site, or go centralize to a location. Ádám's new site, drupal6themes.com aims to not only host Ádám's work but also provide a platform for others to submit their Drupal 6 compatible themes and host them there.

I am extremely happy to see all these theming businesses and the expansion of the available themes to come together, and hope the growth is going to be even bigger going forward.