I do. I don’t use the WordPress media library at all if I can help it. Even though the media library has a lot of in-built functionality I still try to avoid it.
For example it creates thumbnails automatically (smaller versions of the images you upload into it), and allows you to edit and crop your files directly inside WordPress. But this isn’t enough to persuade me to use it.
I Use Amazon S3
I place images for all my sites onto Amazon S3 in preference to using the WordPress media library. I create an organised environment on Amazon S3 with folder names for all the different parts of my site and store images there, directly.
So for example for this site, I would set up a folder on Amazon S3 called say images.genesisclubbers and then a sub-folder called say, posts, and then I’d place all the images for posts on this site into the Amazon S3 sub-folder.
You Said Folder – What Are Buckets?
Please bear in mind that on Amazon S3 top level folders are known as buckets.
So another way of describing what I have done (using the correct Amazon terminology) is to say I have created a bucket for each of my sites, on Amazon S3, and various sub-folders under each bucket to organise my images further within each bucket.
For me, there is one bucket per website that I run. Are the sub-folders, really sub-buckets? You tell me. Normally, in my head, I just think of them all as folders ….
A Bucket And Sub-Folder Example
If I had an image called an-image.jpg, then the ordinary Amazon S3 URL to that image (before I set up a CNAME) might be:
This assumes I’d set up a sub-folder of posts for all my images in various WordPress posts on a particular site.
Once I’d set up the CNAME for the top level Amazon folder (bucket), I’d be able to refer to my image as:
To be clear, I’d create a CNAME for each site, so one for genesisclubbers at images.genesisclubbers.com and one for genesisblueprints at images.genesisblueprints.com and so on.
Within each of those I’d create a number of sub-folders to organise content, but I’d only create a CNAME for the top level folder that covers each whole site.
Just to mention – if you wanted to keep more than just images on Amazon, then maybe you would not name the top level folder images.sitename.com but rather media.sitename.com and then go from there. It’s up to you.
There are some disadvantages to using S3 in the way I do but I think for me, I’d rather use it than have a huge cluttered media library in spite of the disadvantages.
How Can I Use S3?
You could choose to use one of the many S3 plugins available. However if you use a plugin to manage your access to Amazon S3 you will typically still use your media library.
What most S3 plugins do is copy all your images to S3 silently and then re-route any image requests directly to S3 rather than the media library. The media library is used as a sort of intermediate resting places for images until they are copied up to S3.
Using plugins that operate like this mean you get the benefits of S3 and Cloudfront, but your media library remains cluttered. If that works for you, it may be a good solution.
The only service that seems to not need the WordPress media library at all that I know of is Cloudinary. So that is an option if you want to avoid the media library practically altogether.
Maybe a cluttered media library is not an issue for you. Personally I don’t like it. I’ve seen user sites with many hundreds or even thousands of images in the media library and it’s generally a mess.
Disadvantages of the WordPress Media Library
Moving A Site To A New Host
When you have to move a site to a new host, having an empty media library makes the operation very easy and very fast as there are no images to move.
Backing Up A Site
When you have to back up a site the resulting zip file is small because there are no images to backup. The database is also small as there are no images in it, and no attachments.
Finding An Image
When I go looking for an image I can find it as it is well organised in S3. Unless you use extra plugins and stick to a great naming convention you’ll have a hard time finding images or clearing out your library of unused images. When you use S3 you have to be disciplined about where you place mages and what you call them.
These things are important to me, but as you know 99.999% of people use the media library all the time so I’m in a minority.
Alternatively if you host with WP Engine as I do or some host with similar facilities, then you can just click a button and all your media library images are copied to a CDN anyway, it just does not happen to be S3/Cloudfront.
This achieves the speed, but still does not address the cluttered media library. Again this may not matter to you.
Or you can install Automattic’s Jetpack and use the free Photon facility that automatically uploads your media library to a CDN.
Disadvantages To My Approach
There are some plugins and some WordPress functions (galleries for example) that rely on the media library.
If I have to use one of these plugins or functions, then I will use the media library but even if I do, I will end up a very defined set of images in the library – eg the contents of a portfolio – with all other images kept on Amazon S3. So my media library is managed.
In general though, if you do not keep your images in the media library at all, you do not get thumbnails. So using my route, in general you will have no thumbnails. This means for example, no featured images for your posts.
To address this we wrote a thumbnail generator within the Genesis Club Pro plugin which creates thumbnails from S3 and hosts them on your site but not in the media library. That is achieved via the Genesis Club Pro plugin.
This was the simplest and easiest way to achieve fast thumbnails. As the thumbnails are unknown to the media library they do not clutter the database either.
So you get all the speed and other advantages of S3/Cloudfront and no cluttered media library.
Because I’m working with S3 I always optimise my images before I load them up to Amazon. When my thumbnails are generated by the Genesis Club Pro plugin they are generated from an already light-weight image.
But WordPress introduced another media library feature to deal with responsive behaviours. So say you uploaded a large image into your media library of 2000px by 2000px. As usual WordPress would create 3 thumbnails automatically, small, medium and large.
Now say you chose to display a thumbnail in a post, the 1024px by 1024px thumbnail known as large. As you know you get a choice when selecting an image from the media library of which thumbnail to place or indeed, if you want, you can place the original image you uploaded.
So you chose to place the large thumbnail. If the post displays on a desktop then the image WordPress will display.
But if the post displays on a phone, WordPress will automatically swap out the large thumbnail for the tiny one of say 200px x200px to display when the device viewport is small, and it will choose the medium thumbnail of say 400px by 400px if the device is say an iPad.
This means you have a slightly lighter-weight page on smaller devices. As smaller devices tend to use slower networks when on the move, then this is a good thing.
The disadvantage with our method is that although we have set up the Genesis Club Pro plugin plugin to automatically create thumbnails for S3 images, it does not yet allow for their replacement with smaller thumbnails on smaller devices.
But as I am already uploading well-optimised images, and as the Genesis Club Pro plugin allows you to specify the quality of the thumbnails it generates, all the images you use are pretty well optimised already without having to swap in smaller images for smaller devices.
However we will at some point add a capability to make this responsive functionality also work with the GCPP.