Galleries are counted from wp_posts where post_type is foogallery. Item counts are resolved from the FooGallery postmeta image list, the same source the front end uses. Templates and album membership come from postmeta and the foogallery_album CPT respectively, joined at query time.

Yes. Filter by post_status, by taxonomy term, by date range, or by template, and every card recomputes against the same filtered source. The filters apply at the dashboard level rather than per card, which keeps the cards comparable.

Yes. Dynamic galleries from FooGallery Pro resolve their item list at query time the same way as static galleries, so they appear in the item-count chart with their current resolved count, even though the underlying source is a folder or tag.

Album coverage charts work from the foogallery_album CPT and its term relationships to galleries. A bar of galleries per album surfaces uneven album sizes; a number card on unassigned galleries highlights organisation gaps.

Yes. Both views read the same underlying source, so a filter saved at the source level applies to whichever layout is open. Toggling between table and chart layouts is one click without rebuilding the filter set.

Counts and groupings use indexed columns on wp_posts and the existing FooGallery postmeta keys. Aggregations are cached per saved view with a configurable refresh interval, so the dashboard stays responsive even on libraries with thousands of galleries.

Yes, scoped to the items inside foogallery galleries. SleekView joins gallery items to wp_posts attachments and tests the _wp_attachment_image_alt meta value. Items with empty or missing alt rows are counted; values that are just whitespace can be flagged with a normaliser if needed.

No. The dashboard renders on its own SleekView admin page and does not enqueue scripts on the public site or on unrelated admin screens. The default editor experience for galleries stays exactly as FooGallery configures it.