Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Media metadata capabilities: how would you prefer these requests brought?

Open
  • Is something wrong?
#40 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
php
Domain
api

Research direction

Start with the API plugin's existing media resource, page-media listing, and /meta behavior described in the issue, then review the related media metadata work in Grav 2.0.11 (#4200). The listed observations need to be split into separately scoped proposals or an agreed tracking issue. Done means maintainers have chosen the scope, ownership, order, and whether each item is planned or out of scope.

Written by the indexing model from the issue text.

Description

Context

While building a metadata-driven media gallery on Grav 2.1 (a theme plus the API
plugin), I took the liberty of analysing where the media / .meta.yaml
capabilities tend to stop short of what a curator-facing gallery needs. I have a
few small, separately-scoped observations written up, and thought it best to ask
how you'd prefer to receive them before opening anything.

Grav 2.0 is API-first and already moved media in this direction: .meta.yaml
metafiles, media as a first-party API resource, upload and metadata editing in
Admin Next, and the metadata queries added to page.media in 2.0.11 (#4200).
These observations simply continue that path toward a full gallery experience.

Most of what I have is API-plugin side (listing, batching, filtering, field
types); a couple are core-side (metadata defaults, EXIF, a metadata write API).
Happy to file each wherever fits best.

What I've been looking at

Briefly:

  • batch metadata for page media (site media already has it);
  • metadata included in media list responses, to save a per-file /meta call;
  • grouping/facet output, and a search that composes with filter/sort;
  • pagination for the page-media listing;
  • a few more metadata field types (e.g. number, date, select);
  • some extensibility and i18n points (registering metadata fields, custom field
    types, translatable labels, and per-language values);

plus a couple of possible core-side items (folder-level metadata defaults, EXIF
re-extraction, a programmatic metadata write API).

If you have a moment

  • Would you prefer one issue per item, or an umbrella/tracking issue?
  • Is any of this already planned, in progress, or intentionally out of scope?
  • Is there a preferred order, or labels/milestones these should attach to?
  • Anything above you'd rather I leave alone?

I'm glad to reshape, merge, or drop anything already covered — and I haven't
filed anything yet.

This report was generated with AI assistance.

Dominant language
PHP
Stars
5
Forks
10
Avg merge
8h 29m
Merged PRs (30d)
6

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from getgrav/grav-plugin-api

All issues in getgrav/grav-plugin-api

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.