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.

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.

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.

In just one short month FOSDEM, the Free and Open Source Developers' European Meeting, is coming to Brussels again. Just like last year Drupal has its own Developers Room. The Drupal track is far from filled though so we're still looking for talk proposals and requests. The final date for presentation proposal is Friday January 9 so be fast!

Thanks to the lightweight and efficient Taxonomy Browser module it is now possible to use Drupal Digest to create your personalized Drupal news feeds. Just select the different topics from the browser to create the listing. Each listing has its own rss feed and each title links directly to the article on the original site. For example you can create a listing of all posts related to Drupalcon and then add the feed to your favorite aggregator.

I posted an article on the CivicActions blog about upgrading your CiviCRM installation from version 1.x to 2.x. Follow the "Continue reading" link to see the complete post.

When upgrading your CiviCRM site from 1.x to 2.x you might have to upgrade some custom modules. If you're upgrading to CiviCRM 2.1 or higher, this also requires that you're running Drupal 6. Upgrading your custom Drupal 5 modules for Drupal 6 is pretty easy: you simply download the coder module which will point out almost all required changes to your module with direct links to the documentation page about converting 5.x modules to 6.x.

Upgrading your custom CiviCRM modules to be compatible with 2.x however won't be as easy since a bunch of functions have been replaced or removed. The idea is to motivate developers to use the internal API's directly and not use these helper functions anymore. There is a developer discussion about the API Migration from 1.x to 2.x and while it offers some indication as to what functions were replaced, it doesn't provide a valid alternative for all removed functions.

Continue reading »