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

Batch manager cannot generate derivatives ("Generate multiple size images") when upload_dir starts with "../../" #1025

New Issue
Open
opened 2026-10-05 00:28:54 +02:00 by adam · 2 comments
adam commented 2026-10-05 00:28:54 +02:00
Owner
Copy link
Copy source

EXECUTIVE SUMMARY

(detailed repro steps below)

When upload_dir is set to something that is outside of the piwigo root directory's parent (that is, when the path starts with "../../something"):

  • Thumbnails fail to show in the upload Web Form right after import because it's URL is faulty, it's missing "i.php?/.." at the beginning
  • Batch generation of derivatives fails for the same reason
  • Derivatives ARE generated for thumbnails displayed in the Batch Manager, as well as when viewing the gallery's frontend. However, they are generated in the wrong place (in _data/something rather than _data/i/something)

NOTE: If you set upload_dir to a directory just outside of the piwigo root, i.e. "../some_folder", then it all works fine (image URLs are always good, derivatives are always created properly, and under _data/i). It's only when you go one (or presumably more) level higher (../../some_folder) that trouble arises. Note that the same happens if you have subfolders, like "../../some/folder" (that was my original scenario).

SOME INVESTIGATION

(more details on the faulty URLs in the repro steps below)

The URL issue comes from using embellish_url() in the get_url() functions of class DerivativeImage, in derivative.inc.php. embellish_url() "simplifies" the URL when it contains "..", so "something/.." will disappear. In our case, "i.php/.." is removed from the URL, and makes it invalid. I'm new to this codebase and far from a PHP expert, and I don't know whether embellish_url() is really called just for URL cosmetic purposes here and can just be removed, or if that would cause other issues.

I haven't yet looked at why, when images do get generated (thumbnails in the Batch Manager, everything in the frontend), they end up in the wrong place, i.e. _data/something rather than _data/i/something.

DETAILED REPRO STEPS:

  1. Install Piwigo 2.10.2. Here's my setup:

    • English (US) (but language is unimportant here)
    • On Godaddy shared hosting, Cent OS / 7.4.2 / MySQL 5.6.47-cll-lve / ImageMagick 6.9.4-10
    • HTTP or HTTPS, no difference for this issue (unlike issue #1128)

  2. Create file local/config/config.inc.php with the following contents (or use the LocalFiles Editor plug-in, which is installed but disabled by default). I'm including comments from the default config file as a reference:

<?php
  // where should the API/UploadForm add photos? This path must be relative to
  // the Piwigo installation directory (but can be outside, as long as it's
  // reachable from your webserver).
  $conf['upload_dir'] = '../../outside_piwigo_parent_dir';
?>

  1. Create one album

  2. Add one photo to the album via the Web Form (drag and drop or browse, no difference for this issue). Note: While investigating, at one point after changing upload_dir the album page just displayed a message saying I had to manually create that directory - only got that once, not sure in which case it happens, but if you do see that message, just to ahead and create the directory.
    BUG 1: Once upload is done, normally you see thumbnails of the imported photos at the bottom of the Web Form page - in this case, you get a "image not found" icon instead.

    • Browser console output with the faulty thumbnail link: 20200507053339-6ee3c2e0-sq.jpg:1 GET http://myserver.com/outside_piwigo_parent_dir/2020/05/07/20200507053339-6ee3c2e0-sq.jpg 404 (Not Found)
    • Notice that it's NOT a link to "i.php" with some arguments (which is what you normally get when things work, i.e. when upload_dir is not set to a directory at least 2 levels up)
    • If you go and look at the ../../outside_piwigo_parent_dir directory, you'll see that the photo has been imported properly with subfolders for today's date. And if you look at the ./upload directory (the default), it's empty, as expected.

  3. Once the photo is uploaded, click "Manage this set of 1 photos" (or somehow go to the batch manager and get that photo listed). Notice that here, the thumbnail is properly displayed in the Batch Manager. If you look at the ./_data/outside_piwigo_parent_dir directory, you'll see that the thumbnail derivative has been generated properly (ends with -th.jpg). However:
    BUG 2: Although the derivative has been generated, the path is wrong: With the default upload_dir, the path is ./_data/i/upload, so presumably in this case it should be ./_data/i/outside_piwigo_parent_dir, not ./_data/outside_piwigo_parent_dir.

  4. Check the checkbox at the top-left of the photo thumbnail

  5. In the Action dropdown, select "Generate multiple size images"

  6. Check "XXS - Tiny"

  7. Click "Apply Action", wait until processing is finished
    BUG 3: You get a "1 photos can not be regenerated" error message. Indeed, if you look at ./_data/outside_piwigo_parent_dir directory, you still only have the thumbnail, not the XXS version.

    • Browser console output: VM352 jquery.min.js:5 GET http://myserver.com/outside_piwigo_parent_dir/2020/05/07/20200507053339-6ee3c2e0-2s.jpg&b=1588855237&ajaxload=true 404 (Not Found)
    • Again, this is not a "i.php" call

  8. Browse to the gallery's frontend, go into the album, then to the photo you just imported. Try different photo sizes.

    • You'll notice that it all works (except "Original", because in this case the original is not in a path that's within the website's root - but that's a different bug)
    • No browser console error
    • Links for the thumbnail/photos look like this: http://myserver.com/i.php?/../outside_piwigo_parent_dir/2020/05/07/20200507053339-6ee3c2e0-xs.jpg
    • Notice the "i.php?/..", which was missing from the URLs earlier in BUG 1 and BUG 2 above.

RELATED

Related, but different issues:

  • #1128 (that's an HTTPS vs. HTTP issue)
  • #1003 (Imagick exception)
  • #220 (another HTTPS issue)
## EXECUTIVE SUMMARY (detailed repro steps below) When `upload_dir` is set to something that is outside of the piwigo root directory's _parent_ (that is, when the path starts with "../../something"): - **Thumbnails fail to show in the upload Web Form** right after import because it's URL is faulty, it's missing "i.php?/.." at the beginning - **Batch generation of derivatives fails** for the same reason - Derivatives ARE generated for thumbnails displayed in the Batch Manager, as well as when viewing the gallery's frontend. However, **they are generated in the wrong place** (in _data/something rather than _data/i/something) NOTE: If you set upload_dir to a directory _just outside_ of the piwigo root, i.e. "../some_folder", then it all works fine (image URLs are always good, derivatives are always created properly, and under _data/i). It's only when you go one (or presumably more) level higher (../../some_folder) that trouble arises. Note that the same happens if you have subfolders, like "../../some/folder" (that was my original scenario). ### SOME INVESTIGATION (more details on the faulty URLs in the repro steps below) The URL issue comes from using `embellish_url()` in the `get_url()` functions of class `DerivativeImage`, in `derivative.inc.php`. `embellish_url()` "simplifies" the URL when it contains "..", so "something/.." will disappear. In our case, "i.php/.." is removed from the URL, and makes it invalid. I'm new to this codebase and far from a PHP expert, and I don't know whether `embellish_url()` is really called just for URL cosmetic purposes here and can just be removed, or if that would cause other issues. I haven't yet looked at why, when images do get generated (thumbnails in the Batch Manager, everything in the frontend), they end up in the wrong place, i.e. `_data/something` rather than `_data/i/something`. ## DETAILED REPRO STEPS: 1) **Install Piwigo 2.10.2**. Here's my setup: - English (US) (but language is unimportant here) - On Godaddy shared hosting, Cent OS / 7.4.2 / MySQL 5.6.47-cll-lve / ImageMagick 6.9.4-10 - HTTP or HTTPS, no difference for this issue (unlike issue #1128) 2) **Create file `local/config/config.inc.php` with the following contents** (or use the `LocalFiles Editor` plug-in, which is installed but disabled by default). I'm including comments from the default config file as a reference: ``` <?php // where should the API/UploadForm add photos? This path must be relative to // the Piwigo installation directory (but can be outside, as long as it's // reachable from your webserver). $conf['upload_dir'] = '../../outside_piwigo_parent_dir'; ?> ``` 3) **Create one album** 4) **Add one photo to the album via the Web Form** (drag and drop or browse, no difference for this issue). Note: While investigating, at one point after changing upload_dir the album page just displayed a message saying I had to manually create that directory - only got that once, not sure in which case it happens, but if you do see that message, just to ahead and create the directory. **BUG 1**: Once upload is done, normally you see thumbnails of the imported photos at the bottom of the Web Form page - in this case, you get a "image not found" icon instead. - Browser console output with the faulty thumbnail link: `20200507053339-6ee3c2e0-sq.jpg:1 GET http://myserver.com/outside_piwigo_parent_dir/2020/05/07/20200507053339-6ee3c2e0-sq.jpg 404 (Not Found)` - Notice that it's NOT a link to "i.php" with some arguments (which is what you normally get when things work, i.e. when upload_dir is not set to a directory at least 2 levels up) - If you go and look at the `../../outside_piwigo_parent_dir` directory, you'll see that the photo has been imported properly with subfolders for today's date. And if you look at the `./upload` directory (the default), it's empty, as expected. 5) Once the photo is uploaded, **click "Manage this set of 1 photos"** (or somehow go to the batch manager and get that photo listed). Notice that here, the thumbnail is properly displayed in the Batch Manager. If you look at the `./_data/outside_piwigo_parent_dir` directory, you'll see that the thumbnail derivative has been generated properly (ends with -th.jpg). However: **BUG 2**: Although the derivative has been generated, the path is wrong: With the default upload_dir, the path is `./_data/i/upload`, so presumably in this case it should be `./_data/i/outside_piwigo_parent_dir`, not `./_data/outside_piwigo_parent_dir`. 6) **Check the checkbox at the top-left of the photo thumbnail** 7) In the Action dropdown, **select "Generate multiple size images"** 8) **Check "XXS - Tiny"** 9) **Click "Apply Action", wait** until processing is finished **BUG 3**: You get a "1 photos can not be regenerated" error message. Indeed, if you look at `./_data/outside_piwigo_parent_dir` directory, you still only have the thumbnail, not the XXS version. - Browser console output: `VM352 jquery.min.js:5 GET http://myserver.com/outside_piwigo_parent_dir/2020/05/07/20200507053339-6ee3c2e0-2s.jpg&b=1588855237&ajaxload=true 404 (Not Found)` - Again, this is not a "i.php" call 10) **Browse to the gallery's frontend, go into the album, then to the photo you just imported. Try different photo sizes**. - You'll notice that it all works (except "Original", because in this case the original is not in a path that's within the website's root - but that's a different bug) - No browser console error - Links for the thumbnail/photos look like this: `http://myserver.com/i.php?/../outside_piwigo_parent_dir/2020/05/07/20200507053339-6ee3c2e0-xs.jpg` - Notice the "i.php?/..", which was missing from the URLs earlier in BUG 1 and BUG 2 above. ## RELATED Related, but different issues: - #1128 (that's an HTTPS vs. HTTP issue) - #1003 (Imagick exception) - #220 (another HTTPS issue) <!-- github-sync-id:614220325 -->
adam commented 2026-10-05 00:28:55 +02:00
Author
Owner
Copy link
Copy source

Why is there a need to get the absolute URL or protocol? Why not just use relative URL's everywhere? This would ensure the most portability and resolve all these infrastructure/environment compatibility issues.

Why is there a need to get the absolute URL or protocol? Why not just use relative URL's everywhere? This would ensure the most portability and resolve all these infrastructure/environment compatibility issues. <!-- github-comment-id:626230908 -->
adam commented 2026-10-05 00:28:56 +02:00
Author
Owner
Copy link
Copy source

I can only second this. I needed to patch the code while running piwigo inside docker on port 8080 with Caddy in front as reverse proxy for SSL.
Piwigo should not necessarily know at what domain it's hosted and use relative URLs.

I can only second this. I needed to patch the code while running piwigo inside docker on port 8080 with Caddy in front as reverse proxy for SSL. Piwigo should not necessarily know at what domain it's hosted and use relative URLs. <!-- github-comment-id:667708123 -->
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#1025