Remove URL input fields for uploads and `fileStorage: false` config

[kevinansfield]

We'd like to remove the URL input option from our upload components to simplify the UI. This will have a knock-on effect of making the fileStorage: false config in Ghost rather useless as setting that config will make it impossible for users to change any of the image settings.

fileStorage: false predates the introduction of storage adapters in Ghost and was introduced as an escape valve for users not being able to use local storage. Now that storage adapters are available there aren't many use-cases for completely disabling file storage. Keeping all file uploads in ghost-controlled storage will also help further down the line as we introduce advanced media handling and optimisation.

• [x] remove URL input states from the uploader components in Ghost-Admin @kevinansfield
• [x] remove fileStorage conditionals in Ghost-Admin @kevinansfield
• [x] remove option to specify fileStorage: false in Ghost

[kevinansfield]

Closed via https://github.com/TryGhost/Ghost-Admin/issues/559 and https://github.com/TryGhost/Ghost/issues/8144

[Maxszik]

Does this mean that if I already have a blog with thousands of pictures, all being linked, they will all be gone and I'll have to re-upload them into ghost? That will make it impossible for me to upgrad to the new ghost. That sounds like absolute madness. Probably I've misunderstood this, I hope so -

[kevinansfield]

Does this mean that if I already have a blog with thousands of pictures, all being linked, they will all be gone and I'll have to re-upload them into ghost

Not at all, existing images will still work fine.

[nuclearpengy]

I assume this only impacts featured images and not images within a post.

Will this prevent linking to images saved on a CDN or served via a static cookieless host?

[kevinansfield]

This only affects the image upload UI, everything else to do with content image links and using CDNs via storage adapters is unaffected.

[pascalandy]

I asked on Slack and I would like to bring my question here.

---

I consider myself a Ghost power user. I really enjoy the fact that we can paste an URL when adding a picture with Ghost<=0.11.x.

This feature is REALLY useful for pictures in the header as I tend to re-use the same picture over many post & pages.

My question: How can we re-use header pictures across multiple pages/posts as we can't paste a URL anymore?

[kevinansfield]

My question: How can we re-use header pictures across multiple pages/posts?

At the moment re-upload them or if they are assets rather than per-post images then they probably make more sense being in the theme. In the future image re-use will likely be handled via an image library which is one of the reasons we're making the breaking change in UI now.

[pascalandy]

Alright, if have access to a library is in the a scope it totally make sense.

I'll create doubloon then. Thanks for the explanations :)

[nuclearpengy]

Thanks for the feedback Kevin.

Like @pascalandy, I also reuse images and love the current way of linking or uploading images for featured images, profile pictures etc. as it gives flexibility to link to images hosted on other services such as my own file server and avoids creating a messy file structure on the blog itself.

I guess, for self hosted blogs, we could add the image URL directly to the DB but for Ghost (Pro) blogs there isn't much that can be done.

[triestpa]

I agree with the concerns raised here. Being able to attach images as links is an essential feature in Ghost.

Here are the main reasons -

1. Using external image links allows for seamless transitions between local, staging, and production environments. Storing the images on each local file system will make it a mess to keep these environments in sync with each other.
2. All of my blog images are served from an S3 bucket behind a Cloudflare CDN, which makes them easier to manage and reuse, and reduces the I/O load on the blog server.
3. In order to scale the blog horizontally across multiple instances, it is essential for persistent content to be stored separately from the source code. Keeping a local image directory in-sync across multiple load-balanced servers will be difficult and impractical.

I understand that there are plans to add a complete in-app media management and optimization system, which I think is great. However, this system does not exist yet, and removing the option to link images is a major regression in the simplicity and flexibility that makes Ghost a great content platform.

@kevinansfield maybe it would help if I understood the reasoning behind the original decision. Why would allowing image URL linking limit the future potential of an integrated media manager? Shouldn't the database still store the image reference as a URL either way? Won't any predicted compatibility issues emerge in the future regardless of the UI changes, since 1.0 still supports JSON content imports with non-local image URLs?

Thank you for the hard work in preparing 1.0 for release, and for considering the above concerns.

[ErisDS]

The url option for uploading images has been removed from 1.0.0 and will not be making a return in its old form. The code complexity & maintenance overhead created by this feature simply didn't meet up with the usefulness it provided. In future we'll be revisiting this in order to create a more complete set of image management and optimisation tools.

I appreciate the concerns of the people writing on this thread, and wanted to address a couple of them.

For those of you concerned about migrating between environments, Ghost stores relative URLs, and therefore as long as you aren't changing between two environments in which the subdirectory changes you will be able to migrate seamlessly.

If you were making use of this feature to implement a CDN, please instead look at using a custom storage adapter.

Anyone who was using this as a way to work around missing features inside of Ghost, such as reusing images or creating size variations, I hope you'll bare with us. We know these issues exist and they are rising closer to the top of the todo list every day 😊

If this feature is a must-have for you, you are free to stay on Ghost LTS for the time being. We are planning to set the end of life for LTS to around 6 months from the release of 1.0.0, but more information about this will be available soon.

[triestpa]

@ErisDS Thanks for the explanation. I completely understand the need to reduce maintenance overhead. This probably means I'll be indefinitely putting off the upgrade to 1.0, at least until I bite the bullet and build a custom storage adapter to interface with the CDN.

---

Quick question - Is it likely that custom storage adapters be supported in the long-term for 1.0?

Also, is it possible that the new image management tools will allow using external image links? Or is the ability to include non-local images in Ghost being deprecated permanently?

---

In regards to migrating between environments unfortunately storing relative URLs doesn't really help, since the core issue is still keeping the file-systems in sync between environments.

Managing hundreds of images in a Git repo can get ugly, and makes it difficult for a design/marketing team to browse blog media and make quick changes without engineering assistance.

On the flip side, manually updating the images within each environment using an FTP client or the Admin UI is tedious, and makes it very easy for less-noticeable changes(such as image compression) to be applied inconsistently across environments.

Storing images in a location(such as a CDN) that is completely decoupled from the database, server, and source code versioning is an easy solution to this issue IMO, and is especially important for organization blogs and websites.

---

Again, thank you for the explanation, and for taking these concerns into account.

[ErisDS]

Is it likely that custom storage adapters be supported in the long-term for 1.0?

Custom storage adapters have been supported since ~0.5.0. Since then they have been overhauled and in 1.0.0 the concept of adapters was upgraded to a first-class citizen so that we can leverage this concept long term as a kind of required-at-boot app or plugin.

TLDR yes, they will be supported long term.

[twigs67]

Is there any ETA on this? This is really kind of a bummer that this isn't a feature.