Media Library - Manage all files in one place


#1

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:


Is ghost are good for SEO?
#2

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.


#3

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.


#4

Yeah fully! The -2 -3 is annoying.


#5

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


#6

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


#7

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.


Remove old unused images
Attachments in sites/posts
#8

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 :slight_smile:


#9

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.


#10

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.


#11

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?

#12

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


#13

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.


Duplicated image for different articles