Setting up a Wysiwyg or rich text editor in Drupal is a straightforward task: you download the Wysiwyg module along with the library of your favorite editor and you're good to go. You will run into issues when you're using CCK multiple value fields though:

• You will experience data loss when adding more fields: all content added to existing fields will disappearing when you click the "Add another item" button to add a new field.
• Depending on which editor you use, there's a chance of hick-ups and data loss when using the drag-and-drop interface to rearrange fields.
• Depending on which editor you use, you will run into different kinds of unexpected behaviors when adding your first new item after clicking the "Add another item" button. These issues can range from the editor only appearing on the first field, to only appearing on the last field, or from the editor disappearing completely.

The first two issues can be fixed by installing the Wysiwyg API CCK Integration module, which itself depends on three other modules: JS Alter, jQuery Form Update and jQuery AOP. These modules require no configuration: just enable them to fix the problems.

The third issue however is more tedious. I've tried fixing the bug with hook_form_alter() and CCK fields along with the Wysiwyg integration guide but these don't play along nicely. The added difficulty is that the problem varies depending on which editor you use. The only bulletproof "solution" I've found this far is to simply use the FCKeditor editor: it's the only editor that doesn't appear to cause any unexpected behavior. Do note that these problems are only fixed if you use the FCKeditor with the Wysiwyg module: the FCKeditor module itself still has these issues.

The Drupal template override system is very intuitive: find the template you want to alter, copy it to your theme folder and adjust it. The handbook page on d.o about overriding themable output is even one of the most complete and appealing I've seen. So I was surprised when I wanted to override the core poll module's "Most recent poll" block, and found out it simply wasn't working. Try as I might the altered poll-results-block.tpl.php that was sitting in my custom theme folder wasn't being recognized, no matter how many times I cleared the registry or double-checked the paths and filenames. I had my Eureka moment want I came across this d.o issue about how themes can't use node-story.tpl.php without node.tpl.php. John Albin explains the history of this issue (and why it won't be fixed in Drupal 6) in comment #48.

The issue is fixed in Drupal 7 but just so you know in Drupal 6...

• if you want to override poll-results-block.tpl.php you need to copy poll-results.tpl.php as well.
• if you want to override comment-blog.tpl.php you need to copy comment.tpl.php as well.
• if you want to create a Zen subtheme with region-sidebar-first.tpl.php you need to copy region.tpl.php as well.

Following Davy's initiative, here are two years of Mollom stats for mostrey.be. Spread the word!

When you're creating a social site you want to make it as easy as possible for new users to register. Or even better: have them log in with one of their existing accounts so they don't have to go through yet another registration process and have yet another account to maintain. OpenID goes a long way in doing this, but people that are less tech savvy might not be familiar with it and you don't want them to read through a page of documentation just to sign up. Just an example: most users don't realize they can enter the url of their Google profile and use it as an OpenID url.

However, most users that participate in social networking sites already own a Twitter, Facebook, MySpace or Blogger account. Services like Gigya (which is completely free) and RPX (which includes a free plan) provide an easy way for users to register on your site by logging in with one of their existing accounts. Gigya created a Gigya Socialize module for easy integration with Drupal. As a site admin all you need to do is sign up on Gigya (using one of your own accounts) and create an API key for your site. Enter this API key in the module configuration page and you're ready to go.

As a sidenote: apart from user authentication Gigya also plugs in to the different social APIs so that users can send status updates and tweets from your site for instance, or so they can connect with their friends from other social communities. It's like an instant social starter kit.

The development of Drupal 7 has been unique in many ways. One important milestone was the introduction of unstable releases in October 2008. After ten unstable releases we saw the first alpha release in January 2010. These releases are important because they provide an easy starting point for users for testing and for reporting issues. The more people install and test these releases, the more bugs will be found and the more stable the initial Drupal 7 release will be.

Most people that use these releases however are likely to already know their way around Drupal and to embrace most drupalisms. What greatly increases the variety of people testing Drupal 7 is the private beta testing of Acquia's Drupal Gardens. Some of these beta testers, running a total of over 1000 sites, might not even realize that Drupal Gardens runs the latest official version of Drupal 7 (currently that's Alpha 2) and that by helping test Drupal Gardens they're also testing Drupal 7. This already resulted in a bunch of Drupal 7 bug reports (which are listed on the private forums).

A wise man once said that "[i]f your primary motivation for wanting to be a beta tester is to 'try out' a product before it is released, then you are bound to be disappointed when it turns into a lot of work." Drupal Gardens however makes testing Drupal 7 easy and accessible. Some people might not even realize they're doing it.

There are plenty Drupal modules that offer ways to upload new files and to attach them to nodes. There's the core upload module, the image module that creates an image content type, filefield that creates a CCK field, ... The options are much more limited when it comes to re-using already uploaded files. You could use a nodereference field or image_attach to link image nodes, or a WYSIWYG plug-in like IMCE, or the WebFM module, and that about covers it.

For a current project in Drupal 6 I was looking for a CCK widget that allowed me to upload new files as well as easily access existing files. Drupal 5 has the asset module and Drupal 7 will have the wonderful media module but for Drupal 6 the options are very limited. After a lot of searching I came across the FileField Sources module. It enhances the filefield module (that allows you to upload new files) by adding a way to import files by url and by adding an autocomplete field to search for existing files. One of its most interesting features for me was the bridge with IMCE. All in all these three extra options allow for an incredible flexibility in file management. And because the selected file eventually ends up in a filefield field it can be plugged into the multitude of modules that support it, such as media mover for instance.

In the smallcore debate we should focus on what our goal is. We don't want a smaller core as much as we want an independent core. To build a better teddy bear it doesn't matter so much that the openid module or blog module ship with core, but it does matter that the system or profile modules tie in with the node module, hard coded.

In his article Adrien says that "[a] large portion of time spent building something like Managing News or Open Atrium is spent undoing the assumptions that Drupal has baked into core directly." I agree with this. I don't agree that this means that we should never include a default wysiwyg in Drupal for instance. I think we should, but that it should be as a completely independent module that we can simply switch on and off. The main goal is to have a Drupal core which we don't have to alter in order to create our own distribution or highly customized site.

There will be a higher resistance against a smallcore because this means we're no longer working towards our goal of eliminating middlemen. It moves Drupal towards a framework instead of a user-friendly cms while it really can be both. If we see Drupal simply as a framework then why would we add cck or views in core instead of keeping them as a contributed modules? An independent core however would allow for the blog, openid, cck and views modules to be part of core as separate components. It means we can ship core with different installation profiles like a multiblog or a social network profile, while not getting in the way of more custom distributions like Open Atrium.