Skip to content
Grav 2.0 is officially stable. Read the announcement →
Support

Issues with Flex Objects image uploads in Admin2 Panel

Solved by Andy Miller View solution

Started by kskt 2 weeks ago · 2 replies · 173 views
2 weeks ago

Hello,

First of all, thank you so much for Flex Objects. It is an incredibly useful tool and I really enjoy using it!

I am writing to report four issues I encountered when uploading images using Flex Objects.

Since I am not a professional programmer, I am not entirely sure if the following issues stem from the same root cause or if they are a combination of multiple separate problems. Please let me know if I should isolate these into different topics, and I will gladly split them up.

I have noticed the following four issues:

  1. Uploading fails when specifying destination: 'self@' in the blueprint, even though I configured it based on the official documentation.
  2. When uploading an image via the Admin2 Panel, the file is successfully uploaded to the folder on the first attempt, but it is not written to item.json. It only gets recorded in item.json on the second attempt.
  3. When deleting an image file via the Admin2 Panel, the actual file inside the folder is not deleted.
  4. When using destination: 'media://' in the blueprint and uploading an image, the image no longer appears in the Admin2 Panel when I reopen an object I previously created for editing.

Context

I have created a plugin called flex-images, as shown below:

BASH
php bin/gpm install admin2
php bin/plugin login new-user # create super user
php bin/gpm install flex-objects
php bin/gpm install devtools
php bin/plugin devtools new-plugin
> Plugin Name -> `flex-images`
> choose an option -> `flex`
> Flex Object Name -> `flex-images`
> choose a storage type -> `folder`
cd ./user/plugins/flex-images/
composer update
cd ../../../

1. Uploading fails when specifying destination: 'self@' in the blueprint.

I have created a blueprint, as shown below:

YAML
# user/plugins/flex-images/blueprints/flex-objects/flex_images.yaml
config:
    admin:
        permissions:
            api.flex_images:
                type: crudl
        list:
            title: name
            fields:
                text:
                    link: edit
form:
    validation: loose
    fields:
        text:
            type: text
            label: Text
            validate:
                required: true
        images:
            type: file
            label: Images
            multiple: true
            destination: 'self@'
            limit: 2
            accept:
                - image/*

In this state, when attempting to upload a file via the Admin2 Panel, the following error message is displayed:

TXT
Failed to upload image1.jpg: Cannot resolve 'self@:' path: scope '' is not a supported owner.

However, if I comment out destination: 'self@' as shown below, it starts working properly:

YAML
# user/plugins/flex-images/blueprints/flex-objects/flex_images.yaml
        images:
            type: file
            label: Images
            multiple: true
            # destination: 'self@'  # comment out
            limit: 2
            accept:
                - image/*

According to the official documentation, self@ seems to be the default, but it did not work for me.

(Reference) Cannot upload before creating the object

This might be the intended behavior rather than a bug, but I would also like to report that attempting to upload an image before the Flex Object itself is created results in the following error:

TXT
Failed to upload image1.jpg: Method 'POST' is not allowed. Allowed: GET, DELETE, PATCH.

If I first create the object via the Admin2 Panel and then upload the image while updating that existing object, it succeeds.

If possible, it would be highly appreciated if the error message could be something more descriptive.

2. Image is not recorded in item.json on the first upload attempt

After saving an object, if I attempt to upload an image via the Admin2 Panel for the first time, the Save button in the top right remains disabled.

JSON
# user/data/flex_images/.../item.json
{"text":"test"}

However, checking the folder confirms that the file has actually been uploaded.

BASH
$ ls ./user/data/flex_images/.../
image1.jpg  item.json

If I attempt to upload the exact same image again via the Admin2 Panel, the following notification appears, and it successfully gets recorded in item.json.

TXT
Object Changed Elsewhere Save To
JSON
# user/data/flex_images/.../item.json
{"text":"test","images":{"image1.jpg":{"name":"image1.jpg","type":"image\/jpeg","size":72707,"path":"image1.jpg"}}}

3. Deleted images are removed from item.json but remain in the folder

After uploading image1.jpg and image2.jpg via the Admin2 Panel, if I delete them and then upload image3.jpg, the result is as follows:

JSON
{"text":"test","images":{"image3.jpg":{"name":"image3.jpg","type":"image\/jpeg","size":79161,"path":"image3.jpg"}}}

However, looking inside the folder, the actual image files themselves are not deleted.

BASH
$ ls ./user/data/flex_images/.../
image1.jpg  image2.jpg  image3.jpg  item.json

4. Saving an image to media:// and reopening the object causes the image to disappear

Write the blueprint as follows:

YAML
# user/plugins/flex-images/blueprints/flex-objects/flex_images.yaml
        images:
            type: file
            label: Images
            multiple: true
            destination: 'media://'
            limit: 2
            accept:
                - image/*

With this method, it is possible to upload the image and create the object at the same time.
However, if I reopen the object created this way in the Admin2 panel, the image disappears.
The image itself exists in `user/media/`, and the image file is alsoentered in `item.json`.

2 weeks ago Solution

Thanks for the detailed writeup, this was exactly what I needed to track these down. All four are real bugs, and they're now fixed in admin-next and the Flex Objects plugin:

  1. Uploads failing on a self@ field with "scope '' is not a supported owner". The new admin was sending self@ file-field uploads through the wrong endpoint, which can't resolve self@ without a page/plugin/theme scope. It now uploads straight to the object's own media folder, which is exactly what self@ means for a Flex object.
  2. First upload not recording, Save staying disabled. The upload was tripping the object's own "changed elsewhere" watcher and quietly reloading the form, so the first upload looked like it did nothing. Fixed: the first upload now marks the form dirty, enables Save, and records on save.
  3. Deleted images left on disk. When you removed an image and saved, the reference was dropped from item.json but the file was left behind. The API now diffs the field on save and unlinks the removed file, the same way the classic admin's form always did.
  4. Images vanishing on reopen with a media:// destination. The field was reconciling saved values against the object's own media list, which never contains media:// files, so they got stripped on load. It now leaves destination-based values alone and uses the server URL for the preview.

Fixes are committed to develop for Flex Objects (1.4.6) and to admin-next / admin2 (2.0.14), so they'll land in the next releases. If you want to test before then you can pull those branches.

One small ask: for anything like this going forward, please open a GitHub issue rather than a forum post. Bug reports are much easier for us to track and process in our development queue, and yours was a great one to file. Thanks again for the thorough report!

Andy

2 weeks ago

Thank you for the quick and detailed response! I'm glad to hear that all four issues have already been fixed.

Also, I'll make sure to open a GitHub issue for any bug reports going forward. Thank you again for your great work!

Suggested topics

Topic Participants Replies Views Activity
Support · by Anna, 3 days ago
3 61 8 hours ago
Support · by TomW, 2 days ago
2 61 8 hours ago
Support · by Anna, 6 days ago
7 179 2 days ago
Support · by Anna, 6 days ago
9 147 2 days ago
Support · by stuart young, 5 days ago
2 97 4 days ago