rvelices, I have added :

function delete_element_derivatives($ids)
{
  // todo
  if (!is_array($ids))
  {
    $ids = array($ids);
  }

  // for now I do a massive clear, to be removed once the function is
  // properly implemented
  clear_derivative_cache();
}

I let you improve this function :-)

rvelices wrote:

in file_path_for_type the only acceptable $type parameters should be 'original' and 'representative' (if the added element is not a picture)

Actually, function file_path_for_type becomes obsolete with Piwigo 2.4. The only functions using it needs to be rewritten or removed (ws_images_resizewebsize and ws_images_resizethumbnail)

plg wrote:

I'm implementing the "update file" algorithm and I'm searching the deleteDerivative function you had described me. I don't find it. Is it in the TODO list or did I miss it?

it's in the todolist you can put sth like
function delete_element_derivatives($infos)
{
  // todo
}
in admin functions.inc.php and call it ...

plg wrote:

Done for upload form and pwg.images.addSimple. Still under review for pwg.images.add.

You can still cleanup in functions_upload
'tn_ext' => 'jpg',

    if (isset($high_infos))
    {
      $insert['has_high'] = 'true';
      $insert['high_filesize'] = $high_infos['filesize'];
      $insert['high_width'] = $high_infos['width'];
      $insert['high_height'] = $high_infos['height'];
    }

in file_path_for_type the only acceptable $type parameters should be 'original' and 'representative' (if the added element is not a picture)

You have already thought about this, but I asked myself why we need to remove the Remote Sites : can you explain why we can't check if http://mysite/_data/mypicture-tn.jpeg exists and call the distant i.php?etc to generate it ? I'm sorry if it appears as a stupid question for you, I'm certainly missing something

plg wrote:

That doesn't sound enough for me if the visitor can still open _data/i/[path]-la.jpg : we also need .htacess into _data/i, don't you think?

My idea was not to protect _data/i - the webmaster could always allow only "small" resizes.
However this would work out of the box if you choose $conf['derivative_url_style']=2 (i.php) and if we finish the implementation i.php (look for // todo send pass-through )

plg wrote:

Have you already made some performance test on action.php used for all thumbnail/photo etc? (I haven't and I wonder if it needs a lot of CPU/memory on server side)

No tests done, but I would say - no CPU usage, rather heavy IO. Instead of apache using an optimized syscall for transferring data (checkout sendfile function), php reads the file and then outputs it (either quick if used as a php module or with extra IO as cgi/fcgi)

plg wrote:

What's your opinion about that? Do you think we can do something clean and more secure?

Not yet properly working with svn trunk but my target for securing originals will be a plugin that:
- adds .htacces in uploads/galleries deny from all
- implement two event handlers
    get_element_url - will return action.php?part=e&id=1&view instead of get_root_url().row[path]
    get_representative_url - will return action.php?part=r&id=1&view. instead of get_root_url().add_pwg_representative_inside(row[path])