Fatal error: Cannot redeclare user_action_info

Same error here, is there a way to make these 2 modules compatible ?

Actions 5.x-2.x is a backport of actions/triggers in Drupal 6. As such, it claims the namespace from the action-related functions in Drupal 6. node_action_info() is an action-related function in the node module of Drupal 6. It should not be declared by any third-party modules.

workflow-ng uses hook_action_info too, and so also implements node_action_info.

Workflow-ng was built this way as it was the goal to combine the two different action implementations of workflow-ng and actions in the future - actually they work the same way wherever it was possible. So it makes use of the same hook name as I wasn't aware of any backport plans.

Anyway it's sad to have a conflicting backport here now, as workflow-ng can't change the API any more.

Subscribing.

The same with me. I was trying to install this, before installing Ubercart...
Now I am stuck...
Please help...

Thank you

I try to install action/trigger and have to delete workflow_ng
after installing action and trigger module I upload workflow_ng one file at the time
refreshing browser after each upload it worked

> Anyway it's sad to have a conflicting backport here now, as workflow-ng can't change the API any more.

With the ever increasing number of modules in contrib, part of being a responsible module maintainer is making a unique namespace for your module. That has translated to prefixing your module functions with a name that matches your module. In this particular instance, actions is an important and well known enough project for it to go into core, so the argument that you're stuck with the existing API doesn't hold up with me.

You're not the only one that's encountered namespace conflicts. The Mail module is partially halted in it's progress to D6 because of a namespace conflict with the mimemail module. In both the cases of actions/workflow-ng and mail/mimemail, it is perfectly within expectations for someone to run the combination of conflicting modules at the same time to solve their individual needs. To simply say "I was here first" just isn't fair to people that then have to maintain internal forks of modules to get stuff working.

Note, there's also precedent for function name changes even in core (e.g. module_exist() -> module_exists()).

deekayen, I never claimed that I was first and so I have the right to so - I just said that I can't change the API any more as several modules are using it already. I'd rather think it's unfair misquoting people.

Actually this is not about namespaces for functions, but namespaces for hooks as both modules invent hook_action_info and so implement node_action_info. Perhaps some guidelines for naming hooks would make sense too.

But as I already wrote above, this was no coincidence. I did so to make the action implementation as similar as possible to d6, so that workflow-ng actions can be easily upgraded to d6 actions. Probably this wasn't the best idea. Anyway I've learned my lesson, so rules (the 6.x port of workflow-ng) actually has it's hook names prefixed and makes a clear distinction between drupal actions and rules actions.

Personally I don't think this conflict is really critical as I see no sense in using both workflow-ng and actions 2.x at the same time as both modules actually do the same.

That's good to hear about the 6.x prefix. From what I understand from jvandyk, actions could prefix its 5.x-2.0 as hook_actions_action_info, which would also solve this problem. Even easier still might be to warn users not to upgrade to actions 5.x-2.0 if they have workflow-ng installed, otherwise go for 6.x.

hook_actions_action_info() sounds like the better solution to me, as this would avoid further possible conflicts when other contribs implement hook_action_info for workflow-ng, but actions 2.x is enabled, and the other way round. Furthermore this would enable contribs to implement both action types in a clean way.

Sry for this unfortunate situation, but when I wrote workflow-ng I just had not considered a backport of 6.x style actions :(

Changed node_action_info() in actions.module backport to be actions_action_info(). Because the architecture of actions' hook_action_info() allows modules to declare hooks for other modules, this works.

To reiterate, node_* is reserved namespace and should only be used by functions in node.module.

So why had you implemented node_action_info then?

Because you invented hook_action_info and then implemented the hook for the node module - and so did workflow-ng. Again, the problem here is not colliding function names, but colliding hook names. So renaming node_action_info just fixes the symptom, not the problem.

Your fix won't work, as there is also system_action_info, user_action_info, .. which collide too.

I will try to explain this again.

No noncore module should ever use core namespace because of the potential for namespace collisions.

The implementation for hook_action_info() in node module was done in core, in the node module which has ownership of that namespace, not in a contributed module as you suggest.

That is because the only module allowed to use node_* namespace is node.module. In core. No contributed modules should use node_* namespace. Ever.

It does not matter if you call your function-that-begins-with-reserved-core-namespace a "hook implementation" or not. It is a Bad Idea to use core namespace, and this issue demonstrates why that is.

The reason for this issue is that workflow-ng used core namespace when it should not have. Now core is using that namespace, which it has a right to and your contributed module does not.

I have released a new version of actions, version 5.x-2.2, which consolidates actions' hook_action_info() implementations into one hook implementation. This works around the fact that workflow-ng is using core namespace.

>No noncore module should ever use core namespace because of the potential for namespace collisions.

>It does not matter if you call your function-that-begins-with-reserved-core-namespace a "hook implementation" or not. It is a Bad Idea to use core namespace, and this issue demonstrates why that is.

In general I agree with you, but I think implementing newly introduced hooks for core modules is ok. Furthermore I think it's quite common, e.g. views and token do also so - and you also did until this fix.

Anyway thanks for implementing the workaround.