piwigo-export: update existing photos

[quovadit]

First very small step towards #11400

Currently it's not possible to update already existing photos using piwigo-export. The filename is randomized, and every export creates a new copy of the images.

With this PR, the filename in piwigo is the same as in darktable, and if the file already exists when exporting to piwigo, it will be updated instead of copied.

[Nilvus]

Good thing but would be good so to have a prompt to be sure we want to override existing images.

[quovadit]

Good thing but would be good so to have a prompt to be sure we want to override existing images.

good point, I added an option 'on conflict': overwrite/skip - analogous to 'file on disk'

[quovadit]

added 3rd option to only update metadata, without even re-uploading existing image

[quovadit]

Thanks for testing @TurboGit

Unfortunately I can't reproduce the error:

• select one image
• expand export module
• click login > 'authenticated'
• visible is set to: everyone
• click on 'album'
• chose 'create new album'
• set title to 'my new sub-album'
• click on 'parent album'
• chose one existing album
• on conflict is set to: overwrite
• click 'export'

Did I get something wrong?

[TurboGit]

Did I get something wrong?

No I did exactly that and I tried 3 times. I had to kill dt as it was locked somehow. I then reverted the PR and all was fine again as before. And note that I'm using regularly Piwigo and never got an issue. One point, are you using a self hosted Piwigo or an payed instance on piwigo.com? Maybe there is a different version...

[quovadit]

I'm using self-hosted piwigo, version 13 beta I will test with latest stable version 12.2 in the evening...

[quovadit]

just tested with a clean install of piwigo 12.2, no problem either, can't reproduce the described error... @TurboGit : do you have any hint what I could do to get the error?

[TurboGit]

I'll retest with traces activated to see if I can make sense of the issue on my side then.

[quovadit]

thanks for the detailled debugging, I'll try to fix it

[quovadit]

fixed requested changes: stored conflict_action in params, moved dt_image_cache_read_release

[quovadit]

@TurboGit : I'm really sorry, I fear I messed everything up once again :-(

I tried to fix your console errors, but it seams the push did go wrong

---

Additional info: the check if the file already exists does only work, if you set the following piwigo-config: $conf['uniqueness_mode'] = 'filename';

I added this info as tooltip

[TurboGit]

Additional info: the check if the file already exists does only work, if you set the following piwigo-config: $conf['uniqueness_mode'] = 'filename';

I'm very short on time, but do you think it is possible to enable the option in darktable if we are using a piwigo.com instance? Having an option that does not work is not a good idea.

[quovadit]

I did not know, that you can't use LocalFiles Editor on piwigo.com accounts I'll try to find a solution...

[TurboGit]

I did not know, that you can't use LocalFiles Editor on piwigo.com accounts

Maybe I can, I don't know what LocalFiles is BTW... I'm not confident about this as I suppose the site hosted at piwigo.com are probably shared on the same piwigo instance.

[quovadit]

I created a piwigo.com account, tried to edit LocalFiles, but it had no effect. And piwigo forum confirmed this: "critical features of LocalFilesEditor (where you can easily crash your account) are removed"

So I have to find an alternative without the need to change piwigo-config

[TurboGit]

@quovadit : Thanks, note that freeze is for the week-end if all goes well. So this may be for 4.0.1 or later.

[quovadit]

I now use a different piwigo-method so that no piwigo config change is needed anymore.

Performance should be no problem (0.074 - 0.081 seconds per check) [EDITED: 0.081 is correct]

Nevertheless I added a new default-entry 'on conflict: don't check' to skip the duplicate-check

I did not yet fix the upgrade-issue - DT_MODULE(1)

[quovadit]

I removed the conflict_action from existing typedef, as I don't think this change justifies a version bump to DT_MODULE(2)

@TurboGit : I'm finished now, if it's ok I would create a new clean PR without back and forth.

[TurboGit]

@quovadit : I think it is time to fix conflicts, rebase on top of master and try to integrate this for 4.2. TIA.

[quovadit]

@TurboGit : I rebased, hope it's ok now

[TurboGit]

@quovadit : Thanks, I'll test again soon.

[TurboGit]

@quovadit : Just a gentle ping to be sure it is still on your scope for 4.2. If not let me know and I'll remove the corresponding tag. TIA.

[quovadit]

@TurboGit : I fixed the issues, but I couldn't reproduce your issue with updating the author, works fine for me...

[TurboGit]

@quovadit : URGENT, this has introduced a regression that I just found out.

To reproduce:

1. create a duplicate
2. change the duplicate to be very different (say put it black and white)
3. export to piwigo with "overwrite mode"

See issue, two pictures are exported but they look the same.

[TurboGit]

Actually the reproducer is a bit more complex.

1. export one picture into album test
2. create a duplicate
3. change the duplicate to be very different (say put it black and white)
4. select the original image and the duplicate
5. select overwrite mode
6. export for same piwigo album

See that only a single image is in the album which correspond to the b&w duplicate.

[TurboGit]

@quovadit : Please see #13112

[quovadit]

@TurboGit : I will check it asap