Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in pagination #2

Open
mpibpc-mroose opened this issue Feb 6, 2019 · 3 comments
Open

Bug in pagination #2

mpibpc-mroose opened this issue Feb 6, 2019 · 3 comments

Comments

@mpibpc-mroose
Copy link
Contributor

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")

image

I'll propose a bug fix by merge request.

@mpibpc-mroose
Copy link
Contributor Author

is part of my merge request as commit
21ea8b2

@rudolphi
Copy link
Owner

rudolphi commented Feb 6, 2019

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.

@mpibpc-mroose
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants