I have an issue reported here https://github.com/jenstornell/kirby-panel-flags/issues/1
It’s clear that from the image the domain name is missing:
http://localhost:5757/assets/plugins/kirby-panel-flags/icons/pt.svg
The code that make this is:
$url = u() . '/assets/plugins/kirby-panel-flags/icons/' . $filename . '.svg'
Shouldn’t u() give the installation url, like:
http://localhost:5757/my-domain.com
(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
to $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.
Good luck!
@anon77445132: The problem is not that the generated URL is wrong. Therefore, unfortunately, $site->url() does not solve the problem at all.
@texnixe:
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
$site->url()
will answer with
if the website is installed in a directory called my-domain.com and the localhost webserver listens on port 5757.
No, but I use this on my XAMPP dev system every day, e.g. an extended version of https://forum.getkirby.com/t/howto-working-with-contextual-links-to-the-panel/1566.
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):
echo $site->url();
echo u();
It gives:
http://localhost/kirby/2.4.0
http://localhost/kirby/2.4.0
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)
https://getkirby.com/docs/developer-guide/plugins/assets
Now I tried it with the plugin and it did not work. The url I get is this:
http://localhost/kirby/2.4.0/assets/plugins/kirby-panel-flags/icons/gb.svg
http://{domain}/assets/plugins/{pluginName}/{optionalSubfolder}/{filename}
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.
Alright!
I added an issue about it: