Better image/file management & optimisation

A nice thing to see in the future would be a place to manage all your photos and files that you upload. At this moment we can only upload pictures to our server or select an external one with Unsplash App. Some interesting features would be:

  1. Delete an image - Right now we can’t delete a picture unless we go in content/images folder and delete it manually.
  2. Define image sizes - Some themes, including Casper, have a list of posts that can show the featured image in loop. Unfortunately we have to show the full size of the image in there. That might be slow in some cases.
  3. Multiple file extentions - Upload videos, pdfs, webp and other type of files. Right now only .GIF, .JPG, .JPEG, .PNG, .SVG are supported.
  4. Images management - See all your uploaded images and search for a desired picture.
  5. Reusability - Ability to reuse an uploaded image. Now we need to upload it again if we want to set it as a featured image.
  6. Manipulate - Be able to crop, resize, rotate, apply filter effects, etc.

and more …

The list is crazy, of course, and it would take a huge amount of time to deliver something like this. I’m not sure if all the ideas are good or should be implemented as core features. Manipulate could be done by user on local or by an App.

The first 2, personally, I think that are the most important.

I’m pretty sure there are more features that people would love to see but there are not in this list. Feel free to list anything here :slight_smile:

I think media library > no media library so it might be good to aim for a simpler V1 and maybe only cater for adding and deleting media. No fancy functions. That alone would streamline image management.

As part of the deployment, I think there needs to be a “scan my content” feature, which scans the uploads folder for existing media and then adds it to the library so that both existing and new media can be managed from the same user interface.

Once V1 of the media manager is released, additional features could be rolled out as upgrades.

5 Likes

Definitely a basic Media Library should be at first. I simply listed a lot of features that might be interesting to see or discuss in this thread. If the first version of the library lets you delete images, that would be great, because we can get rid of the junk photos that we have now on our servers. And be able to upload images with the desired name, not with -2, -3 suffix.

1 Like

Yeah fully! The -2 -3 is annoying.

I currently FTP in and manage images directly on the server to work around the -2 -3 issue.

From a user-friendliness standpoint, at a bare minimum for sure need the ability to delete uploaded media files without having to ssh to the server

4 Likes

There should be some way of seeing which posts and pages the image is used in from the Media Library screen. If the image is renamed or deleted, at a minimum the user should be warned that the related posts will be affected. Going further, an option could be given to automatically update the Markdown image tag in the related post when a renaming takes place.

It would also be nice to have the option to change the location where the image is saved so that we can have smaller image namespaces (thus reducing the likelihood of the -2 -3 problem occurring). Currently images are located at domain.com/content/images/year/month/image.jpg, where year and month reflect the time that the image was first uploaded. However, from a users perspective, I’m more interested in seeing the image URL match the publish date and name of the article or the name of the page, e.g. domain.com/year/month/day/post-name/image.jpg or domain.com/page-name/image.jpg unless the image is intended to be shared across multiple posts. More often than not images don’t need to be shared between posts, yet they’re scoped using a shared namespace.

2 Likes

Keep in mind that the media deduplication is storage adapter specific. If you use the default local storage, it will try to find an unique name instead of override an existing media name.

This behaviour could be very easily undone if you edit the storage adapter and the code snippet that does that. If you use external storage adapter (AWS S3, Cloudinary, etc.), you can mostly choose how duplication is handled.

For instance, with Cloudinary, you can chose to reuse, override or create a conflict-free name of the image.

Most external storage adapters have the ability to delete an image but Ghost does not provide a UX mean for this action. Maybe some day :)

Bear in mind that bringing deduplication, media swaps/re-uploads, deletion, and other advanced features into a media library will have compounding complexity as other features are added to Ghost later on.

If (when :smile:) post versioning/edit history is added you’ll still need old images to be around otherwise the ability to roll back changes is severely limited. There will also be issues with swapping images out - if you swap an image via the media library that is used in multiple posts should there be a changelog created for all posts that use it? How is this then managed across all of the different storage engines that are available?


I think it’s much more useful to focus on use cases in these Ideas topics otherwise it’s far too easy to jump to quickly thought-out solutions that mask the real reason for suggesting a feature.

Post what you were you trying to accomplish (and why) when you ran into something that wasn’t possible or was difficult to achieve with what’s available in Ghost at the moment - that will help guide feature design and prevent these topics becoming giant developer-focused wishlists.

4 Likes

I’d start as simply as possible. The major use case I’d like to see supported is easy browsing, finding and reusing of existing images. It’s the only thing I’ve really missed since moving from WP.

2 Likes

The use cases I’ve come across are:

  • As a visitor, when saving an image from a Ghost site to my local PC, the file name is my-image-2.jpg rather than my-image.jpg. An initial thought is “what happened to the first image”? A number on the end of the image file name implies that there is an existing sequence of images that I can view.
  • As a visitor, when right clicking and opening an image directly in a new tab, the year that the image was uploaded appears in the URL. The image was uploaded in 2018, but the post that contains the image is dated 2002. As a user, I am confused that this years is in the URL rather than the year of the post.
  • As an author, after uploading an image, and discovering that it has the wrong or misleading name, there is no way to rename that image (without uploading it again). What if the file name described different content than what was in the image?
  • As an author, after uploading the wrong image accidentally, I discovered that there was no way to delete the image. What if that image had been private and not intended to be shared with other authors or admins of the blog?

I’m curious as to whether this is a problem your visitors have raised with you or something you’ve noticed yourself as a developer? Most sites these days will have very random looking image names that can also look like a series (I checked Twitter, Facebook, BBC News, The Guardian quickly, all of them have random image names or images that look like a series).

If you’re replacing an image it’s important that the name changes in order to ensure that caches update - Ghost by default adds 1-year expiry headers to images so a straight swap wouldn’t necessarily cause visitor’s browsers, CDNs, other caches etc to update.

Would you be happier with random image names? That would likely need to happen in the future anyway once automatic compression and image resizing is in place (see the Automatic thumbnailing/resizing of image uploads Ideas topic)

As a visitor, when right clicking and opening an image directly in a new tab, the year that the image was uploaded appears in the URL. The image was uploaded in 2018, but the post that contains the image is dated 2002. As a user, I am confused that this years is in the URL rather than the year of the post.

Again, I’m curious to hear if this is a complaint your visitors have raised or something you’ve noticed as a developer. It’s the first time I’ve heard about this being a problem.


It’s also worth noting that both of the above issues can be resolved right now if they are real problems on your site by using a custom storage adapter set to match your site’s requirements

These are things I’ve noticed when using Ghost, but they can be noticed by non-developers when using common features of the web browser. For example, a direct link to an image could be pasted directly into an email or forum post; in those cases, readers will see the direct image URL.

One counter example is Wikipedia, which generally has meaningful image file names. E.g.

https://en.wikipedia.org/wiki/Ghost#/media/File:Athenodorus_-_The_Greek_Stoic_Philosopher_Athenodorus_Rents_a_Haunted_House.jpg

Yes, because a hash of random characters implies the lack of meaning, whereas a sequence number or date implies meaning where meaning might not be.

You could use a hash in the folder name (e.g. /oipq5mh6yf/my-image.jpg) so that the file name remains clean. Another option (for caching purposes only, not for uniqueness) is that Ghost could add a hash as a parameter on the end of the URL automatically, e.g. my-image.jpg?oipq5mh6yf.

Another consideration with handling images from older post revisions is whether the images used in those revisions should still be publicly accessible via their existing URL. If I delete or replace an image, and the old image is still publicly accessible via the same URL, that may not be intended by the author. So there may be value in moving images that are no longer found in current post revisions to a private location.

This is definitely a good idea. Now with the new Koenig editor it’d be every so useful. I saw someone mentioning Cloudinary - I also believe that this would be a great addition. Having all my images in Cloudinary and be able to include them in an easy fashion (i.e. by selecting one or multiple images) would be a great help. Furthermore using a tool such as Cloudinary means that image optimisation/transformation can be done with ease.

2 Likes

Do you consider to add a support of third-party file storages soon? For example, Dropbox, Imgur, PDFfiller https://edit-pdf.pdffiller.com/ and so on? It would be very promising

i think not just media library, but also can manage/add/edit/delete any files. U know what i mean, it “File Manager”.

1 Like

I think one functionality that should be present in the media/file library/manager should complement this:
https://docs.ghost.org/faq/the-importer/

I mean a download option of your entire image archive so that you can move your blog much easier from one server to another. On the other side, an import option would be great as well to recreate the content/images folder identically to the previously downloaded version.

As a newcomer to Ghost, the use case I missed immediately was image re-use. I uploaded an image to one post. Then in a subsequent post wanted to use the same image and now I have to re-upload it. Most other systems I’ve used allow me to browse and select. (As a developer, I know how to go to the content dir and find the image name and insert it via html or markdown – but as a user I shouldn’t have to. And on a Ghost-Pro install, I don’t seem to have access to my content dir, so that’s out.)

1 Like

We’ve made a lot of progress with better image support in Ghost this year. That said, this issue has become a bit of a dumping ground for just about anything related to media, up to and including the kitchen sink :upside_down_face:

I’m going to run through the main things that have been talked about and wrap this topic up, because the majority of them have been completed at this stage. If anyone wants to start new, more specific, ideas topics after this - that’s absolutely fine!


Things that have been done & shipped

  • :white_check_mark: New editor/image uploader
  • :white_check_mark: Image output size control
  • :white_check_mark: Image re-usability with simple copy/paste
  • :white_check_mark: New image caption support
  • :white_check_mark: New dynamic image gallery cards
  • :white_check_mark: Automatic image compression & optimisation
  • :white_check_mark: Dynamic responsive image sizes
  • :white_check_mark: Drag/drop image re-ordering
  • :white_check_mark: Cloudinary integration guide
  • :white_check_mark: Amazon S3 storage adapter guide
  • :white_check_mark: Google Drive storage adapter guide
  • :white_check_mark: Azure storage adapter guide
  • :white_check_mark: Google cloud storage adapter guide
  • :white_check_mark: Backblaze storage adapter guide
  • :white_check_mark: Custom integration guide

https://docs.ghost.org/integrations/cloudinary/

https://docs.ghost.org/integrations/amazon-s3/

https://docs.ghost.org/integrations/google-drive/

https://docs.ghost.org/integrations/azure-storage/

https://docs.ghost.org/integrations/google-cloud-storage/

https://docs.ghost.org/integrations/backblaze/

https://docs.ghost.org/integrations/custom-integrations/


Things we’re not going to do

:no_entry: Short term renaming/deleting of images

TLDR: It’s a lot of work to implement for no discernible benefit. Storage is extremely cheap, and filename has no impact on image output. Most platforms scramble filenames to a hash, so no matter what you upload it ends up being rendered as /images/34khds92lk20990923klnsd.jpg - generally speaking you just don’t need to worry about it.


Things we might do eventually

:warning: A simple, minimal file browser

We may at some point create a very light file management UI within Ghost Admin for images. This isn’t a priority, because the only real use-case is for managing images which will be regularly re-used, such as a set of corporate brand assets. Beyond that, it’s just an incredible amount of work for very little reward.

A file browser UI is something that can be voted for on a new topic, but will likely not be implemented unless someone from the open source community decides to build it themselves and contribute upstream.

6 Likes