Skip to content
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

Refactor: fetch image dimensions from local file storage #8900

Merged

Conversation

aileen
Copy link
Member

@aileen aileen commented Aug 15, 2017

refs #8868

  • don't fetch icon sizes for blog logo within meta data anymore and make it synchronous

Refactors the getImageSizeFromUrl:

  • Renamed file to image-size.js
  • Added second fn getImageSizeFromFilePath that reads from local file storage
  • Added guard in getImageSizeFromUrl that checks if the image should be on local file storage and uses the new fn then instead
  • Added tests for new fn
  • Added a fn fetchDimensionsFromBuffer that takes the file buffer and returns an imageObject with dimensions.
  • Added a new util getLocalFileStoragePath which takes an image URL or filepath and sanitizes it so it's readable for the storage.

TODOS:

  • make tests work
  • implement logic in image-dimensions fn / think of a smarter way to differentiate when to read from local file storage and when via request

@aileen aileen force-pushed the refactor-image-size-use-local-storage branch 3 times, most recently from 9a10cf0 to ef5a212 Compare August 29, 2017 10:02
@aileen aileen changed the title [WIP] 🔥 Refactor: fetch image dimensions from local file storage Refactor: fetch image dimensions from local file storage Aug 29, 2017
@aileen
Copy link
Member Author

aileen commented Aug 31, 2017

@kirrg001: if this looks good to you, I actually think that it would make sense to try and get this into LTS as well? What do you think?

@kirrg001
Copy link
Contributor

Can please you rebase? 🙏🏽

@aileen aileen force-pushed the refactor-image-size-use-local-storage branch from ef5a212 to d1f6130 Compare August 31, 2017 10:33
@aileen
Copy link
Member Author

aileen commented Aug 31, 2017

Done @kirrg001!!

@@ -29,9 +29,16 @@ var sizeOf = require('image-size'),
* @returns {Promise<Object>} imageObject or error
*/
module.exports.getImageSizeFromUrl = function getImageSizeFromUrl(imagePath) {
<<<<<<< HEAD

This comment was marked as abuse.

@@ -1,103 +0,0 @@
// Supported formats of https://github.com/image-size/image-size:

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.


return Promise.props(getBlogLogo()).then(function (result) {
metaData.blog.logo = result;
metaData.blog.logo = getBlogLogo();

This comment was marked as abuse.

imagePath = imagePath.replace(new RegExp('^' + utils.url.urlJoin(utils.url.urlFor('home', true), utils.url.getSubdir(), '/', utils.url.STATIC_IMAGE_URL_PREFIX)), '');

return storage.getStorage()
.read({path: imagePath})

This comment was marked as abuse.

imageObject.url = imagePath;

// storage needs the path without `/content/images/` prefix
imagePath = imagePath.replace(new RegExp('^' + utils.url.urlJoin(utils.url.urlFor('home', true), utils.url.getSubdir(), '/', utils.url.STATIC_IMAGE_URL_PREFIX)), '');

This comment was marked as abuse.

This comment was marked as abuse.

config = require('../config'),
storage = require('../adapters/storage'),
_ = require('lodash'),
dimensions,

This comment was marked as abuse.

return got(
imagePath,
requestOptions
).then(function (response) {

This comment was marked as abuse.

This comment was marked as abuse.

@kirrg001
Copy link
Contributor

kirrg001 commented Sep 4, 2017

I wonder, if it was discussed at any point to rather fetch and store the dimensions in the database when storing the image? (Could be a simple look up table url -> dimensions). I was unable to find a discussion. Because even with this PR, we can run into timeouts which block the frontend request.

Plus the concern i've raised here #8900 (comment), which describes that blogs are using e.g. the s3 storage adapter and not sure the performance is better than querying the dimensions via the s3 lib. Was that considered/tested?

@aileen aileen force-pushed the refactor-image-size-use-local-storage branch from d1f6130 to 8a6547b Compare September 4, 2017 12:02
@aileen
Copy link
Member Author

aileen commented Sep 4, 2017

I wonder, if it was discussed at any point to rather fetch and store the dimensions in the database when storing the image? (Could be a simple look up table url -> dimensions).

I remember this was being discussed before the very first implementation but then decided to wait for the image optimisation first.

Re: possible timeouts when people are using a custom storage adapter like S3 wasn't discussed. Maybe this should be discussed and considered first before we proceed with this PR?

@aileen aileen force-pushed the refactor-image-size-use-local-storage branch 6 times, most recently from 720ef9d to 7364e4c Compare September 5, 2017 10:20
@aileen
Copy link
Member Author

aileen commented Sep 5, 2017

Re: possible timeouts when people are using a custom storage adapter like S3 wasn't discussed. Maybe this should be discussed and considered first before we proceed with this PR?

We decided that reading from the local file storage would overweight the benefits for users who don't use a custom storage adapter. We'll therefore merge this change and are happy for contributions if improvements for custom storage adapters are needed.

* @description Takes a url or filepath and returns a filepath with is readable
* for the local file storage.
*/
function getLocalFileStoragePath(imagePath) {

This comment was marked as abuse.

This comment was marked as abuse.

refs TryGhost#8868

- Removed image-size in blog logo fn for meta data and made it synchronous
- Renamed `image-size-from-url.js` to `image-size.js` (incl. the test)
- Added second fn `getImageSizeFromFilePath` that reads from local file storage
- Added guard in `getImageSizeFromUrl` that checks if the image should be on local file storage and uses the new fn then instead
- Added a fn `fetchDimensionsFromBuffer` that takes the file buffer and returns an `imageObject` with dimensions.
- Added a new util directory in `adapters/storage` and there a new fn `getLocalFileStoragePath` which takes an image URL or filepath and sanitizes it so it's readable for the storage.
@aileen aileen force-pushed the refactor-image-size-use-local-storage branch from 7364e4c to b9dc7e3 Compare September 5, 2017 11:29
@kirrg001 kirrg001 merged commit eef7932 into TryGhost:master Sep 5, 2017
@ErisDS
Copy link
Member

ErisDS commented Sep 5, 2017

I wonder, if it was discussed at any point to rather fetch and store the dimensions in the database when storing the image? (Could be a simple look up table url -> dimensions). I was unable to find a discussion. Because even with this PR, we can run into timeouts which block the frontend request.

At some point we may move towards using a different cache, but not just yet - there are a couple of other things that need to become clearer with regard to images

Plus the concern i've raised here #8900 (comment), which describes that blogs are using e.g. the s3 storage adapter and not sure the performance is better than querying the dimensions via the s3 lib. Was that considered/tested?

Users with custom storage adapters are welcome to submit improvements that make this work/perform better for them - I think our focus should always be on the default case 😊

aileen added a commit to aileen/Ghost that referenced this pull request Sep 7, 2017
no issue

Adds redirect test back, which was accidentially removed with PR TryGhost#8900
ErisDS pushed a commit that referenced this pull request Sep 7, 2017
no issue

Adds redirect test back, which was accidentially removed with PR #8900
@aileen aileen deleted the refactor-image-size-use-local-storage branch October 13, 2017 08:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants