With $conf['original_url_protection']="images" (or "all"); the Piwigo API pwg.images.getInfo returns in element_url the URL …action.php?id=6&part=e instead of …action.php?id=6&part=e.
I add a patch replacing & with & in the iOS but could this be fixed?
PS: Tested with Piwigo v2.9.2
With `$conf['original_url_protection']="images" (or "all");` the Piwigo API `pwg.images.getInfo` returns in `element_url` the URL `…action.php?id=6&part=e` instead of `…action.php?id=6&part=e`.
I add a patch replacing `&` with `&` in the iOS but could this be fixed?
PS: Tested with Piwigo v2.9.2
<!-- github-sync-id:265506302 -->
but I admit I don't remember why we used & instead of &. I need to make more tests to see if it's safe to make this change. function add_url_params is used quite everywhere (indirectly)
OK, I have also encountered the problem with theme Modus when trying to display the original size. This fixes the problem:
```
~/git/Piwigo[master|✚2⚑49] % git diff
diff --git a/include/functions_url.inc.php b/include/functions_url.inc.php
index 08fdbd5a9..0b6cb992a 100644
--- a/include/functions_url.inc.php
+++ b/include/functions_url.inc.php
@@ -100,7 +100,7 @@ function get_absolute_root_url($with_scheme=true)
* @param array params
* @return string
*/
-function add_url_params($url, $params, $arg_separator='&' )
+function add_url_params($url, $params, $arg_separator='&' )
{
if ( !empty($params) )
{
```
but I admit I don't remember why we used `&` instead of `&`. I need to make more tests to see if it's safe to make this change. function `add_url_params` is used quite everywhere (indirectly)
<!-- github-comment-id:4100566135 -->
Now I remember why: in HTML, we're supposed to write & in attributes (or anywhere else) to avoid confusion with the start of an HTML entity. Obviously modern web browsers don't really care and it works perfectly well by writing & instead.
I'm confused on what we should do to make things clean without breaking half of Piwigo urls (depending on the web browser or the third party app using the API)
Still working on finding a solution...
> I don't remember why we used `&` instead of `&`
Now I remember why: in HTML, we're supposed to write `&` in attributes (or anywhere else) to avoid confusion with the start of an HTML entity. Obviously modern web browsers don't really care and it works perfectly well by writing `&` instead.
I'm confused on what we should do to make things clean without breaking half of Piwigo urls (depending on the web browser or the third party app using the API)
Still working on finding a solution...
<!-- github-comment-id:4100732201 -->
Instead we only change the separator when we detect we're in the API.
We discussed with plg. This change is too simple and not compliant with html standards.
```php
-function add_url_params($url, $params, $arg_separator='&' )
+function add_url_params($url, $params, $arg_separator='&' )
```
Instead we only change the separator when we detect we're in the API.
<!-- github-comment-id:4109928344 -->
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.
With
$conf['original_url_protection']="images" (or "all");the Piwigo APIpwg.images.getInforeturns inelement_urlthe URL…action.php?id=6&part=einstead of…action.php?id=6&part=e.I add a patch replacing
&with&in the iOS but could this be fixed?PS: Tested with Piwigo v2.9.2
Still an issue after 8 years 🤨
OK, I have also encountered the problem with theme Modus when trying to display the original size. This fixes the problem:
but I admit I don't remember why we used
&instead of&. I need to make more tests to see if it's safe to make this change. functionadd_url_paramsis used quite everywhere (indirectly)Now I remember why: in HTML, we're supposed to write
&in attributes (or anywhere else) to avoid confusion with the start of an HTML entity. Obviously modern web browsers don't really care and it works perfectly well by writing&instead.I'm confused on what we should do to make things clean without breaking half of Piwigo urls (depending on the web browser or the third party app using the API)
Still working on finding a solution...
We discussed with plg. This change is too simple and not compliant with html standards.
Instead we only change the separator when we detect we're in the API.