Issue with u() and localhost port

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/.*

@jenstornell:

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!

@HeinerEF: 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.

@HeinerEF: Have you tested this?

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. :slight_smile:

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: