Jump to content
You're invited! Join our 4.6 Live Event on ZOOM 6/24 ×


Support caching URL for database-stored files

Recommended Posts


It would be very helpful if database-stored files could be assigned a caching URL. Right now, they are at /index.php?file=xyz

I am using a CDN for file-based storage, which covers JavaScript, CSS and emoticons, but there are still database-stored files such as user profile pictures etc. At this point I'd say this is the bulk of my data transfer. They don't seem to cache for very long in the user's browser either, despite barely ever changing.

I do recognize this would require the user's setup to support friendly URLs. Most do, though.

Thank you!


Edited by James25
Link to comment
Share on other sites

20 minutes ago, Matt said:

Out of interest, why are you choosing to use a database to store images?

We've used this configuration in the past (with vBulletin) when we had multiple front end servers and relied on the database to serve out certain images. It simplified the backup process for user generated things, and made it so we could spin up web servers easily without having to move files between multiple filesystems. We have a new approach now, yet I think if an administrator (for whatever reason) sets images to be stored in the database, it makes sense to serve them with a URL absent a query string.

Link to comment
Share on other sites

  • Management

In 2021 I would really suggest you use S3 for this over database storage. Storing images in the database is a holdover from days past and is something I think we should remove in a future version. You are trying to make MySQL do something it is not really designed to do but, 20 years ago, better solutions like S3 did not exist.

Link to comment
Share on other sites

Posted (edited)

It's actually useful in cases you might not expect. Take a look: https://themes.evolvapor.com/

When a new .ecigtheme is uploaded, I have a background task that checks for new uploads, generates preview images using our software, and inserts the new images in the database. If I were doing this with the filesystem, I'd need to give this task write permission, and the ability to reach, the directory on the server hosting IPB.

Regarding S3... Being in the vaping industry -- and really, this is true for anyone in an industry entrenched, wealthy interests would like to be rid of -- we try to be self-reliant where we can. You never know that you won't wake up the next day and be disconnected for some reason invented the day before. For us, and many others, "better solutions like S3" effectively do /not/ exist today.

If I were able to cache these, the hit rate would be 99%+.

Edited by James25
Link to comment
Share on other sites

MySQL is happy spitting out blobs all day long if provisioned correctly and in tandem with caching, even better.

James, you may want to consider that these images can be put on a filesystem other than the one hosting your IPS files and served out from a subdomain or similar. To do so, It's not very well documented or as apparent as it could be in the help guides. However, it sounds like your process could generate the preview image, put it on that separate filesystem, and then insert the path into the database instead of the blob itself (if that's your preferred method).

You can create a filesystem storage configuration, turn on "use custom url." Consider setting up a subdomain like preview-images.example.com, that lives on another server you maintain for serving out these images and is then cached by your CDN.

What I'd suggest instead, however, is that you transition this task to use the IPS API for Downloads instead. This way you only need to grant API access to your process, the files can be stored on your filesystem, and your script doesn't need access to the web server's filesystem to do so.


Are screenshots not editable though via API? What nonsense is that?

Link to comment
Share on other sites


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy