I have an issue reported here
It’s clear that from the image the domain name is missing:
The code that make this is:
$url = u() . '/assets/plugins/kirby-panel-flags/icons/' . $filename . '.svg'
u() give the installation url, like:
(I know that I should probably use
kirby()->urls()->assets() for it in this case)
To be honest I don’t understand the issue.
http://localhost:5757 is a perfectly valid domain name. It just all depends on the setup.
I tested this a well without the port number on localhost, but the resulting url - while correct according to the docs - just doesn’t work, so I don’t think this is related to the port.
Edit: When I uncommented these two rules in .htaccess, it worked:
# block all files in the site folder from being accessed directly
# except for requests to plugin assets files
RewriteRule ^assets/plugins/([a-zA-Z0-9\.\-_%=]+)/(.*)$ site/plugins/$1/assets/$2 [L,N]
RewriteCond $1 !^plugins/[a-zA-Z0-9\.\-_%=]+/assets/.*
If you change
$site->url(), you may get what you want or need.
I don’t know you webserver configuration, but on my “XAMPP on Windows server” and the respective live linux server this runs.
If you want to know why I can suggest this here, you can look at the “gear wheel” links at
HowTo: Working with contextual links to the panel, where I have used this.
@anon77445132: The problem is not that the generated URL is wrong. Therefore, unfortunately,
$site->url() does not solve the problem at all.
May be I am wrong, because it may be that I do not understand the core problem of @jenstornell, but I think, if he would change his code, he will get what he wants or needs.
I think, not every code part of Kirby needs to fit all wishes of all developers…, I feel certain, I can tell your Kirby team many points, I wish to run in another way, but that is different from this question.
Sometimes a developer can avoid some problems…
Well, just compare the following two screenshots:
As you will see, the generated URL to the image is perfectly alright:
Image 1: the two lines in .htaccess commented out:
Image 2: same story, the two lines in .htaccess uncommented:
As you can see, the URL has not changed from image 1 to image 2. So the URL is not the problem.
To answer the first question from
@jenstornell on this webpage:
I am quite sure, that
will answer with
if the website is installed in a directory called
my-domain.com and the
listens on port
@anon77445132: Have you tested this?
No, but I use this on my XAMPP dev system every day, e.g. an extended version of
Well, then please
do test it with the plugin, and you will see that it will not work.
I just tested this in Kirby 2.4.0 (without port):
In case it has not changed in Kirby 2.4.1 there is nothing wrong here. They output the same thing.
(Because my CLI does not work at the moment I use Kirby 2.4.0)
Now I tried it with the plugin and it did not work. The url I get is this:
I agree with
@texnixe that it is correct according to the docs. Maybe it’s time to add it as an issue to Github?
If we just leave the plugin aside for a moment, if you just take the resulting URL and copy it into the address bar of your browser, you get this:
If you change the two lines above in .htaccess, the result is this:
Yes, then it works for me too.
But this should be uncommented in the htaccess by default right? So we can use plugin assets without these kinds of problems?
Well, I guess, it happens because this line
RewriteRule ^site/(.*) index.php [L]
blocks all access to the
/site folder, so maybe it is not surprising that the route does not work.
Edit: As I said before, the problem is not caused by
u() or ports. If you use
panel()->site()->url() instead of
u() the result is the same.
I don’t know if it should be uncommented by default. It might suffice to mention it in the docs.
I added an issue about it:
It's because important parts are commented out from the htaccess:
#RewriteRule ^assets/plugins/([a-zA-Z0-9\.\-_%=]+)/(.*)$ site/plugins/$1/assets/$2 [L,N]
#RewriteCond $1 !^plugins/[a-zA-Z0-9\.\-_%=]+/assets/.*
More info here:
Docs about how plugin assets...