According to current API documentation: http://api.drupal.org/api/function/hook_action_info_alter/7

hook_action_info_alter() should allow to alter actions.. all, except already present actions, because in system.admin.inc:2866 (system_actions_manage callback for the 'admin/config/system/actions', the $actions retrieved by hook_action_info() and hook_info_alter() are only used to check if the require a configuration form.

Actually, the example in the a.d.o hook page does not work, because 'node_unpublish_action' is already present in the {actions} database.

I don't know what is wrong, the information on the a.d.o, the hook_action_info_alter() expected behaviour, or the system_actions_manage callback? but the three say different things.

CommentFileSizeAuthor
#1 929548-actions_synchronize.patch909 bytesmr.baileys

Comments

mr.baileys’s picture

Status: Active » Needs review
StatusFileSize
new909 bytes

I don't know what is wrong, the information on the a.d.o, the hook_action_info_alter() expected behaviour, or the system_actions_manage callback? but the three say different things.

… or none of the above ;)

You are correct that the example at http://api.drupal.org/api/function/hook_action_info_alter/7 does not work, and neither does changing anything other than the callback itself (the key in the associative arrays returned by hook_action_info and altered by hook_action_info_alter) in an hook_action_info_alter implementation. I also think that your expectation is how it is supposed to work.

The callback for admin/config/system/actions (system_actions_manage) correctly invokes actions_synchronize() as a first step in order to update the {actions}-table with up-to-date information on all non-configurable actions (with the list of actions being generated by actions_list() which invokes both hook_action_info and hook_action_info_alter). However, actions_synchronize() then neglects to update the {actions}-table in case any of the action info was altered (except for the key, which it does take into account). system_actions_manage assumes that the {actions}-table is up-to-date after calling actions_synchronize…

tl;dr: actions_synchronize should take updated actions into account too, not just additions and removals.

ilo’s picture

Good catch, mr.baileys! :)

Status: Needs review » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.