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.

A couple of days ago a new unstable release for Drupal 7 was published. One of the many new wonderful features is that installation profiles are now treated as regular modules. This means that you no longer need to learn separate rules, use obscure functions or apply a special Install Profile API. If you know how to write a module, you now know how to write an installation profile. If you want to view a simple example of how this exactly works now, you can take a look at the expert installation profile that ships with Drupal 7.

As Angie mentioned on the dev mailing list:

Install profiles are now basically modules with .install files, .info files to declare dependencies, etc. If you can write a module, you can write an install profile, and you can also do everything from install profiles you can do with modules including use the full Drupal API and write update functions to move from one version to another.

If I remember correctly Starbow was the first to suggest this approach in a post dated about a year ago. It looks like things will work out just fine. Good stuff!

When you create a new Drupal installation two users are created. The first is the obvious admin user with uid 1, which you will use to create your first pieces of content (or, for larger sites, to create the moderation role, assign the necessary permissions and create the moderation users). The second user might be less obvious. It's the virtual anonymous user with uid 0. You will not find it in any user listing, you can not assign any roles to it and you can not log in as the anonymous user. It's important to realize that both users are essential.

There are many efforts being put in preventing the deletion of the admin user since you could easily delete it using the admin interface. Webchick provided a short list of support issues about users that did so and who were unable to administer their site. But surprisingly there are also many things that happen when you have no uid 0, depending on which Drupal version you're using. On Drupal 4.6 and 4.7 you receive various Duplicate entry and Access denied errors while on Drupal 5 and 6 there are issues with rebuilding the user permissions and session information is never saved. This means that any actions that require information from the $_SESSION variable will always fail because upon each page request it is completely empty.

The anonymous user doesn't disappear all by itself of course. The most obvious way is to delete the row for uid 0 from the users table. If you wonder why someone would do this, here is a real life example:

Thinking back to when we first installed Drupal, my boss and I looked at the database and sure enough we though that a user with uid set to zero and no user name and or password was a bug and probably just deleted the row. Now looking back, the bug was actually introduced by us.

The solution here is to create a new "empty" user with uid 0. You might also lose the anyonmous user when exporting and importing the users table due to the auto_increment setting, as described in this support request. If this happens, you will need to manually update the record to set the uid value back to 0.

Yesterday we saw the birth of the CCK 3.x dev branch. One of the many exciting new features is the addition of the multigroup module. A multigroup works exactly like a regular fieldgroup in that it allows you to group different widgets together. You can for instance create a custom address group with textfields for the street name, zipcode and city, or a profile group with a nickname textfield and an avatar image upload field. What's new is that you can create a multi-value widget from these groups. So you can now create your own image gallery widget by setting up an image upload field, a title textfield and a description textarea and combining them in a multigroup.

This is another powerful step in eliminating the middleman by allowing administrators and editors full control, not only over the content types, but the widgets as well.