planet

While I've been working on the flag module's rules integration and getting the 1.0 release out, I've also fixed the details of my master thesis. I am happy to announce to further enhance rules during my thesis. The main feature I'm going to work on is allowing rules to work with remote sites and content. I'm going build client and server-side web service support, so that several drupal sites can talk to each other. Furthermore I'm going to make it possible to invoke arbitrary SOAP-based web-services out there, maybe also others. Perhaps the right way to do achieve that might be doing rules integration for the service module. You want to invoke a web-service? - Just use the action for it. You want to create a web-service? - Just build a rule set. Apart from that I'm going to build a readable rule export for documentation purposes, work out a basic publishing workflow and research some semantic web research capabilities. Actually I'm thinking about integrating with the RDF-API to get some meta-data about drupal objects, which is important to have in place when dealing with remote content steming from other drupal sites.

A lot of people run drupal with lighttpd, a light and fast webserver, which uses FastCGI to support PHP. As lighttpd doesn't read .htaccess files, some extra config is required to get drupal's clean urls working right. I'm doing so already for a while now, finally I found the best way to do clean urls with lighttpd. I started with some url-rewriting regexes, which isn't ideal as there are problems with some special paths or dots. I've improved the regexes a bit, but still there were problems. Another common way is to use a lua-script. The big advantage of this script is that one can do the url rewriting based on the condition whether there is a file for the requested path - so no regex magic is required. Thus there also no problems with dots. The disadvantage of that approach is it's inflexibility. When you want to install multiple drupal instances in several different sub directories or use a script to generate settings for all your drupal instances, it's odd that the lua variant needs one script per drupal prefix, because you have to set the prefix in the lua script! Finally I found a way to work around this inflexibility. First off I looked into passing the prefix variable into the lua script, but I had no luck with that. So I decided to go for another approach: I wrote a simple wrapper script, that creates the needed lua script with the right prefix set on the fly. So when lighttpd parses your configuration it calls the wrapper script, which makes sure there is a lua script in place and returns the suiting configuration for your drupal installation. Ok, enough talk. Let's see how it works.

Today I held a presentation about rules at the drupalcamp in Cologne, Germany. It was really amazing to see how many people are interested into rules! You can find the slides of my presentation attached to my post. If you are interested, my presentation was also recorded. Hopefully the video is up soon - probably it'll be linked here. Thanks go to criz for taking the photo! The drupalcamp here in Cologne is a pure success! There are really interesting sessions and it's just amazing how many great people are here! I'm looking forward to the next day tomorrow. Oh Greetings from cologne!

The BETA 2 is already more than a half year old - so a new BETA release is really long overdue. So I've worked hard during last days to get a next BETA out of the door - finally it's there! Of course there were a lot of improvements and bug fixes since BETA 2, so let me mention only the most notable ones:

• added support for an edit tab at the users page: either on the top level or as secondary tab below the "Edit" tab.
• added an extension module for integration at the registration page
• made theming with content profile easier and added content profile docs for themers
• added the possibility for admins to add content profile nodes for other users
• basic support for translated profiles with the help of the "content translation" module
• added Views integration
• added rules integration with support of upgrading from nodeprofile workflow-ng rules.
• by Gundalo and Michelle: added Panels integration
• added more usage help and hints to the README

Let's have a closer look at some points of these...

Theming with content profile

When you have a "profile-as-nodes" you probably want to use some profile information stored in your profile content in some of your themes, e.g. to show some additional information about the author of a forum post. To do so, you previously had to manually load the profile node in your theme and output the right data at the right place - yeah and not forget to properly check your data... This cried for improvements, so I tackled this problem. We need to be able to easily access the data of the created profiles, where it should be already properly prepared for use in a template so you haven't to check it yourself. Yes and we should do that fast.. So just loading all profile data and putting it into $user is really no option.

I've just released 6.x-1.0 of the content access module - yet another node access module. In comparison to the 5.x version there are quite some changes and improvements.
First off the module leverages the new permissions for content types of drupal 6: "edit any type", and "delete any type". Then consequently it makes also use of the "edit own type" and "delete own type" permissions and provides a "view own type" setting. So the 5.x "author" checkbox has been removed in favour of these role based settings. So with content access you have got the modules' settings and drupal's access permission settings. To give you a better overview about your settings content access respects and makes use of drupal's built in permissions as far as possible. Which means the access control settings provided take the built in settings of drupal into account and provide you a good overview about the really applied access control settings for a content type or content node - on just one screen! Let's show an example. If you don't grant "access content" to your anonymous users, they won't be able to do so - regardless what you would configure in content access. So the module forces the corresponding tick to be unchecked and shows you this message: Another example: If you set access control permissions for a certain content node, which is unpublished, drupal won't take your settings into account as it treats unpublished nodes in a special way. So content access warns you: Then if you use the "per content node" settings, it's now possible to reset the permissions of a content node back to the content type defaults. Apart from that there were a bunch of bug fixes for both drupal 5 and 6 versions. klausi tackled writing simpletests for content access and did an awesome job - now there is bunch of tests for both the drupal 5 and 6 version. This is really important thing to have, as access control is important to work right, right? Right!

For the second exercise of my Information Retrieval course at the university I had to do implement a relevance feedback system - so I thought: Why not build it upon drupal's search? So that's what I did. The result is a working proof of concept module, which you can find in my sandbox and test at the demo site. The system has two operation modes: One that uses "implicit feedback" and one that let's the user give "explicit feedback". The implicit feedback mode just tracks which search results the user has viewed, takes these results as relevant to generate an optimised search query and shows the improved results to the user. The explicit system works the same way, but provides some UI for users to mark results as relevant and non-relevant, as you can see on the screenshot: You can test the system at the demo site, which runs in explicit feedback mode. Once you have provided three positive results as feedback the system makes use of the Rocchio algorithm to generate an optimised search query and redirects you to the improved search results.

I'm happy to announce the rules 6.x 1.0 BETA 1 release. Check out the rules project page and try it. Now the API is frozen and modules developers are encouraged to write module integration and to port their workflow-ng integration to rules. You can find the documentation here. To get token support everywhere in your actions you just have to install the latest development snapshot of it. Now basically everything is there, including support for

• firing core actions
• grouping rules in rule sets
• scheduling arbitrary rule sets
• a module input evaluation system
• and much more!

If you want to know more details about the improvements done for rules 6.x check out the development status page or the slides from the drupalcon session.

Developers often want to embed a node form. So I'll try to work out, how this is done best in drupal 6. For 5.x I provided the subform element module, which was an easy way to do it. However recently I found out, that embedding fully working node forms in 6.x isn't so easy any more. The funky JS stuff of node forms, which relies on the #ahah form API property, fails if $form doesn't look that way it expects.

So how to embed a node form with working AHAH?

Fortunately, it's not that hard either. We must just ensure to keep the structure of $form as in the original form. So don't move the embedded form in $form['fieldgroup'] - or it's #ahah stuff gonna break. So let's show how to embed a node creation form.

I'm really happy to announce that Content Profile is going to be the common base module for "profiles-as-nodes" solutions in drupal 6.x! After a long discussion thought my efforts to join bio and node profile development were for nothing. But then the discussion continued and we were able to agree on a common base module, which avoids unnecessary code duplication and provides an API on which further extension modules may rely on. The people from FunnyMonkey started working on it and agreed with me on continuing my previous work on this topic: Content Profile :) So now as we have a decision we can concentrate on coding..

Quite a long time ago I started the discussion about the future of the profile as nodes solutions out there (link). There was a lot of input to the discussion and most people (including me) agreed on variante 2 "build upon a small base module". This means we build a small, well tested simple profile-as-node solution, which can be further extended by other modules. So I had started developing content profile and invited others to join in - but unfortunately no one did. Now after some discussion it looks like there will be a 6.x bio version - introducing the imho unnecessary duplicity again. As an affect code like views integartion, user register integration and so on has to be written twice - once for each solution. But in my opinion the worst is that further extension modules, which want to build extended functionality on top of "profile as nodes" can't support all solutions by building upon a single module - they would have to build support for each solution on its own. Don't mentioned that they can't rely on a unique API to do so. So what I'm going to do now?