I’m trying to create my first small Kirby plugin, but I’m running into a problem loading assets on the frontend. I read (and thought I understood) the handling of plugin assets. However, it’s still not working.
The asset is located on the server at site/plugins/pluginname/assets/js/myscript.js
So the url to include in the header should be media/plugins/pluginauthor/pluginname/js/myscript.js and I included it via <?php echo(js(['media/plugins/pluginauthor/pluginname/js/myscript.js', '@auto'])); ?>
Now when I load the page from the remote webserver, the request for the mentioned asset returns a 403 - forbidden. File permissions for this asset on the remote server are the same as as for standard (non-plugin) assets. Standard assets are being loaded correctly, plugin assets not.
When loading the page locally with the php built-in server (php -S …) the asset is loaded correctly.
So I assume it has to do with the .htaccess file which kicks in on the remote webserver. However, I’m using the default .htaccess from Kirby plainkit and the media folder is not rewritten there or anything. The only line which might be involved is this RewriteRule ^site/(.*) index.php [L]
However, this shouldn’t have an effect on the file which is accessible by the url media/… and not site/…
Thanks for the suggestion, but no, this doesn’t change things. I’m also referencing other assets from assets/js/… which are working fine (I just removed them for this ticket for brevity). I tried using an absolute path nevertheless, but without success.
It’s working now, but I needed to edit the symlink manually. It was pointing to /html/snippets/site/plugins/pluginname/assets/js/myscript.js
which is not the complete absolute path.
Changing the symlink to be pointing to /home/www/pxxxxxx/html/snippets/site/plugins/pluginname/assets/js/myscript.js
did the trick for me.
Is this something, which could be fixed in the Kirby core, where the absolute path for the symlink is determined? $_SERVER[‘DOCUMENT_ROOT’] seems to return the correct directory.
Thanks, I saw this thread, but in my case it doesn’t seem to be an issue of the hosting provider.
Kirby really is using PHP’s symlink(), but still this function must be fed with a target and a link.
My question is whether these parameters could/should be adjusted.
I am so sorry for causing confusion… The snippets folder mentioned above has absolutely nothing to do with the Kirby snippets folder! I’m talking about an internal test/demo site, where I want to store some Kirby snippets in order to be able to look them up there and combine them for future projects. This demo site lives in a domain, which I call snippets.domain.tld and that’s why I put the files in a subfolder called snippets.
So the output I posted might as well be /html/demo/content/1_home
The web root is /html/demo/
Maybe it’s better to discuss on this basis in order not to confuse my own snippets folder with the Kirby snippets folder.
So my original question remains: Might my absolute path problem be solvable in the Kirby core?
So as I understand you, your setting up some common code (“snippets” in this case) to share among several other projects from a central point?
Might i suggest using a plugin? A kirby plugin doesnt have to be a plugin, it can just just contain snippets, or blueprints, or templates, or all 3. You can store this in a private Git and install it into kirby with submodules, allowing easy updating. Just a thought.
This seems to be related to my hosting company after all. The realpath() function, which Kirby is using seems to return some unexpected, i.e. truncated, path, which leads to the symlinks not being followed.
So I am fixing the problem with a custom script right now, which adjusts all symlinks from the plugins folder to have the right (absolute) links. Basically, I’m just adding a prefix, if doesn’t exist, yet.
My hosting company is using symlinks themselves in the directory setup, so I guess this is related to the problem, but I have no idea whether there is a way to mitigate this problem in the Kirby code.
The only chance might be using _SERVER[‘DOCUMENT_ROOT’] instead of realpath() in Kirby. This would solve the problem for me, but I don't know whether _SERVER[‘DOCUMENT_ROOT’] is set consistently correct or whether this might fail for other setups.
@texnixe, I guess realpath() doesn’t return an empty string in your setup?
FWIW, I had this issue locally. I had changed the name of the website in the directory, but the symlink created by Kirby had stayed the same. Once I deleted the /media/plugins directory, and reloaded the site, the symlink rebuilt with the new, correct path and the plugin asset was found again.