Another screenshot where I echo the value of $page->url() on the about page:
Hint:
I would use another (new!) browser, e.g. a portable version.
[Added:]
The other /new browser would have no add-ins, no changes of the default entries, no cache etc.
On Windows I use a Portable App (Mozilla Firefox)
I don’t know what you mean. But I have tried it with Chrome also.
@texnixe i noticed another different behavior between our 2 test sites
visiting http://kirby.texnixe.io/panel blocks panel install as it should
visiting http://kirby.krypod.com/panel redirects to the install page, allowing me to create an account
once i crated an account i see the following URL in the panel dashboard:
Permissions
in my 2.5.0 install on server
/index.php
permissions are: 755
in a 2.4.2 install on server
/index.php
permissions are: 644
Have you made any changes in your config.php file, @max? Or why can you install the Panel?
My index.php has 755 as well. But I don’t think this is a permissions issue…nor a browser issue or a .htaccess issue.
did not make any changes to config.php
i’m not sure why i was able to do the panel install through the browser, while the site was running on the server
@anon77445132: Subpages wouldn’t even work if the .htaccess was ignored.
2 Likes
I uploaded the starterkit to a remote server. No absolute url:s there either:
So we now currently have a 5:4 score relative urls vs. absolute urls but no obvious reason why this is happening to some but not all of us 
No one has added c::set('url', '/') in their config to force relative URLs…
1 Like
No I have not touched the config file at all.
For my installations, I downloaded the starterkit as a zip from getkirby.com. But I guess the result would be the same if I would do the installation via Git or the Kirby cli?
Edit: I just tried installing the Starterkit via the Kirby Cli. The results where the same. Only relative url:s.
Yes, I also tested CLI, download and clone, all with the same result, I also tested all available PHP versions, I just can’t get any relative URLs unless I force them via config.
I looked at the Kirby repo, and there where a lot of commits regarding url handling. Hard to tell whether the issue is in one of these commits.
https://github.com/getkirby/kirby/commit/ac9f9a9d343dd92039d545a8592ca30a73957c77
https://github.com/getkirby/kirby/commit/ea5dfeb751f7042bc76fe9fcef3480d915b87fee
https://github.com/getkirby/kirby/commit/5077b88563bf3fdd2adc13310993d5e13502c972
https://github.com/getkirby/kirby/commit/ae98f9742073a2f490fe9cf891d0fd8afa17d55a
https://github.com/getkirby/kirby/commit/298a47610fd0a97c5faf663713023bdffd61e308
Yes, that’s what I saw as well and maybe it is related to this issue.
It seems like the problem is here.
https://github.com/getkirby/toolkit/commit/3834f9809e545f0d430059aa427de89d15001515
The old one evalutes to false and the updated method evaluates to true on a dev server of mine.
Therefore this one here will return / as the index url.
5 Likes
Good find! Seems like it could be the cause of this.
yep!
reverting that commit seems to correct the urls on my server
https://github.com/getkirby/toolkit/commit/3834f9809e545f0d430059aa427de89d15001515
Thanks for your help with debugging this bug.
As I wrote in the GitHub issue, we are definitely going to fix this in the very next release, which is going to be out in just a few weeks.
You can help us by verifying that reverting the mentioned commit solves the issue.
Reverting this commit fixed the problem. Thank you!
Whats about a development version (e.g. at https://github.com/getkirby/kirby/tree/develop for the Kirby Core submodule) on a daily basis?
That may be good for the further testing…