The idea is to make Piwigo ready for "single photo, multiple formats". For example, you have img1234.jpg and many formats : img1234.cr2 (raw Canon file), img1234.cmyk.jpg (for print purpose)
The idea is to make Piwigo ready for "single photo, multiple formats". For example, you have img1234.jpg and many formats : img1234.cr2 (raw Canon file), img1234.cmyk.jpg (for print purpose)
Already a bit discussed on http://piwigo.org/forum/viewtopic.php?id=26087
<!-- github-sync-id:119727245 -->
@mistic100 @modus75 @flop25 @ddtddt would you like to review my code before I merge into master? (let's say I'll merge in 3 days unless you find some problems)
@mistic100 @modus75 @flop25 @ddtddt would you like to review my code before I merge into master? (let's say I'll merge in 3 days unless you find some problems)
<!-- github-comment-id:165449954 -->
@plegall I don't like the image_format table. As far as I see, the primary key is useless and is obviusly missing at least a key on image_id ...
@plegall I don't like the image_format table. As far as I see, the primary key is useless and is obviusly missing at least a key on image_id ...
<!-- github-comment-id:165472833 -->
Another small detail. Random string is not required in picture.php. It's in fact easier to "cancel " browser cache from action.php (there is some specific code in action to handle cache)
Another small detail. Random string is not required in picture.php. It's in fact easier to "cancel " browser cache from action.php (there is some specific code in action to handle cache)
<!-- github-comment-id:165482647 -->
piwigo_image_format.format_id is not useless: it is simpler for format deletion and each time I create a table without such primary key, I often have to add it afterwards. This primary key doesn't cost anything.
OK for the index on image_id, I will add it.
OK for random string, I have to test that on action.php.
piwigo_image_format.format_id is not useless: it is simpler for format deletion and each time I create a table without such primary key, I often have to add it afterwards. This primary key doesn't cost anything.
OK for the index on image_id, I will add it.
OK for random string, I have to test that on action.php.
<!-- github-comment-id:165484270 -->
Furthermore, about the format_id : it is useful in history table, where it would be a bad idea to have a format_ext column (varchar)...
@modus75 you say you don't like the image_format table, but what would you use instead? I had 2 other solutions:
a serialized array in a column images.formats, but it's not efficient
not database store at all, only detection "on the fly" on picture.php, but I like to have the filesize in database to be able to use statistics for example.
In action.php, I see the lines you gave to handle the cache handling. I have to give a try. Considering I want no cache on formats, do you recommend to enable "Expires" in http headers and set a max_age=0 if ($_GET['part'] == 'f') ?
Furthermore, about the format_id : it is useful in history table, where it would be a bad idea to have a format_ext column (varchar)...
@modus75 you say you don't like the image_format table, but what would you use instead? I had 2 other solutions:
1) a serialized array in a column images.formats, but it's not efficient
2) not database store at all, only detection "on the fly" on picture.php, but I like to have the filesize in database to be able to use statistics for example.
In action.php, I see the lines you gave to handle the cache handling. I have to give a try. Considering I want no cache on formats, do you recommend to enable "Expires" in http headers and set a max_age=0 if ($_GET['part'] == 'f') ?
<!-- github-comment-id:165606955 -->
Ok for format id because of the history table.
No need for anything special in action. Just not send the specific headers. This is because php automatically sends the headers when starting a new session.
Ok for format id because of the history table.
No need for anything special in action. Just not send the specific headers. This is because php automatically sends the headers when starting a new session.
<!-- github-comment-id:165680156 -->
One problem is that when action.php is broken (PHP error) then even if you fix it, you have to force refresh. Which is "complicated", compared to a normal page. Maybe it's only a dev issue and I shouldn't care, but adding a random string prevents this from happening.
One problem is that when action.php is broken (PHP error) then even if you fix it, you have to force refresh. Which is "complicated", compared to a normal page. Maybe it's only a dev issue and I shouldn't care, but adding a random string prevents this from happening.
<!-- github-comment-id:165702254 -->
OK, I tried to remove the random string. If I change the file to download, and simply clic once again on the download link, I still get the old version of the file :-/
OK, I tried to remove the random string. If I change the file to download, and simply clic once again on the download link, I still get the old version of the file :-/
<!-- github-comment-id:166122095 -->
Now if I remove the block if (isset( $_SERVER['HTTP_IF_MODIFIED_SINCE'] ) ) then it's fine, I don't use the browser cache. So what do you think of either removing this block or adding a condition:
if ('f' != $_GET['part'] and isset( $_SERVER['HTTP_IF_MODIFIED_SINCE'] ) )
Now if I remove the block if (isset( $_SERVER['HTTP_IF_MODIFIED_SINCE'] ) ) then it's fine, I don't use the browser cache. So what do you think of either removing this block or adding a condition:
if ('f' != $_GET['part'] and isset( $_SERVER['HTTP_IF_MODIFIED_SINCE'] ) )
<!-- github-comment-id:166124210 -->
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.
The idea is to make Piwigo ready for "single photo, multiple formats". For example, you have img1234.jpg and many formats : img1234.cr2 (raw Canon file), img1234.cmyk.jpg (for print purpose)
Already a bit discussed on http://piwigo.org/forum/viewtopic.php?id=26087
@mistic100 @modus75 @flop25 @ddtddt would you like to review my code before I merge into master? (let's say I'll merge in 3 days unless you find some problems)
@plegall I don't like the image_format table. As far as I see, the primary key is useless and is obviusly missing at least a key on image_id ...
Another small detail. Random string is not required in picture.php. It's in fact easier to "cancel " browser cache from action.php (there is some specific code in action to handle cache)
piwigo_image_format.format_id is not useless: it is simpler for format deletion and each time I create a table without such primary key, I often have to add it afterwards. This primary key doesn't cost anything.
OK for the index on image_id, I will add it.
OK for random string, I have to test that on action.php.
Furthermore, about the format_id : it is useful in history table, where it would be a bad idea to have a format_ext column (varchar)...
@modus75 you say you don't like the image_format table, but what would you use instead? I had 2 other solutions:
a serialized array in a column images.formats, but it's not efficient
not database store at all, only detection "on the fly" on picture.php, but I like to have the filesize in database to be able to use statistics for example.
In action.php, I see the lines you gave to handle the cache handling. I have to give a try. Considering I want no cache on formats, do you recommend to enable "Expires" in http headers and set a max_age=0 if ($_GET['part'] == 'f') ?
Ok for format id because of the history table.
No need for anything special in action. Just not send the specific headers. This is because php automatically sends the headers when starting a new session.
One problem is that when action.php is broken (PHP error) then even if you fix it, you have to force refresh. Which is "complicated", compared to a normal page. Maybe it's only a dev issue and I shouldn't care, but adding a random string prevents this from happening.
OK, I tried to remove the random string. If I change the file to download, and simply clic once again on the download link, I still get the old version of the file :-/
If I force reload, then I get the new version of the file. But this is not a solution for "normal" users.
Now if I remove the block if (isset( $_SERVER['HTTP_IF_MODIFIED_SINCE'] ) ) then it's fine, I don't use the browser cache. So what do you think of either removing this block or adding a condition:
if ('f' != $_GET['part'] and isset( $_SERVER['HTTP_IF_MODIFIED_SINCE'] ) )
Adding the if condition test was exactly what I had in mind.
I have merged the branch. I close this issue for a first step. Next step will be #389