You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi Felix,
the pagination (at least) of the search for components does not work properly on installations, which where the webroot is not "/". This is caused by a leading slash in the URL of the pagination buttons ("/list.php" instead of only "list.php")
I'll propose a bug fix by merge request.
The text was updated successfully, but these errors were encountered:
Hi Marco, the URL is generated using $_SERVER["SCRIPT_NAME"] (lib_url.php:64). Of course it would be possible to clean this output, but as far as I remember the script path should be fine, even in subfolders. Other options may work as well, of course.
Hi Felix,
in my commit 13ed133 I moved the stripping to lib_urls.php as suggested. I crosschecked my URL rewriting done by NGinx which acts as reverse proxy to my docker containers. This seems to be fine.
From my further tests it seems that $_SERVER["SCRIPT_NAME"] always contains the trailing slash. In classic setups and OE instances in sub locations this would not make any trouble I think. But with proxies where the URI in the app differs from the web URI it seems to be better to use relative path's.
Hi Felix,
the pagination (at least) of the search for components does not work properly on installations, which where the webroot is not "/". This is caused by a leading slash in the URL of the pagination buttons ("
/list.php
" instead of only "list.php
")I'll propose a bug fix by merge request.
The text was updated successfully, but these errors were encountered: