New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
kevinansfield opened this Issue Feb 21, 2017 · 13 comments

Comments

Projects
None yet
7 participants
@kevinansfield
Contributor

kevinansfield commented Feb 21, 2017

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.

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

kevinansfield added a commit to kevinansfield/Ghost-Admin that referenced this issue Mar 3, 2017

🔥 remove URL input option from image upload components
refs TryGhost/Ghost#8032
- `fileStorage: false` config is going away, it predates storage engines and will simplify future image optimisation work
- simplifies UI, it can be brought back in the future in a more robust fashion if required

acburdine added a commit to TryGhost/Ghost-Admin that referenced this issue Mar 3, 2017

🔥 remove URL input option from image upload components
refs TryGhost/Ghost#8032
- `fileStorage: false` config is going away, it predates storage engines and will simplify future image optimisation work
- simplifies UI, it can be brought back in the future in a more robust fashion if required

kirrg001 added a commit to kirrg001/Ghost that referenced this issue Mar 13, 2017

🔥 remove fileStorage option
refs TryGhost#8032

- this was used to disable the upload image functionality in Ghost-Admin
- we no longer need this boolean, because people can add their own storage adapter

kevinansfield added a commit that referenced this issue Mar 14, 2017

🔥 remove fileStorage option (#8144)
refs #8032

- this was used to disable the upload image functionality in Ghost-Admin
- we no longer need this boolean, because people can add their own storage adapter
@kevinansfield

This comment has been minimized.

Contributor

kevinansfield commented Mar 14, 2017

@Caucasus-and-Mercury

This comment has been minimized.

Caucasus-and-Mercury commented Jul 3, 2017

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

This comment has been minimized.

Contributor

kevinansfield commented Jul 3, 2017

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

This comment has been minimized.

nuclearpengy commented Jul 3, 2017

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 comment has been minimized.

Contributor

kevinansfield commented Jul 4, 2017

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

@pascalandy

This comment has been minimized.

pascalandy commented Jul 4, 2017

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

This comment has been minimized.

Contributor

kevinansfield commented Jul 4, 2017

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

This comment has been minimized.

pascalandy commented Jul 4, 2017

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

This comment has been minimized.

nuclearpengy commented Jul 5, 2017

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

This comment has been minimized.

triestpa commented Jul 22, 2017

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

This comment has been minimized.

Member

ErisDS commented Jul 25, 2017

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

This comment has been minimized.

triestpa commented Jul 25, 2017

@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

This comment has been minimized.

Member

ErisDS commented Jul 25, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment