David Karich

To be honest, I wouldn’t do that. Sometimes, for example when replacing a logo, the graphic simply has different dimensions (because it’s a different logo or partner, for instance, but is to be placed in the same spot). The same applies, for example, when the styles of images change as part of a design overhaul. For instance, square images used to be used for contact persons, but now the client wants portrait format. In that case, a simple swap wouldn’t be possible if there’s a restriction on dimensions.

I think you’ve identified all the pitfalls quite well. To me, it reads like a well-thought-out plan. One pitfall in my use cases would be ProCache: if ProCache is in use, the pages that reference the modified asset should be removed from the cache. Otherwise, on-the-fly regeneration won’t be triggered the next time the page is loaded, and the page will refer to the old, deleted file – which may even have had a different filename – resulting in a 404 error. As this replacement process can trigger many background processes, depending on the amount (e.g. clearing ProCache pages for hundreds of items), an informative loading indicator in the UI should be used to show users what is happening at any given moment. In principle, it’s also worth considering whether, when uploading the asset to be replaced, you should ask whether the filename should be retained from the original or renamed to the new one.

Must have Module! 🚀

Hi @Mikel That looks like a very useful module for existing installations. I’m looking forward to testing it next week. Just one crucial question first: why only image fields? I’d have the same use case for normal file fields. Would it be possible to extend the module to work with files as well?

@Roych It looks promising so far. Thanks for the module. Custom event tracking and goal tracking are features I personally would still like to see. Plus conversion rates based on that data. Have you already run a performance test using long-term data and a large number of visitors? How does this scale over the long term? For example: I have sites with 6 million unique visitors per year and a tracking history spanning 15 years. Does the module still run stably with such large data volumes?

Hmm, not the best solution. 😅 I've tried it about 30 times already today.

Hi everyone, I’m not actually sure who the forum admin is at the moment: here’s a bug report. I can’t change my profile picture. When I try to upload and save it, I get a 500 server error with the message: Content unavailable. Resource was not cached. FYI @ryan

A quick note about the new documentation: the table layouts in the accordion sections don't work on mobile devices. They aren't scrollable. 😊

We send everything through Amazon SES. You can limit it to specific regions, and you won’t find a cheaper way to send bulk emails. It’s $0.10 per 1,000 emails. And the deliverability is top-notch. And no fixed monthly fees — just pay as you go.

Then you'll get two hearts. 😅

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?

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!

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.

@Gadgetto Are you still developing your module further with regard to the switch to Snipcart V3?

Hi @kongondo Happy New Year. It's been a while since anything has happened here on the subject of ‘Next’. Since there are two major projects planned for this year where I would be needed for MM, I wanted to ask what the status is? 😊