Worth two minutes before you build anything large. Knowing where the data lives explains most of the plugin’s behaviour, including the parts that surprise people.

Gallery itema WordPress post of type jmzg_mediaText, number, datestored as post metaTags, single choicestored as a taxonomyThe image itselfstays in the Media LibraryNo custom database tables. Everything is a post, post meta or a term, so every WordPress tool still works on it.
A gallery item is an ordinary WordPress post that points at an attachment and carries your fields.

Items, not albums

Most gallery plugins ask you to put photos into albums, and an album is the only thing you can then display. JMGallery has no albums. Every photo is a record with fields on it, and a gallery is a saved query across those records.

The practical difference: one photo can belong to the 1994 holiday, the Portofino set, the pictures of Ana, and the portfolio, all at once, without being copied four times. Albums are just another field — and you can delete that field if your collection is organised some other way.

Where each piece lives

The gallery itemA post of type jmzg_media
The imageThe post’s featured image, still an ordinary Media Library attachment
Text, number, date, long text, link, yes/no fieldsPost meta, keyed jmzg_ plus your field key
Tags and single-choice fieldsTaxonomy terms, so they get their own archive URLs
Your field definitionsOne option, jmzg_fields
Your saved displaysOne option, jmzg_displays
SettingsOne option, jmzg_settings

There are no custom database tables. Every backup plugin, migration tool, search plugin and SEO plugin you already use understands this data, because it is nothing unusual.

Three consequences

Deleting a gallery item does not delete the photo

The item and the attachment are separate things. When you delete items, JMGallery asks explicitly whether the files should go too, and defaults to keeping them.

Removing a field hides it, it does not erase it

The stored values stay where they are. Add a field back with the same key and everything reappears. This is deliberate: removing a column should not be a destructive act.

Changing a field’s type does not convert the data

Text stored as text stays text. If you switch a field from text to number, old values are still there, and they are still strings. Convert them yourself, usually by exporting to CSV, fixing the column in a spreadsheet, and importing back.

Tag fields get URLs of their own. A tags field keyed people gives you /photos/people/ana/ automatically, listing only that person’s photos. Nothing to configure.