more.zites.net

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!

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.

During the last days I was really busy with things like work and studying. So I had no time for the workflow-ng port "rules" for some days. Furthermore I'm going for one week to Ireland, so I won't have time during the next week either.
Anyway I plan to get back working on it as soon as I'm back from Ireland. I've already ported the API and overhauled it. I've added support for rule sets and improved things, so that the API is ready for further enhancements like generic scheduling and d6 actions integration. Furthermore I've written simple tests for the API, which will be a great help during further development.

As it looks like the rules API improvements take already too much time, so I won't be able to spend as much time as I'd like on the UI of the rules module. So I'll start with a more basic UI leaving the planned ajax/ahah usability improvements open for later. However if you like to help me working on that, contact me!

Actually I'm wondering what the features are that people are missing most in workflow-ng?

Currently I'm starting with the 6.x port of it, the rules engine. I'll utilize this opportunity to improve the system. So if you miss anything important, let me know now!

I'd also like to know your wishes! As a start, here are mine:

• generic scheduling support
• verbose mode, so that admins can track the execution of rules
• support for sets of entities
• to work with them - support for looping over these sets
• based on that support loading arguments from views
• basic variable support (strings, ..)

Yes, this all goes into the direction of a high level programming solution. Isn't it drupal's goal to eliminate the programmer? :)

I'm proud to finally announce the 2.0 release of workflow-ng. This brings a whole bunch of new features to you, e.g. now you can clone rule configurations, order them with weights or load further entities like (CCK) referenced users and work with them as usual.

For a more complete list have a look at the release notes.

Now I'm concentrating on the 6.x port, the rules engine. I hope to have at least a beta version out with the end of March.

Breadcrumbs...

One new feature workflow-ng 2.x just got, ist the "Set breadcrumb" action. Perhaps you know eaton's great custom breadcrumbs module? This new action is similar, but...

In addition to the new features which were already available for some time in worflow-ng's 2.x series, some further improvements are waiting for you!

Logging per entity

First off there is a new extension module, which is shipped with workflow-ng. It allows you to log a customize message on every support workflow-ng event for content or users. This is done by actions! For flexible display of the log messages, views support is available. So there a lot of possible use cases for this, I have to in my mind:

Activities..

You could easily log certain actions of users and their buddies and list them in blocks and pages generated by views. So you can build something similar like the (really interesting) activity module!

State change log

In workflows it's often desired to have a log of state changes. E.g. if content, let's say an article goes from "needs review" to "published" this should be logged and displayed on a tab associated with the article (yes, views can do that!).

Great, isn't it? Thank GHOP and corsix for that! Yes, corsix implemented the whole module in two GHOP tasks. This took him only 1 day per task, awesome!

Rules ?

Furthermore I've changed the terminology as preparation for 6.x. Configurations are now called rules. I think the term "rule" describes it very well.
With 6.x the core of workflow-ng will be a separate project: the Rules Engine

Looking at the TODO list you can see that I've recently implemented some new features for workflow-ng. The most important ones are:

• allow cloning of configurations
• allow ordering of configurations
• allow actions to load further entities
• on top of that, there is now support for loading referenced users and nodes from CCK fields
• allow modules to conditional include their action/condition configuration forms
• a brand new admin interface for the states module, which finally allows one to define custom state machines without coding. This machines may be e.g. used to track the state of content. Thanks GHOP and corsix for that!

I'm happy to announce the next release of workflow-ng. You can find the changelog at the release notes.

I think most important are two new features: First of now there is a really useful "Execute arbitrary PHP Code" action and condition, thanks to the awesome GHOP contest. Then now workflow-ng comes with conditions and actions for the path module. This makes even automatic path aliases possible! So if you are interested in a light weight alternative to pathauto, checkout the new tutorial "Automatic path aliases for content".

That sounds really easy, not? Indeed one can easily configure that with workflow-ng as well as using the node go to module.

But....
just using drupal_goto() to redirect to the new page breaks drupal's node access API as the node access grants are written after nodeapi 'insert' was invoked. If one uses nodeapi to create the redirect (like the node go to module and the workflow-ng solution), the grants doesn't get written any more....

Node go to issue: http://drupal.org/node/193944
workflow-ng issue: http://drupal.org/node/196445

Furthermore any other modules doing their job on nodeapi after the module issuing the redirect, won't be able to do so too. E.g. specified path aliases won't be saved any more. The list of possible problems is endless..

But how to redirect in clean way?