adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-10-30 21:52:00 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

Allow plugins to extend pwg.images.setInfo #584

New Issue
Closed
opened 2026-10-05 00:05:41 +02:00 by adam · 10 comments
adam commented 2026-10-05 00:05:41 +02:00
Owner
Copy link
Copy source

Hello there!
Thank you for your wonderful plugin.
I'm trying to update with Piwigo webservices the value added from your plugin (in table _images, value is_sphere).
I tried with the service pwg.images.setInfo but the field is_sphere is not recognized.
I don't know if I have to use the service pwg.plugins.performAction, but in this case, I don't know the first parameter. They are (action, plugin, pwg_token).
Can you help me or suggest me a solution?
Because when I add a new image through webservice, the field is_sphere is 0 by default.

I've modified as follow:

  $info_columns = array(
    'name',
    'author',
    'comment',
    'date_creation',
    'is_sphere',
    );

Now it works as I would!
Can you modify the original function php in order to do that in the next update?
Thank you!

Hello there! Thank you for your wonderful plugin. I'm trying to update with Piwigo webservices the value added from your plugin (in table _images, value is_sphere). I tried with the service pwg.images.setInfo but the field is_sphere is not recognized. I don't know if I have to use the service pwg.plugins.performAction, but in this case, I don't know the first parameter. They are (action, plugin, pwg_token). Can you help me or suggest me a solution? Because when I add a new image through webservice, the field is_sphere is 0 by default. I've modified as follow: ``` $info_columns = array( 'name', 'author', 'comment', 'date_creation', 'is_sphere', ); ``` Now it works as I would! Can you modify the original function php in order to do that in the next update? Thank you! <!-- github-sync-id:209543085 -->
adam closed this issue 2026-10-05 00:05:41 +02:00
adam commented 2026-10-05 00:05:42 +02:00
Author
Owner
Copy link
Copy source

I will reformulate : this request is about allowing plugins to expose more image properties updatable via pwg.images.setInfo.

I will reformulate : this request is about allowing plugins to expose more image properties updatable via `pwg.images.setInfo`. <!-- github-comment-id:281913917 -->
adam commented 2026-10-05 00:05:43 +02:00
Author
Owner
Copy link
Copy source

Thank you for changing the title!

Thank you for changing the title! <!-- github-comment-id:281966043 -->
adam commented 2026-10-05 00:05:43 +02:00
Author
Owner
Copy link
Copy source

@plegall I looked a bit a this to integrate it in the PhotoSphere plugin and I see two possibilities :

  1. add a trigger_change to allow plugins to modify $info_columns, this would work for most cases for simple columns
  2. add a trigger_notify at the end of the method to allow plugins to make arbitrary updates, this is more flexible, but in case a simple updates would require two or more SQL updates.

In both cases the ws.htm file won't be updated, unless adding adding yet another trigger for the reflection method.

@plegall I looked a bit a this to integrate it in the PhotoSphere plugin and I see two possibilities : 1. add a trigger_change to allow plugins to modify `$info_columns`, this would work for most cases for simple columns 2. add a trigger_notify at the end of the method to allow plugins to make arbitrary updates, this is more flexible, but in case a simple updates would require two or more SQL updates. In both cases the ws.htm file won't be updated, unless adding adding yet another trigger for the reflection method. <!-- github-comment-id:2322112027 -->
adam commented 2026-10-05 00:05:44 +02:00
Author
Owner
Copy link
Copy source

The Batch Manager Unit Mode is under heavy redesign in Piwigo 15. Instead of a big POST request with all photos at once, it's going to be (already in 15beta2) one call to pwg.images.setInfo for each photo. And we want it to be "extendable". @marsooooo is working on this subject and he may have some thougts to share.

The Batch Manager Unit Mode is under heavy redesign in Piwigo 15. Instead of a big POST request with all photos at once, it's going to be (already in 15beta2) one call to `pwg.images.setInfo` for each photo. And we want it to be "extendable". @marsooooo is working on this subject and he may have some thougts to share. <!-- github-comment-id:2322215295 -->
adam commented 2026-10-05 00:05:45 +02:00
Author
Owner
Copy link
Copy source

I am currently working on the Skeleton plugin to showcase new ways to validate extension fields in Batch Manager Unit Mode. An update should be available early next week.

The idea behind the redesign is to give collaborators more freedom in how they implement new functionalities based on their needs. Moving away from the old POST request was necessary because now you can validate your changes one picture at a time, dynamically.

For the Batch Manager Unit Mode, the idea is for an extension to inject its template and functions directly into the page. When validating a picture, the core calls each extension's JavaScript functions named batchManagerSave_[pluginID] , which then call the assigned API method. For example, in the Skeleton plugin, I've been working on a method called skeleton.setInfo that updates the skeleton field in the piwigo_images table.

A performance question remains since this method would result in many API calls during large-scale validations. However, the initial tests I've conducted suggest that this should not cause any issues, given how optimized Piwigo's core is today.

I am currently working on the Skeleton plugin to showcase new ways to validate extension fields in Batch Manager Unit Mode. An update should be available early next week. The idea behind the redesign is to give collaborators more freedom in how they implement new functionalities based on their needs. Moving away from the old POST request was necessary because now you can validate your changes one picture at a time, dynamically. For the Batch Manager Unit Mode, the idea is for an extension to inject its template and functions directly into the page. When validating a picture, the core calls each extension's JavaScript functions named `batchManagerSave_[pluginID]` , which then call the assigned API method. For example, in the Skeleton plugin, I've been working on a method called `skeleton.setInfo` that updates the skeleton field in the `piwigo_images` table. A performance question remains since this method would result in many API calls during large-scale validations. However, the initial tests I've conducted suggest that this should not cause any issues, given how optimized Piwigo's core is today. <!-- github-comment-id:2322299495 -->
adam commented 2026-10-05 00:05:46 +02:00
Author
Owner
Copy link
Copy source

Does that mean if I have OSM, PhotoSphere and Gvideo plugins enabled, it would make 4 requests by image ?

That's really not ideal, Piwigo itself might be optimized, but you potentially put a big load on the SQL server.

Another possibility (after the two I gave earlier, whose have the same "problem") is a trigger_change acting on the $update variable, than way any plugin can hook just before the SQL update is performed.

Anyway, looking forward for Pwg 15 :)

Does that mean if I have OSM, PhotoSphere and Gvideo plugins enabled, it would make 4 requests by image ? That's really not ideal, Piwigo itself might be optimized, but you potentially put a big load on the SQL server. Another possibility (after the two I gave earlier, whose have the same "problem") is a trigger_change acting on the $update variable, than way any plugin can hook just before the SQL update is performed. --- Anyway, looking forward for Pwg 15 :) <!-- github-comment-id:2323491875 -->
adam commented 2026-10-05 00:05:47 +02:00
Author
Owner
Copy link
Copy source

Having successive SQL requests will not cause performance issues. We've tested both our lower end and high performance servers and none of them ever exceeded 1ms per request (except low end on wake up requests only) with databases of up to five hundred thousand pictures.

Bigger CPU : 

MariaDB [base_vniiqsbbd4]> update images set author='test' where id=575026;
Query OK, 1 row affected (0.000 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [base_vniiqsbbd4]> update images set author=null where id=575026;
Query OK, 1 row affected (0.000 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [base_vniiqsbbd4]> update images set comment='test desc' where id=575026;
Query OK, 1 row affected (0.000 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [base_vniiqsbbd4]> update images set comment=null where id=575026;
Query OK, 1 row affected (0.000 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Smaller CPU : 

MariaDB [base_3tnbp3308p]> update images set comment='test desc' where id=336393;
Query OK, 1 row affected (0.016 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [base_3tnbp3308p]> update images set comment=null where id=336393;
Query OK, 1 row affected (0.000 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [base_3tnbp3308p]> update images set comment='test desc' where id=336393;
Query OK, 1 row affected (0.001 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [base_3tnbp3308p]> update images set comment=null where id=336393;
Query OK, 1 row affected (0.001 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Although, the real performance issue might be the multiple HTTP requests made by the Ajax calls, even if we know that the core can handle a lot of requests, it's indeed still far from optimal. We've decided that we'd use the ws_invoke_allowed event handler (also used for the recently updated skeleton_ws_users_setInfo in skeleton) as a 2nd extensibility option for pwg.images.setInfo. It will allow extensions to register a field to the API call which will keep the amount of both HTTP and SQL requests as low as possible. We will keep the method I previously mentioned available since these options (either this event handler or the possible trigger you've mentionned) only covers plugins using the piwigo_images table.

Having successive SQL requests will not cause performance issues. We've tested both our lower end and high performance servers and none of them ever exceeded 1ms per request (except low end on wake up requests only) with databases of up to five hundred thousand pictures. ``` Bigger CPU : MariaDB [base_vniiqsbbd4]> update images set author='test' where id=575026; Query OK, 1 row affected (0.000 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [base_vniiqsbbd4]> update images set author=null where id=575026; Query OK, 1 row affected (0.000 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [base_vniiqsbbd4]> update images set comment='test desc' where id=575026; Query OK, 1 row affected (0.000 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [base_vniiqsbbd4]> update images set comment=null where id=575026; Query OK, 1 row affected (0.000 sec) Rows matched: 1 Changed: 1 Warnings: 0 Smaller CPU : MariaDB [base_3tnbp3308p]> update images set comment='test desc' where id=336393; Query OK, 1 row affected (0.016 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [base_3tnbp3308p]> update images set comment=null where id=336393; Query OK, 1 row affected (0.000 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [base_3tnbp3308p]> update images set comment='test desc' where id=336393; Query OK, 1 row affected (0.001 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [base_3tnbp3308p]> update images set comment=null where id=336393; Query OK, 1 row affected (0.001 sec) Rows matched: 1 Changed: 1 Warnings: 0 ``` Although, the real performance issue might be the multiple HTTP requests made by the Ajax calls, even if we know that the core can handle a lot of requests, it's indeed still far from optimal. We've decided that we'd use the `ws_invoke_allowed` event handler (also used for the recently updated `skeleton_ws_users_setInfo` in skeleton) as a 2nd extensibility option for `pwg.images.setInfo`. It will allow extensions to register a field to the API call which will keep the amount of both HTTP and SQL requests as low as possible. We will keep the method I previously mentioned available since these options (either this event handler or the possible trigger you've mentionned) only covers plugins using the `piwigo_images` table. <!-- github-comment-id:2324489438 -->
adam commented 2026-10-05 00:05:47 +02:00
Author
Owner
Copy link
Copy source

Just to give an actual example of use of ws_invoke_allowed, in plugin AddUsersNotes:

add_event_handler('ws_invoke_allowed', 'usernotes_ws_users_setInfo', EVENT_HANDLER_PRIORITY_NEUTRAL, 3);
function usernotes_ws_users_setInfo($res, $methodName, $params)
{
  if ($methodName != 'pwg.users.setInfo')
  {
    return $res;
  }      
  if (!isset($_POST['usernotes']))
  {
    return $res;
  }
  if (count($params['user_id']) == 0)
  {
    return $res;
  }
  
  $updates = array();
  
  foreach ($params['user_id'] as $user_id)
  {
    $updates[] = array(
      'user_id' => $user_id,
      'usernotes' => $_POST['usernotes'],
    );
  }

  if (count($updates) > 0)
  {
    mass_updates(
      USER_INFOS_TABLE, 
      array(
        'primary' => array('user_id'),
        'update'  => array('usernotes') 
      ),
      $updates
    );
  }
  return $res; 
}

You can do pretty much anything in here. Working on USER_INFOS_TABLE but not only. Plugin Prepaid Credits also works with ws_invoke_allowed:

add_event_handler('ws_invoke_allowed', 'ppcredits_ws_users_setInfo', EVENT_HANDLER_PRIORITY_NEUTRAL, 3);
function ppcredits_ws_users_setInfo($res, $methodName, $params)
{
  check_input_parameter('add_credits', $_POST, false, PATTERN_ID);
  check_input_parameter('remove_credits', $_POST, false, PATTERN_ID);
 
  if ($methodName != 'pwg.users.setInfo')
  {
    return $res;
  }

  if (count($params['user_id']) == 0)
  {
    return $res;
  }

  if (isset($_POST['add_credits']) or isset($_POST['remove_credits']))
  {
    $query = '
SELECT
    `user_id`,
    `ppcredits`
  FROM '.USER_INFOS_TABLE.'
  WHERE `user_id` IN ('.implode(',', $params['user_id']).')
;';
    $credits_of_user = query2array($query, 'user_id', 'ppcredits');
  }

  if (isset($_POST['add_credits']))
  {
    $query = '
UPDATE '.USER_INFOS_TABLE.'
  SET ppcredits = ppcredits + '.$_POST['add_credits'].'
  WHERE user_id IN ('.implode(',', $params['user_id']).')
;';
    pwg_query($query);

    foreach ($params['user_id'] as $user_id)
    {
      pwg_activity(
        'user',
        $user_id,
        'add_credits',
        array(
          'add_credits' => (int)$_POST['add_credits'],
          'ppcredits' => $credits_of_user[$user_id] + $_POST['add_credits'],
        )
      );
    }
  } 
  // [...]
  return $res;
}
Just to give an actual example of use of `ws_invoke_allowed`, in plugin AddUsersNotes: ``` add_event_handler('ws_invoke_allowed', 'usernotes_ws_users_setInfo', EVENT_HANDLER_PRIORITY_NEUTRAL, 3); function usernotes_ws_users_setInfo($res, $methodName, $params) { if ($methodName != 'pwg.users.setInfo') { return $res; } if (!isset($_POST['usernotes'])) { return $res; } if (count($params['user_id']) == 0) { return $res; } $updates = array(); foreach ($params['user_id'] as $user_id) { $updates[] = array( 'user_id' => $user_id, 'usernotes' => $_POST['usernotes'], ); } if (count($updates) > 0) { mass_updates( USER_INFOS_TABLE, array( 'primary' => array('user_id'), 'update' => array('usernotes') ), $updates ); } return $res; } ``` You can do pretty much anything in here. Working on `USER_INFOS_TABLE` but not only. Plugin Prepaid Credits also works with `ws_invoke_allowed`: ``` add_event_handler('ws_invoke_allowed', 'ppcredits_ws_users_setInfo', EVENT_HANDLER_PRIORITY_NEUTRAL, 3); function ppcredits_ws_users_setInfo($res, $methodName, $params) { check_input_parameter('add_credits', $_POST, false, PATTERN_ID); check_input_parameter('remove_credits', $_POST, false, PATTERN_ID); if ($methodName != 'pwg.users.setInfo') { return $res; } if (count($params['user_id']) == 0) { return $res; } if (isset($_POST['add_credits']) or isset($_POST['remove_credits'])) { $query = ' SELECT `user_id`, `ppcredits` FROM '.USER_INFOS_TABLE.' WHERE `user_id` IN ('.implode(',', $params['user_id']).') ;'; $credits_of_user = query2array($query, 'user_id', 'ppcredits'); } if (isset($_POST['add_credits'])) { $query = ' UPDATE '.USER_INFOS_TABLE.' SET ppcredits = ppcredits + '.$_POST['add_credits'].' WHERE user_id IN ('.implode(',', $params['user_id']).') ;'; pwg_query($query); foreach ($params['user_id'] as $user_id) { pwg_activity( 'user', $user_id, 'add_credits', array( 'add_credits' => (int)$_POST['add_credits'], 'ppcredits' => $credits_of_user[$user_id] + $_POST['add_credits'], ) ); } } // [...] return $res; } ``` <!-- github-comment-id:2324809341 -->
adam commented 2026-10-05 00:05:48 +02:00
Author
Owner
Copy link
Copy source

In the end, the most complicated is not to deal with extra parameters sent during the call to pwg.images.setInfo but to be able to add the extra parameters to the API call in javascript. In my opinion, this is the main problem we should focus on if we want to make a page like Batch Manager Unit Mode extensible (or User Manager, exact same situation)

In the end, the most complicated is not to deal with extra parameters sent during the call to `pwg.images.setInfo` but to be able to add the extra parameters to the API call in javascript. In my opinion, this is the main problem we should focus on if we want to make a page like Batch Manager Unit Mode extensible (or User Manager, exact same situation) <!-- github-comment-id:2325256300 -->
adam commented 2026-10-05 00:05:49 +02:00
Author
Owner
Copy link
Copy source

As seen in previous comments, you can already interact with existing API methods. The second concern was the extensibility of the batch manager unit mode so that, for example, when a user saves changes, it also takes fields added by plugins (this has been added in Piwigo 15).

As seen in previous comments, you can already interact with existing API methods. The second concern was the extensibility of the batch manager unit mode so that, for example, when a user saves changes, it also takes fields added by plugins (this has been added in Piwigo 15). <!-- github-comment-id:3052666927 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#584