Start here
All documentation Installing JMGallery Your first gallery How JMGallery stores thingsFilling the library
Adding photos Custom fields The library and bulk editing CSV export and importShowing photos
Building a display Grid, masonry and list Shortcodes The archive page and filters Single photo pages The Elementor widgetPro features
Video Captions, backgrounds, hover Protecting your photos Downloads and sellingReference
Settings reference Licences and updates For developers TroubleshootingWorth 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.
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 item | A post of type jmzg_media |
|---|---|
| The image | The post’s featured image, still an ordinary Media Library attachment |
| Text, number, date, long text, link, yes/no fields | Post meta, keyed jmzg_ plus your field key |
| Tags and single-choice fields | Taxonomy terms, so they get their own archive URLs |
| Your field definitions | One option, jmzg_fields |
| Your saved displays | One option, jmzg_displays |
| Settings | One 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.