I have used a platform called Ghost for writing blogs off and on for over five years now. There is a conversation that is still occurring there since it was brought up initially in 2013.
Ghost CMS is designed for writers by those with a passion for writing. One of the issues is that it allows for image use, but doesn't take into consideration that people will likely upload images that are unnecessarily too large.
I would argue, based on the experience of working with my clients, most writers do not understand the more delicate points of optimizing for the website, let alone images.
Other CMS (Content Management Service) have figured this out. WordPress has multiple solutions one can add in. Many times these rely on Imagemagik or other language-specific libraries.
Ghost is still a somewhat new CMS when compared to the likes of WordPress. The following is much smaller in comparison. It doesn't excuse a discussion about the architecture hasn't taken place.
I recently wrote in support of a forum submission in the community forums that I am surprised this still hadn't been addressed. For the first time in some time, I had a real response.
It's very much on our radar and has been discussed internally a number of times but no quick-win has emerged so far. Unfortunately we don't have the resources to tackle it just yet, it's a very large project to implement well and in a way that works across the huge variety of Ghost install environments and use-cases.
You can add your vote/input to the related feature requests on our Ideas board that we'll be referencing when we do get to the design & implementation stage:
From the outside, reading this statement appears to be more about a paralysis through analysis. Looking for a quick-win that can work across multiple platforms is far-reaching, but not starting is losing fans to other platforms.
In the meantime, other content management systems, including some that are much newer than Ghost, created an ability to at the minimum do an image resize. Other's even put in media management systems, and in less time than Ghost has been around.
Every time I consider moving back to Ghost CMS, I find the same issue awaiting me - work with Ghost and the writing platform I prefer and either deal with issues and workarounds, or move to another platform that does it and more.
I'm testing Ghost from my own hosted solution before paying for Ghost (Pro). Before getting into Ghost (Pro) and setting up a pay account, I want to make sure I am will to deal with it.
WordPress is more than I need, and I am looking for a more uncomplicated service for my writing. But I know the platform and the core very well, so there is a comfort level.
Duda is an excellent platform which has a blogging function making it a nice place to work on a managed platform quickly. It comes with media management and gives access to every page.
Publii allows a static website generated on any static host from GitHub to Google Cloud Storage to Netlify. The images are automatically resized and use VueJS to develop and manage the site.
There are certainly many more solutions out there including some great headless services.
Are you going to complain, or do you offer solutions?
Certainly, I come from a solutions background.
Starting with an overall view of the platform use is a great place to start when architecting solutions.
Identify what architectures Ghost run on and to what percentage is a great place to analyze where to start and to target initially.
Perhaps the initial could focus on supporting Ghost (Pro).
The next solution could host on the local system and then build out from there.
To make it easier for other developers to help, publishing a hook system could create ways to extend to support individual cases - S3, Google Cloud Storage, etc.
Seeing the platforms identified with Apache vs Nginx, Linux vs Windows vs MacOS, and understanding responses from a Platform poll can help provide a good development roadmap.
Great what direction would you go?
[install_dir]/images/example.png [install_dir]/images/responsive/example-small.png [install_dir]/images/responsive/example-medium.png [install_dir]/images/responsive/example-large.png
If at any time the files don't seem to be working correctly, using a regenerate responsive image could be enacted, allowing for the images to size properly.
Another reason the images may need a regeneration is an application of new image size descriptions, e.g. - small = 400x400 instead of 360x360.
Where would you start?
I would suggest of course to build first a lab element that has a resized image on upload option for max width and height for small, medium, and large. This should cover everyone rather equally on their specific platforms.
A significant first step with some NodeJS solutions available already.
Sharp by PixelPlumbing would a great candidate, being faster than native Imagemagick libraries. It would also give a first step trial that has a recovery mechanism for those that might run into issues using the resize.
After an image resize toggle, I would like to see a responsive image insert that supports srcset tags.
This could be put into a handbar function that automatically takes local images and outputs a templated
<img> tag. This would replace my direct
<img> work around I use.
A media management system is more complex, but there are many solutions out there. Look at the one that serves 80% of the use cases and go from there.
You have a workaround?
In fact, I do. I am currently using a two-prong approach.
Unsplash is a great platform I use, and they provide a way to pull sized images from their platform. I open up images in a new tab and can see the URL information they use to pull specific sizes.
In the URL above,
&w=1080 designates the size of the image to be pulled. I put this into an tag to designate the sizes for the initial src location, and the other resulting srcset image sizes as follows:
<img src="https://images.unsplash.com/photo-1421885568509-8d5319e54d89?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=057c864ca2bdb96ae14c270567b62bcc&auto=format&fit=crop&w=400&q=80" srcset="https://images.unsplash.com/photo-1421885568509-8d5319e54d89?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=057c864ca2bdb96ae14c270567b62bcc&auto=format&fit=crop&w=800&q=80 800w, https://images.unsplash.com/photo-1421885568509-8d5319e54d89?ixlib=rb-0.3.5&ixid=eyJhcHBfaWQiOjEyMDd9&s=057c864ca2bdb96ae14c270567b62bcc&auto=format&fit=crop&w=1200&q=80 1200w" alt="Ghost">
The second mechanism uses an identical solution from Google Cloud which uses
get_serving_url() through Google's App Engine API. Google uses this same function on Google Photos and extends into Google Cloud Storage.
These are my workarounds but YMMV, and I would not consider this to be a solution for everyone.
The first step is the hardest. The first step is the easiest.
It is easy to sit outside of an organization and give criticism and offer should opinions. I recognize I don't know all they are considering at Ghost.
I also recognize that Ghost is very responsible organization working with a very accountable and transparent development team. The fact that they are taking a responsible step in reviewing solutions for working with images says much about them. They are trying to consider everyone with their answer.
The hard part is that there are not any simple solutions for a responsible organization, but there are ways to identify how and where to start building as I listed above.
I do hope that there might be a point that we can create a reliable solution in Ghost CMS. It is a platform I have returned to often and for a good reason. I do want to see it's success.
Want to vote on Ghost images and media management?
More on Ghost CMS
Subscribe to Darren by Design
Get the latest posts delivered right to your inbox