Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By lefnire on
it seems like D6 trigger.module is the new workflow.module, right? if I'm right, is there a downside to this... as in modules that integrate workflow.module?
what about workflow_ng... is that made obsolete by workflow? that one seems to have more integrating modules. and for that matter, what is the difference between workflow_ng and workflow... i can't seem to figure this out from the docs.
Comments
I would also like to know
I would also like to know what the main differences between workflow, workflow-ng and the new triggers and actions in D6 core.
Could anyone shed some light on this?
thanks!
I haven't examined/compared
I haven't examined/compared these enough yet to give any good explanation, but it seems that the survivors in Drupal 6 will be:
http://drupal.org/project/workflow versions 6.x-2.x (compatible with Drupal 6 actions/triggers)
http://drupal.org/project/rules (the successor of workflow_ng, replaces Drupal 6 triggers)
With the inclusion of
With the inclusion of Actions/Triggers into D6 what is the reasoning for converting these modules to Drupal 6? Wouldn't this just create more duplicated code?
Thanks!
The workflow module supplies
The workflow module supplies workflow states for node types. Actions and triggers don't have workflow states, but they can support them.
The rules module (successor of workflow_ng) also supplies states, and replaces core actions and triggers. The developer was fully aware of the available core modules but obviously found them insufficient for his needs, he wrote his own and made it available for people with similar needs.
This kind of duplication can't be avoided and is usually a good thing in the long run. The only problem is the user confusion caused by this. I think the only way to address this problem is comparative documentation and a better formal categorization and description of the modules, their function, their application domain, their code quality, their popularity and their development and support activity.
So what your saying is that
So what your saying is that Rules doesn't build upon the Actions and Triggers in core but side steps them completely?
Yes. The trigger module is
Yes. The trigger module is the one responsible for triggers and actions in D6 core, and here it says that the rules module is "a more feature rich replacement for the trigger module in core".
http://drupal.org/project/rules
modules have no upgrade path
Yeah this guy doesn't seem to care about compatibility. The 5.x module (workflow_ng) is essentially discontinued in favor of 'rules'. He did the same thing with the 5.x node_profile module, which has been discontinued in favor of content_profile (which now he says will replace the bio module too). Both of the 6.x versions though are missing tons of features and nowhere near ready, and the 5.x versions still have their own bugs and limitations as well.
What's going to happen when drupal 7 is released next year?
So I'm glad I stuck with templating the regular user_profile rather than use bio or node_profile, but if I had known it was the same person I would have used workflow instead of workflow_ng (workflow has both a 5.x and 6.x version that is compatible).
RE: modules have no upgrade path
Talking of bugs, also Workflow has its bugs, or even not optimized code.
If you see the list of bugs in that module, you will see that it has some porting issue. It seems the code has been copied from the Drupal 5 version of the module, but has not been completely adapted to the new version.
It does not seem fair to
It does not seem fair to blame a developer for any work, for several reasons.
Generally, an open source developer does not owe anything to anyone. More specifically, anyone who choses to use a module such as workflows_ng or node_profile for their additional features should be fully aware of the possible difficult future situations with upgrades.
Some of fago's choices were dictated by the direction Drupal core was taking. If he continued his modules in their existing form they would probably divert further and further from core. And I don't think he did bad at all with the upgrade paths.
Actually I avoided using workflows_ng in the past for these reasons, since I didn't really need the extra features. From the other modules you mentioned, the content_profile module seems a solid choice future-wise and it has some consensus from other developers.
thank you
for blaming me even without reading the project pages.
* content profile has an upgrade path
* a upgrade path for rules is in work and will be in place before a first beta release
Use the core modules
I would think that is better to use what the core modules offer, before to write a module which duplicates the same code present in those modules.
For Workflow, the Drupal 6 version of the module has sense for who already used it with Drupal 5; any new users which didn't use it before, and installed Drupal 6 should use Actions, and Rules or find a module which uses the code present in the Drupal core (and that now is not even put in actions.module).
I agree
I agree on that. There are many modules that are implemented in a wrong way, or are too limited. It would be too much to ask that somebody doesn't make a module if there is already a module which does similar tasks. In that way, if the first person is not able to implement the module code, or he would not be able to fix a bug, Drupal would stay in the prehistory.
I see the trend in drupal
I see the trend in drupal modules as becoming more flexible and generic, like lego blocks. With the main goal of interoperability between modules. I think it is a good thing for *some* consolidation for drupal modules. I am all for the Unix-y way of doing things, but do we really need multiple modules that do practically the same thing or do it in a similar way?
I find that the best modules usually get refactored and put into core "CCK for D7", Update Status, etc..
is there meanwhile another
is there meanwhile another forum post or documentation about this topic:
actions
trigger
workflow
rules (workflow-ng)
or a starting point - i'm a little bit confused ...
thanks momper
Subscribe
(Yeah, I know it is almost 2 yrs old; but I think still a relevant discussion and I would like to know whenever there are more updates to this discussion)
.
The workflow module is different from the rest. It deals with nodes. It lets you define your own workflow states for node types (with names like "Draft", "Reviewed" etc, which may mean whatever you want) and transition between states. You can define which user roles can do these transitions.
Actions and trigger (in core since Drupal 6) and the more advanced rules module let you specify generic events (when someone saves a node, when cron runs, etc) which trigger the execution of a specified action (send out an email etc). These are generic actions and they don't do anything special for node types.
When you use workflows, you can optionally set up actions to be triggered when a state transition happens.
Comparing the rules module with actions and trigger, rules lets you write your own actions using PHP without writing a module for that action, and also lets you specify conditions to check whether an action will run or not.
Thank you for this great description!
This helps to clear up a few questions I had.
Subscribe
Thanks! Answered questions I had about