Hello Devs,
I don't understand how I should handle $this->register_task.
I have noticed if a plugin is running on its own task then it behaves strange.
I think it is best to give an example:
I inlude a javascript file into each task which triggers an AJAX sync request as follows:
{{{ rcmail.http_post( 'plugin.carddav-addressbook-sync', '', rcmail.env.task == 'addressbook' ? rcmail.display_message(rcmail.gettext('addressbook_sync_loading', 'carddav'), 'loading') : false ); }}}
If this request is executed f.e. in Kolab's calendar task I get an error:
PHP Error: No handler found for action calendar.plugin.carddav-addressbook-sync in C:\xxxx\program\lib\Roundcube\rcube_plugin_api.php on line 462 (POST /?_task=calendar&_action=plugin.carddav-addressbook-sync?_task=&_action=)
The according action is registered in my carddav plugin (this plugin is not running on its own registered task):
{{{
$this->register_action('plugin.carddav-addressbook-sync', array($this, 'carddav_addressbook_sync'));
}}}
So, what am I doing wrong? How do I have to register the action in a plugin so that they are properly recognized while staying on a task which is registered/owned by another plugin?
Thanks for your clarifications!
Regards, Rosali
On Thu, Aug 14, 2014 at 3:52 PM, Rosali myroundcube@mail4us.net wrote:
Hello Devs,
I don't understand how I should handle $this->register_task.
I have noticed if a plugin is running on its own task then it behaves strange.
I think it is best to give an example:
[...]
So, what am I doing wrong? How do I have to register the action in a plugin so that they are properly recognized while staying on a task which is registered/owned by another plugin?
I guess looking at the request dispatching routine [1] clarifies the situation. First it checks is_plugin_task() and only if it isn't, the 'plugin.' prefix is checked. We might change the order of these checks and give precedence to 'plugin.*' actions but I can't imagine the side-effects such a change might have.
A work-around for your particular situation could be to execute rcmail.http_post('mail/plugin.carddav-addressbook-sync') or rcmail.http_post('foo/plugin.carddav-addressbook-sync') in order to not hit a task that is registered by a plugin.
Kind regards, Thomas
[1] https://github.com/roundcube/roundcubemail/blob/master/index.php#L296
Am 2014-08-14 18:28, schrieb Thomas Bruederli:
On Thu, Aug 14, 2014 at 3:52 PM, Rosali myroundcube@mail4us.net wrote:
Hello Devs,
I don't understand how I should handle $this->register_task.
I have noticed if a plugin is running on its own task then it behaves strange.
I think it is best to give an example:
[...]
So, what am I doing wrong? How do I have to register the action in a plugin so that they are properly recognized while staying on a task which is registered/owned by another plugin?
I guess looking at the request dispatching routine [1] clarifies the situation. First it checks is_plugin_task() and only if it isn't, the 'plugin.' prefix is checked. We might change the order of these checks and give precedence to 'plugin.*' actions but I can't imagine the side-effects such a change might have.
A work-around for your particular situation could be to execute rcmail.http_post('mail/plugin.carddav-addressbook-sync') or rcmail.http_post('foo/plugin.carddav-addressbook-sync') in order to not hit a task that is registered by a plugin.
I think 'plugin.*' should have precendence. Let's wait what others say. I can live with the code as is. Thanks a lot for the hints!
Best, Rosali
Kind regards, Thomas