What Gets Detected

MediaFlow asks one question of every piece of content: which attachments does this use? This page lists what counts as an answer.

The same scan powers two things: the folder names in automatic organization, and the Used on answers.

Core WordPress

• Featured images.
• Gutenberg blocks: core/image, core/gallery, core/cover, core/media-text, core/video, core/audio, core/file and core/site-logo.
• Nested blocks: blocks inside groups, columns and reusable blocks are found too, with a loop guard and a depth cap so a reusable block that references itself cannot spin.
• Classic editor content: [gallery], [playlist], [caption] and wp-image-NN markup.

Images with no ID

Some content references an image only by its URL, with no attachment ID attached. MediaFlow resolves those by looking the upload URL back up — including resized filenames such as hero-300x200.jpg, and protocol-relative sources.

Elementor

When Elementor is active, MediaFlow walks the saved Elementor document structurally, recognising the {id, url} shape that every Elementor media control stores. That means backgrounds, galleries and repeater rows are all found without maintaining a list of control names.

WooCommerce

When WooCommerce is active, MediaFlow reads product gallery images and variation images. Variations are capped at 100 per product.

The same rule applies: the provider registers only when WooCommerce is loaded, and WooCommerce is never required.

Advanced Custom Fields

ACF image, file, gallery and repeater fields are read — including fields nested inside repeaters, flexible content, groups and clones.

They are found structurally, not by field name. Every ACF value is stored as two meta rows: the value itself, and a companion row holding the field key (field_5f3a1b…). Any pair shaped like that is an ACF field, whatever it is called and wherever it sits. So you do not have to register your field names anywhere.

With ACF active, the field’s own type decides whether it holds media. Without ACF active — the values outlive a deactivated plugin — shape decides, and MediaFlow’s existence check drops anything that is not really an attachment.

Other page builders

Divi, Bricks, Beaver Builder and Breakdance are read, each from its own storage:

After decoding, all four look the same — a nested tree of settings where a media value is either an ID under a media-sounding key, or an {id, url} pair — so they share one walk. No builder class is called and no builder is required, which means any of them can change version, or be deactivated with its data left behind, without breaking detection.

Theme options and the Customizer

Theme mods are read: logo, site icon, header, background, and any theme option whose name says it holds an image.

What is deliberately not detected

MediaFlow reads block attributes from an explicit map of known media attributes. A blanket “any attribute called id” rule was considered and refused, because core/navigation stores a menu ID under exactly that name — and filing your logo under a navigation menu would be worse than not filing it at all.

If you have a custom block that stores an attachment ID, teach the resolver about it with mediaflow_block_attachment_keys, or read the IDs yourself with mediaflow_block_attachment_ids. Whole custom sources register through mediaflow_media_usage. See Filters and hooks.

What is never seen

Two sources are outside what any content scan can reach, and the interface says so rather than leaving you to find out:

• CSS background images and hard-coded template URLs.
• Anything referencing the file from outside this site.

A file used only in one of those ways will show as having no known usage. This is why MediaFlow never uses the word “unused” — see Where media is used.

Frequently asked questions