getgrav / getgrav/grav-plugin-admin
'type: filepicker' not working inside plugin
- Dominant language
- PHP
- Stars
- 377
- Forks
- 225
- Avg merge
- 11h 51m
- Merged PRs (30d)
- 4
Description
EDIT: After digging around a bit more, and talking with the devs it looks like an issue with filepicker inside list elements on plugins. Added screenshots at the end.
I made a simple admin plugin addon that gets the blueprint of a page and builds a form so you can modify the frontmatter file of that page folder to help editors speed up multilanguage setups, but neither *type: pagemediaselect* or _type: filepicker_ work, giving me a prompt in admin saying that **'Cannot use "self@" outside pages'**.

The issue is I'm not using *self@* anywhere on my theme blueprints, neither on the plugin, the folder: is set to *theme://images/icons*.
```yaml
.image:
type: filepicker
folder: 'theme://images/icons'
preview_images: true
label: MYTHEME.FORM.MENUITEM_ICON
```
It is inside a list element. I placed another filepicker field outside of one to test, and it gave the same error, not working either.
On a clean install it doesn't work either, but doesn't throw an error.

I tried using it on the plugin blueprint itself, and it worked as expected

*type: mediapicker* does work but it only finds images uploaded to page folders, not the theme or *user://images*, which is what I need.
I've been using the latest version of both Grav, Forms and Admin plugin since the start.
I'm working on a windows 10 machine, and tried using both **bin/grav server** and xampp apache server.
EDIT:
Screenshots when adding elements with filepicker to a list inside the plugin
Adding new element

After saving it empty once it works normally

But every new element still doesn't work

Contributor guide
Research direction
Start by reproducing the issue in a clean Grav Admin setup with a filepicker inside a plugin list element, comparing it with the working plugin blueprint field. The payload names no source files or tests, so trace the Admin plugin's filepicker and list-element handling until theme:// or user:// selections work reliably; done means new and saved list elements no longer show the self@ error or empty picker.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, php
- Domain
- content, frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100