i’m creating an artist’s website, with lots of images, and every image has an image.meta.yaml file. They’ll be uploading new images via the admin panel, as they create new work, but I just realized that I don’t think there’s a way for them to create or edit image.meta.yaml files via the admin panel. Does anyone have a suggestion?
1 Like
Hi
You can manually add fields to your page blueprints, I’ve done this to add in alt and title tags. Its a bit of extra hassle but it works. I’m not 100% sure (cause I don’t use them) but I think you can set all the image manipulation functions (cropping etc) via markdown so at least they’re editable by users.
Hopefully there will be a plugin to address this soon.
Hi, I think that would work if there were one or two images per page, to just create form fields corresponding to each image’s metadata. In my case, each page has 10 - 15 images, so I think each one should have its own yaml file, rather than incorporating all of that data into the page’s frontmatter.
It does seem like there would need to be some sort of plugin to enable users to edit those meta.yaml files via the admin plugin. I found another thread that says that they’re currently working on it.
We have plans to add support for metadata editing, but just not gotten around to it yet
2 Likes
Hi @rhuk,
I was wondering if this feature was still in the pipeline. I could not find anything confirming.
Thank you in advance.
Also interested, any progress?
It would be so good to have this! I just tried programming it myself, based on the plugin admin-addon-media-rename and the current display of metadata in the admin plugin, but it was beyond my abilities. Currently I can’t use Grav for websites that will be edited by other people, just because this bit is missing. I cannot ask an editor to create .meta.yaml files and upload them via FTP. Most of them would be out of their depths.
Hello everyone,
i asked this on Discord a few days ago and it points in the same direction. But i think it’s better to post it here :
–
I saw some discussions, for example on GitHub, about a media manager. Are there still any plans to implement this ?
Or maybe easier :
- An automatic generation of *.meta.yaml files, adjustable via a setting in the admin.
- The possibility to edit the *.meta.yaml files in the admin.
–
I agree with @clivebeckett . It’s often too complicated for editors to edit the meta-data of image files, for example.
If you have no plans or simply no time to implement this, what would be the right approach here?
Just some ideas :
To 1. : Writing a plugin that generates a *.meta.yaml file after uploading an image using the onAdminAfterAddMedia.
To 2. : I saw this plugin on the Grav Plugins page : https://github.com/Flamenco/grav-admin-media-actions. Can this be a basis for further development?
Maybe the core team already has a specific idea how to implement this.
Cheers
1 Like
I managed to create a plugin for adding/editing image.meta.yaml files and would be very happy for others to try it and maybe even contribute to it:
github.com/clivebeckett/grav-plugin-admin-addon-media-metadata
This Admin Panel addon adds *.meta.yaml files for each uploaded media file and provides a form for editing title/alt/caption in those *.meta.yaml files. You can configure it to provide more fields (see README.md). You can also manually add other data to a *.meta.yaml file which will not be editable via the form but will also not be overwritten.
Super excited for this plugin… I tried installing your beta version but I got an error:
Whoops \ Exception \ ErrorException (E_COMPILE_ERROR)
Grav\Plugin\AdminAddonMediaMetadataPlugin::autoload():
Failed opening required
'/Users/A/Dev/david-young/user/plugins/
admin-addon-media-metadata/vendor/autoload.php'
(include_path='.:/Applications/XAMPP/xamppfiles/lib/php'
@syntaxErrr, It’s best to create an issue at the repository of the plugin. That will help the developer in managing, discussing and fixing issues…
Hi! Thanks for trying … and sorry for this error message. I guess the AdminAddonMediaMetadataPlugin->autoload() method has been created by the
bin/plugin devtools new-plugin command – and I never touched it 
The weird thing is: I git cloned it into at least one other local Grav instance without a problem. And from there I uploaded the folder onto another Grav instance on a remote server where it also runs without problems.
I also just copied the plugin into yet another Grav instance: first without the above mentioned method, then removed it, then copied it again including the method. Both versions worked fine.
How did you install it? What’s your Grav version (mine: 1.6.x) and Admin plugin version (mine: 1.9). I also uploaded the plugin (as it is on Github) to an older version on a server where I can’t update Grav (Grav 1.5.10, Admin 1.8.20).
If you have the files in your instance already you could try commenting out the method (lines 42–45 in admin-addon-media-metadata.php) and see what happens.
I hope some of that helps.
@clivebeckett, If I’m not mistaken, the function ‘autoload’ will only be called by Grav 1.7.x.
When creating a plugin using Devtools it shows the following warning:
Make sure to run
composer updateto initialize the autoloader
If you run $ composer update in the root folder of your plugin, composer will create the required files inside the ‘vendor’ folder.
@syntaxErrr, To fix the issue you can run $ composer update yourself inside folder /user/plugins/admin-addon-media-metadata.
Hope this helps…
1 Like
@anon76427325 Thanks a lot! I did as you suggested (after I installed composer which I never managed to understand although I do understand its basic purpose) and pushed the resulting changes to Github.
I don’t know whether the empty classes directory should be uploaded, too or whether that will result in another error (git does not version control empty directories). The directory is mentioned in composer.json (autoload/psr-4), though the only class listed is the one in the root folder of the plugin.
@clivebeckett, Your plugin won’t crash if there is no ‘classes’ folder.
To preserve the ‘classes’ folder, a common practice is to add a ‘.gitkeep’ file to it. The actual name doesn’t matter, it is only a placeholder or dummy file. Grav uses it to preserve empty folders like ‘assets’, ‘backup’, ‘cache’, etc.
1 Like