Note: Having raised this issue, I'm not clear that I'm right, my PHP is what I've gleaned from reading the Piwigo source code, and as a result very minimal in understanding. I understand why you've got these triggers - they should in theory allow extension of the core Piwigo code without copy and paste like I've had to, but, in order to maximise that possibility and standardise the approach, could all calls be perhaps given an object with all WS-API params, and the source method as a default, then extra details as the code Piwigo developers feel are needed to determine where the call is coming from in the logic - e.g. for categories.getList, you'd need the loop variables. This would give you more than you need in most cases, but by being standard, would allow less instances of having to change stuff in the core code stream and allow more work-arounds to be handled by plugins as quick fixes for example. I would have liked to have pushed a fix to the Extended Details plugin source repo, but because my fix also needs to go into the Piwigo repo, I don't think this is possible.
The following is one example where the param and the caller method name appear to have been muddled up, but there are a few more if I'm right. If I'm wrong, perhaps the docs could be clearer in the method declaration
ws_core.inc.php : line 586 has the call $result = trigger_change('ws_invoke_allowed', true, $methodName, $params);
trigger_change is defined in functions_plugins.inc.phpline 185
* @param string $event
* @param mixed $data data to transmit to all handlers
* @param mixed $args,... optional arguments
* @return mixed $data
*/
function trigger_change($event, $data=null)
Note: Having raised this issue, I'm not clear that I'm right, my PHP is what I've gleaned from reading the Piwigo source code, and as a result very minimal in understanding. I understand why you've got these triggers - they should in theory allow extension of the core Piwigo code without copy and paste like I've had to, but, in order to maximise that possibility and standardise the approach, could all calls be perhaps given an object with all WS-API params, and the source method as a default, then extra details as the code Piwigo developers feel are needed to determine where the call is coming from in the logic - e.g. for categories.getList, you'd need the loop variables. This would give you more than you need in most cases, but by being standard, would allow less instances of having to change stuff in the core code stream and allow more work-arounds to be handled by plugins as quick fixes for example. I would have liked to have pushed a fix to the Extended Details plugin source repo, but because my fix also needs to go into the Piwigo repo, I don't think this is possible.
The following is one example where the param and the caller method name appear to have been muddled up, but there are a few more if I'm right. If I'm wrong, perhaps the docs could be clearer in the method declaration
_pwg.categories.php_ : **line 268**
```$row['comment'] = strip_tags(
trigger_change(
'render_category_description',
$row['comment'],
'ws_categories_getList'
)
);
```
_ws_core.inc.php_ : **line 586** has the call
```$result = trigger_change('ws_invoke_allowed', true, $methodName, $params);```
`trigger_change` is defined in _functions_plugins.inc.php_ **line 185**
```
* @param string $event
* @param mixed $data data to transmit to all handlers
* @param mixed $args,... optional arguments
* @return mixed $data
*/
function trigger_change($event, $data=null)
```
<!-- github-sync-id:744159828 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Note: Having raised this issue, I'm not clear that I'm right, my PHP is what I've gleaned from reading the Piwigo source code, and as a result very minimal in understanding. I understand why you've got these triggers - they should in theory allow extension of the core Piwigo code without copy and paste like I've had to, but, in order to maximise that possibility and standardise the approach, could all calls be perhaps given an object with all WS-API params, and the source method as a default, then extra details as the code Piwigo developers feel are needed to determine where the call is coming from in the logic - e.g. for categories.getList, you'd need the loop variables. This would give you more than you need in most cases, but by being standard, would allow less instances of having to change stuff in the core code stream and allow more work-arounds to be handled by plugins as quick fixes for example. I would have liked to have pushed a fix to the Extended Details plugin source repo, but because my fix also needs to go into the Piwigo repo, I don't think this is possible.
The following is one example where the param and the caller method name appear to have been muddled up, but there are a few more if I'm right. If I'm wrong, perhaps the docs could be clearer in the method declaration
pwg.categories.php : line 268
ws_core.inc.php : line 586 has the call
$result = trigger_change('ws_invoke_allowed', true, $methodName, $params);trigger_changeis defined in functions_plugins.inc.php line 185