[WIP] Media Hub - the centralised hub for your PW media

[Peter Knight]

Hey, I've started to create a Media Hub for Processwire.

[Edit...newest updates to UI are in later posts]

Screenshots attached. Obviously a few UI improvements are needed 🙂 

One of my clients requested a centralised media manager. I thought it'd be fun to give it a go and learn some stuff.

I know that with a self-built Module, it'll always be maintained, and I have an active interest in evolving it.

Shout out to @markus-th who just announced he is doing similar with WireMedia.

 

[Stefanowitsch]

Looks really good, too. I would like to give it a try when it is ready. A media manager solution is a must have feature IMHO.

[Peter Knight]

14 minutes ago, Stefanowitsch said:

Looks really good, too. I would like to give it a try when it is ready. A media manager solution is a must have feature IMHO.

I'd love some early testers, Stefan. Thanks for the offer.
If you're interested in trying it on a non-commercial site and are happy with temporarily breaking changes, I will be in touch when I'm a bit closer to the first version.

[Peter Knight]

Hey everyone, I have some updates to MediaHub to share.

Media Hub view

Screenshot of the Grid view...

• This is the grid view showing a thumbnail of all your images.
• Each card has helpful meta data (PNG, file size etc)
• Some images have crop applied denoted by the small pink badge. IE Lisbon tiles has 4 crop versions.
• Usual filters at the top and a search bar.

Screenshot of the Table view.

• Handy if you have hundreds of images
• Displays tags too

Screenshot of the Upload / Drag and drop mode

• There's some nice aniamtion / UI when the system is uploading several images

Tomorrow I'll share more...

 

 

 

 

 

[Krlos]

This looks awesome!

[10101]

This looks great!

Any chance you could share a bit more detail on how file storage and file usage in page templates will work?
Also wondering if there’ll be a custom field type replacing / extending the core image/file fields.

[Peter Knight]

Some more work. Not sure why the images are so fuzzy

Image detail page

• You can edit the usual stuff...Title, Alt, Description, and add Tags etc
• Some utilities in there too such as Download, Copy URl, Duplicate, Delete
• If an image has Crop versions they are displayed under the main image
• Crop versions has thumbs and table view
• A crop version has a detailed view too

Image Crop page

• There are presets, but you can create your own named crops
• Save as a crop version or save as a new image. 

The hardest part is in progress which is

1. A custom Inputfield which allows you to add images from the MediaHub. All while maintaining a connection back to the hub source file. IE it's important that there's no duplication and that the images in the Media Hub are a true source / canonical version
2. Displaying images in the page edit field in a nice consistent way with the existing UI. As much as possible, I want the user to feel like this the core and not some bolt-on with its own CSS. Although I am changing some things…

Hope you like!

P

 

 

[Peter Knight]

22 hours ago, 10101 said:

This looks great!

Any chance you could share a bit more detail on how file storage and file usage in page templates will work?
Also wondering if there’ll be a custom field type replacing / extending the core image/file fields.

Yeah sure. This is how I’m proceeding…

Every file is a page and has its own id folder. I guess that part is predictable enough.

Crops are simply variations of an image. They are stored in the same id folder with their own unique name.

Re. image fields, there’s a custom field which is designed to look and feel like a normal image field, but isn't a regular image field. 

A user adds images to the image hub field, but they are living, connected references to the source hub. IE the image hub assets are not detached copies. The hub is meant to be the centralised media hub. Otherwise, it wouldn’t be much of a hub.

At least that’s how it’s working right now. 🙂

 

 

[Peter Knight]

19 hours ago, Peter Knight said:

Crops are simply variations of an image. They are stored in the same id folder with their own unique name.

Rethinking my Media Hub cropping model 😑

I discovered a limitation when adding images via my new ImageHub field: selecting a crop doesn’t add a second item. Instead, it replaces the first crop selection.

Root cause: the field stores a PageArray / reference list keyed by page ID, so it silently dedupes. All crops belong to the same master image page (same ID), so you can only reference it once.

I’m leaning toward treating each crop as its own image/page (unique ID) with a master_id link, so multiple crops can be selected, ordered, reused across pages, and tracked for “where used”.

 

[maximus]

Hello, Peter.

Thanks for the updates — it's clear that you're moving fast and in the right direction.
Lots of screenshots, lots of details, it already looks solid.

Good luck with the improvements. Take your time, but also don't delay — the potential of the thing is good.

[Peter Knight]

How does everyone feel about folders? I have tags working but I am also considering Collections.

A photo could belong to one or more collections. In the background I’d allow the agency/developer to rename collections as folders. I know collections are more powerful but many clients are more at home with the concept of folders. 
And I feel like, why make them choose?

[Peter Knight]

6 hours ago, maximus said:

Hello, Peter.

Thanks for the updates — it's clear that you're moving fast and in the right direction.
Lots of screenshots, lots of details, it already looks solid.

Good luck with the improvements. Take your time, but also don't delay — the potential of the thing is good.

Cheer for the support Maximus. Having one of those days where I need a break from it all but more coming soon. Good to hear it’s useful.

[taotoo]

On 2/10/2026 at 11:13 PM, Peter Knight said:

the image hub assets are not detached copies.

I like this approach a lot - looking forward to seeing it in action!

[David Karich]

It looks fantastic so far. Great work. 😯

I'm currently struggling with similar problems and requirements for a media manager. However, it needs to be scalable enough to easily handle 100,000 assets (for a news portal). My experiments with the principle that each asset is also its own page quickly reached the limits of performance. I am therefore pursuing the approach of storing the actual asset paths in the database, i.e. as a JSON object in a separate input field.

A well-known problem: what happens if you rename the asset in the file system? I am still in the testing phase to see if this can be solved with a simple SQL replace and update.

However, I would be very happy to test your module. Maybe I don't have to reinvent the wheel after all. 🙂

Here are a few more wishes that I have as requirements in my projects:

• Folders: Customers love folders and folder trees.
• Multiple use: An asset is used multiple times on different pages; it must also be possible to have different descriptions here. With the MM module, for example, the description is global and cannot be changed individually for each reference.
• Language versions: An asset is only available for certain language versions, so it can be deactivated for EN, for example, and will not be displayed in this language in the frontend.
• Automatic categorisation: An API that enables automatic categorisation after uploading/saving. Example: In the ‘News’ template, there is a select field called ‘Category’. If a new image is uploaded in the edit mode of the page, it should be automatically loaded into the folder of the selected category or alternatively tagged. In the best case, this creates an automatic structure if you can define several fields such as ‘News/2026/Category’. The date is read from a date field and the category from a select field, etc.

[Peter Knight]

Hey David
Thanks for that. I am planning another sprint next week.

Right now, I am approaching this from a traditional image-as-page approach.
Each crop variation of a 'master' image is also a separate page.
 

That's possibly not as good for scalability but better from the point of view of having a new page image field listing all my images and crops.

I dont have any sites with 10K + images so I'm happy enough with this solution but I will certainly reconsider and you've given me some other ideas too which I'll tackle next week.

Will DM you re. other items.
Cheers

[Peter Knight]

On 2/19/2026 at 2:22 PM, David Karich said:

 

It looks fantastic so far. Great work. 😯

I'm currently struggling with similar problems and requirements for a media manager. However, it needs to be scalable enough to easily handle 100,000 assets (for a news portal). My experiments with the principle that each asset is also its own page quickly reached the limits of performance. I am therefore pursuing the approach of storing the actual asset paths in the database, i.e. as a JSON object in a separate input field.

Incidentally, when you mention you reached limits of performance, where and how did those limits manifest?

I ran your query / issue through my AI Agent and had the following response.

The Real Diagnosis

Your friend likely experienced real slowness, but the cause is almost certainly inefficient query patterns (loading too many pages at once, N+1 queries, unindexed searches) rather than a fundamental limitation of pages-as-assets. These are the same problems any ORM-based system hits at scale, and they have well-known solutions.
 

What MediaHub Would Need for 100K Assets

Problem	Fix	Effort
Crops filter loads all crop pages	Direct SQL: SELECT DISTINCT master_id	Small
N+1 crop count per listing	Batch query or denormalized count field	Small
LIKE search on title/desc	Add FULLTEXT indexes	Small
Tag dropdown loads all tags	Already paginated or use autocomplete	Small
No query caching	Add WireCache for expensive queries	Medium
Standard pagination at scale	PW handles this natively with start= + limit=	Already done
Streaming large exports	Use $pages->findMany() (lazy loading)	Small

 

 

None of these require rethinking the data model. They're standard database optimization work.
 

Summary

The page-per-asset architecture is sound and scalable. ProcessWire's page model with proper indexing handles 100K+ pages without issue. The current MediaHub implementation has a handful of query patterns that would need optimization (mostly the crop filter and N+1 counts), but these are straightforward fixes. Switching to a JSON-in-field approach would solve the wrong problem while creating a bespoke data layer that loses most of PW's value and introduces its own harder-to-fix scaling issues.

//END

What do you think of above

 

[Peter Knight]

Media Hub update

• The Media Hub now has a folder view 
• Folders is the default name for the view. It can be renamed to Gallery, Collections, Assets, Media, etc. 
• Media assets can exist in one or more Folders so essentially they operate like Tags 
• Clicking a Folder name will filter the main MediaHub by items within that Folder (and optionally sub folders)
• On an Asset detail view, you can quickly add and remove an association to a folder
• Support for Folder nesting, renaming etc is working

[David Karich]

On 2/21/2026 at 12:35 PM, Peter Knight said:

Incidentally, when you mention you reached limits of performance, where and how did those limits manifest?

I ran your query / issue through my AI Agent and had the following response.

The Real Diagnosis

Your friend likely experienced real slowness, but the cause is almost certainly inefficient query patterns (loading too many pages at once, N+1 queries, unindexed searches) rather than a fundamental limitation of pages-as-assets. These are the same problems any ORM-based system hits at scale, and they have well-known solutions.
 

What MediaHub Would Need for 100K Assets

Problem	Fix	Effort
Crops filter loads all crop pages	Direct SQL: SELECT DISTINCT master_id	Small
N+1 crop count per listing	Batch query or denormalized count field	Small
LIKE search on title/desc	Add FULLTEXT indexes	Small
Tag dropdown loads all tags	Already paginated or use autocomplete	Small
No query caching	Add WireCache for expensive queries	Medium
Standard pagination at scale	PW handles this natively with start= + limit=	Already done
Streaming large exports	Use $pages->findMany() (lazy loading)	Small

 

 

None of these require rethinking the data model. They're standard database optimization work.
 

Summary

The page-per-asset architecture is sound and scalable. ProcessWire's page model with proper indexing handles 100K+ pages without issue. The current MediaHub implementation has a handful of query patterns that would need optimization (mostly the crop filter and N+1 counts), but these are straightforward fixes. Switching to a JSON-in-field approach would solve the wrong problem while creating a bespoke data layer that loses most of PW's value and introduces its own harder-to-fix scaling issues.

//END

What do you think of above

 

Hi @Peter Knight 

Thank you very much for the pre-analysis. 😊

It is correct that the sheer number of pages is not the problem. I have already achieved good performance in tests with half a million pages. The real problem occurs more during output: the limit here is often the RAM limit of the PHP process.

Example: You have an image field for a gallery. In this gallery (here as an example from one of my customers, an event), there are easily between 100 and 200 images per input field. When outputting to the front end – and also in the back end when editing – you run into a MAX RAM problem and very long loading times, as each image object is loaded into the RAM.

Here, I now see an additional problem with the ‘1 asset per page’ approach: not only is the image object loaded, but also the complete page object where the asset is stored. And if I understand your concept correctly, the master page object of the asset is also loaded.

This means, to stick with the example, that with 100 images, around 300 objects are loaded into RAM just to output them. This is overkill for most servers (especially shared hosting).

One possible solution here would be to implement a kind of ‘getRaw()’ method, similar to ‘findRaw()’, which returns all asset paths (including variation paths) and descriptions as a simple array – without the complete object. This would make it easy to iterate over the array and output the images directly. I am aware that this would then make it impossible to use ‘size()’, ‘width()’ etc. and all the image methods.

What do you think of this option for special use cases with many assets that need to be loaded at once?

And thank you again for your truly great work and your ambition to develop such a complex module!

[David Karich]

On 2/21/2026 at 5:10 PM, Peter Knight said:

Media Hub update

• The Media Hub now has a folder view 
• Folders is the default name for the view. It can be renamed to Gallery, Collections, Assets, Media, etc. 
• Media assets can exist in one or more Folders so essentially they operate like Tags 
• Clicking a Folder name will filter the main MediaHub by items within that Folder (and optionally sub folders)
• On an Asset detail view, you can quickly add and remove an association to a folder
• Support for Folder nesting, renaming etc is working

Fantastic. You've already won my heart. 🤩

P.S.: @Peter Knight, this raises another question for me: have you also planned a ‘delete protection’ feature? When an image is deleted from the Media Hub, is it first checked to see whether the image is used on any pages? If so, deletion is not possible and there is an option to list all the pages where the image is used?

[Peter Knight]

31 minutes ago, David Karich said:

Fantastic. You've already won my heart. 🤩

P.S.: @Peter Knight, this raises another question for me: have you also planned a ‘delete protection’ feature? When an image is deleted from the Media Hub, is it first checked to see whether the image is used on any pages? If so, deletion is not possible and there is an option to list all the pages where the image is used?

Yes already have it done.

Each asset has a details page with a Usage table. This lists the places where an asset is used etc.
The attached should give you an idea even if this asset is only used in one place.

[David Karich]

3 minutes ago, Peter Knight said:

Yes already have it done.

Each asset has a details page with a Usage table. This lists the places where an asset is used etc.
The attached should give you an idea even if this asset is only used in one place.

Then you'll get two hearts. 😅