MediaHub 1.19.25: upload refresh, custom fields and speed improvements

[Peter Knight]

Happy Friday, everyone. 

I'm starting this Friday with something I meant to do last Friday!

The latest version of MediaHub (1.19.25) is now available, and thanks to our testers, we have improvements across the UI, module performance and some new features too.

Existing Media hubbers: Download here
New to hubbing: Read here 
Full changelog: Read here

What's new and improved in 1.19.25...

 

Upload screen refresh

Uploading is one of the first things a new user will do, so the first impression should be positive, distraction-free and simple.

But behind a screen that seemingly has 'just one job', people asked if they could organise their uploads from here. While you can do this later within the Library, being able to associate your uploads with Collections and Labels at this point across multiple images will save you a lot of time and asset admin.

An "Organise uploads" bar above the dropzone lets you assign Collections and Labels before the batch starts. If one doesn't exist yet, you can create it from here.

A scrollable card queue replaces the old list. Each file shows a thumbnail or file-type icon, inline status, and a per-file progress bar. 

Oversized or unsupported files stage with a clear warning and are excluded from the upload. Inline filename editing on each card is possible before you upload.

We'll introduce a table view shortly if you're uploading at scale and want to sort and filter at this point.

 

Once your upload starts, you can see the progress of each file and a master progress bar.

Custom fields on assets

Adding custom fields to a MediaHub input field works the same way as the existing workflow. 

Should you wish, you can also assign custom fields to a master asset depending on your use case. 

You can assign custom fields to your master asset or just the MediaHub field on your page.

They work indenpendently when you want, but also have a relationship with and inherit-with-override model.

Inherit-with-override works the same way Title and Alt already do:

1. The asset detail page (left) holds the canonical (library-level) value. Every reference inherits it by default.
2. On a page, custom fields appear below Title, Filename, Description, and Tags. An editor can override the value for that one reference only. The override saves when the page saves, no separate save button
3. A small reset control next to any overridden field lets you revert to the library value in one click
4. On a MediaHub input field, a developer can choose to display custom fields in a different order than on the asset detail page

Two tiers
Some metadata belongs to the asset everywhere (a photographer credit, a licence URL). Other metadata belongs to how the asset is used in a specific field. Both are supported:

• Asset-level fields go on pkd-mediahub-asset. Master value plus per-reference override and reset
• Field-specific fields go on a template named mediahub-field-{fieldName} (mirrors ProcessWire's native pattern). These appear only in that field's drawer and are per-reference only, no library master

I hadn't planned on allowing custom fields on the asset detail page, but it was straightforward once I added some of the standard text-based fields.

It works in the same way you'd add a field to any template and doesn't even require the extra custom field to input field step (creating an extra fileless template). 

Anything on that asset template that isn’t one of MediaHub’s built-in fields: title, image, alt, labels, collections, and so on - is treated as yours.

Should you wish to uninstall MediaHub, we have safeguards in place to keep your custom fields on your ProcessWire install, which is what I think you might want.

The only real downside I have found so far is that custom fields on the master asset template show on every asset detail page, so a name like Photographer fits a photo but feels odd on a PDF or spreadsheet. What has worked for me is broader labels from the start (Source, Description). We plan to make this more asset-aware in a future release, but for now, name fields as if every asset type will see them, because they will.

But, this is just a side note and doesn't affect input fields, which was the core feature and of the 1.19.25 release.

Library thumbnails

1.19.25 takes a leaner approach to thumbnail generation and makes more effort to reuse thumbnails across the UI vs generating the full scope on upload and import.

• One preview at upload. Each image gets a single small proportional preview. That's 75% fewer auto-generated files at upload time.
• One library thumb per asset. Grid, Masonry, and List share one canonical thumbnail. CSS handles grid cropping.
• Built on first browse. The full library size is generated the first time you scroll an asset into view, not during upload. The upload preview is shown immediately as a placeholder so nothing looks broken while it's being prepared
• Import Existing Images and the asset picker use the same on-demand model.

Bulk imports of existing assets from existing fields should feel noticeably lighter on disk and CPU.

Library bulk actions and toolbar

The search and filter area of the Library was cleaned up for consistency and clarity in advance of some architectural changes (more below)

Selecting assets now swaps the breadcrumb row for a compact bulk action bar with actions for Collections, Labels, and Delete.

There's a useful workflow change here: you can select assets first and then create and assign a collection in one step, rather than having to create the collection first.

 

Library and picker consistency

MediaHub looks like it has one central Library, but under the hood there are actually three slightly different versions of it: the main Library, the InputfieldMediaHub picker, and the TinyMCE picker. Over time I found that improvements made to the main Library were easy to overlook on the other two, since they didn't share any underlying code.

To reduce that drift, 1.19.25 moves the toolbar, sidebar, filters, and tiles onto shared partials so all three surfaces stay aligned going forward. This isn't just a tidy-up under the hood either. It lightens the module overall, and it's what made it possible to introduce the Collections and Labels sidebar into Library screens that didn't have it before.

 

Import page images

The ability to import images from your existing fields was an early feature and has been in MediaHub since v1

1.19.25 gives it an overhaul. BTW the import Page Images button is optionally enabled in the field config so you can enable it on a field-by-field basis.

Repeater and RepeaterMatrix support
The scan now walks Repeater and RepeaterMatrix fields up to three levels deep. Results are grouped under breadcrumb headings so you can see exactly where each image came from.

How matching works
Each image on the page is scored against the whole Hub using four signals:

1. filename stem
2. file size
3. dimensions
4. and a perceptual hash (a 64-bit visual fingerprint that can match re-encoded or renamed copies).

Each result gets a confidence badge:

• New - not currently in the Hub
• Exact match - identical file already in the Hub
• Likely match - looks like an asset already in the Hub
• Possible match - filename matches a Hub asset but the file content appears different
• Already added - already used in this field

When a match is confirmed, MediaHub adds a reference to the existing asset rather than copying the file again.

Hardening for large pagesThere's also longer scan and import time limits, JSON error handling, a 200-selection cap per request, and client-side checks so a timeout doesn't surface as a cryptic error.

Import Page Images was one of MediaHub's earliest features, and I think there's more we can do here. The import modal in particular could use a bit more cleanup, so that's on the list.

 

That's pretty much it. Thanks for reading and scrolling!

MediaHub is currently available for single sites, developers of multiple sites and agencies.

If you'd like to try it first, DM me.

Have a great weekend,
Peter