Obscure blueprint bug

Kirby 3 Solved ✅
1

Just hit a bit of a weird issue, which i guess is fairly obscure but exists none the less.

I have a a few plugins I made containing common code, just blueprints, snippets, template files and a few useful hooks. I use these in most projects. I normally symlink these into my current project.

With the 3.2.0-rc2 release, there are a few features available that means i can refine my UI a little more (like the uploads on the files field). I have a sandbox project I use to work on this stuff, which had the symlinks in place. I deleted the symlinks and copied the plugins into my sandbox site so i could update them in isolation so it wont effect clients sites using these plugins. Thats the crucial bit.

The panel refused to see the copy in the plugins folder. Somewhere, somehow there is a cache of the plugin blueprint/snippet/template locations. As far as Kirby was concerned, they will still at the symlink path, not under the plugin folder. Heres where it gets weirder. If i trashed the plugins, and reloaded the panel, it complained it couldn’t find any of the stuff. When i put them back, it was happy, but was still insisting on loading them from the symlink location, despite the files being directly available in the plugin folder, and where not symlinked.

Ok I thought, its probably a session thing. I flushed the browser. Same result. The only thing that fixed it was to reboot, so im guessing its a PHP cache somewhere. I don’t know how all that works really.

I know its an obscure one, and i don’t really expect a fix as such, but it seems odd that it keeps hold of the file path to the blueprints. If this was a live server, i may have had to reboot the server to get it to sort itself. Not ideal.

To reproduce:

  1. symlink some plugins with blueprints into the plugins folder
  2. login to the panel and move around a bit, hit some pages using the stuff in those plugins
  3. delete the symlinks, and put the real plugin files into the plugins folder
  4. try changing the blueprints in the plugins folder. It should refuse, since its still seeing the the identical ones that where symlinked.

You will probably have to reboot / kill your local server to get it to work again (im using Valet+ and PHP 7.1).

Just putting it out there… I observed this with 3.2.0-rc2, but i guess it might have existed before.

2

If you google “nginx symlink cache” you get some results that might be helpful.

3

@jimbobrjames Have you found a solution?

4

Only restarting the server to flush the cache.I did google around on the technicalities of it. It does seem specific to Nginx. Call it solved if you wish :slight_smile: