Closed kroesche closed 4 months ago
Sorry, for my slow response. Just put the following on the main README. Let me know if you are interested.
Important: I'm currently very busy in my job, so I don't have much time to support this project. It seems there is some interest in it on a regular basis, so I'd be happy to give admin access to another developer that wants to maintain/develop the project further. Please get in touch with me if you are interested.
I appreciate that you approved this but I only ever tested it on the files gallery. I would like to verify that it does not cause any problems for the remote galleries. That is why I have not merged this PR yet.
I appreciate that you approved this but I only ever tested it on the files gallery. I would like to verify that it does not cause any problems for the remote galleries. That is why I have not merged this PR yet.
Sure, no problem. Ideally, in this case, you can convert the PR to draft so it is clear it is not ready to be merged.
I am withdrawing this for now. There have been a lot of changes in the codebase since i made this PR and I want to spend some time to verify these changes do not cause any breakage. Also, I am now working on this as a branch in this repo, instead of my fork. The new branch is feature/filehash
. Once I have confidence in this set of changes I will make a new PR.
This is a partial solution to #117. I implemented this for the files gallery but not the other variants. This is for your consideration.
force_description_reuse
is added that if true, will reuse descriptions even if it appears the file has changed. this can be used in situations like mine where I want to preserve descriptions for photos where the mtime changed for some reason but the file contents are the sameI did limited testing with my own test case.
I tried running the unit tests. As far as I can tell they all passed but I am not sure I ran them all, or ran them correctly.