TryGhost/Ghost
1
0
Fork 0
mirror of https://github.com/TryGhost/Ghost.git synced 2024-12-23 10:53:34 +03:00
Code Issues Projects Releases Wiki Activity
a9e668a949
Ghost/core/test/unit/metadata/image-dimensions_spec.js

333 lines
14 KiB
JavaScript
Raw Normal View History

💄 🐷 Test consistency (#8199) no issue - change out should.equal for // jshint ignore:line - ensure should is the first require in every test, and ALWAYS require - make sinon the second require, and sandbox the last thing - ALWAYS use sandbox, futureproofs tests against contributors who don't know it - change require formatting
2017-03-21 11:24:11 +03:00
var should = require('should'),
sinon = require('sinon'),
rewire = require('rewire'),
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
// Stuff we are testing
💄 🐷 Test consistency (#8199) no issue - change out should.equal for // jshint ignore:line - ensure should is the first require in every test, and ALWAYS require - make sinon the second require, and sandbox the last thing - ALWAYS use sandbox, futureproofs tests against contributors who don't know it - change require formatting
2017-03-21 11:24:11 +03:00
getImageDimensions = rewire('../../../server/data/meta/image-dimensions'),
getCachedImageSizeFromUrl = rewire('../../../server/utils/cached-image-size-from-url'),
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
sandbox = sinon.sandbox.create();
describe('getImageDimensions', function () {
var sizeOfStub;
beforeEach(function () {
sizeOfStub = sandbox.stub();
});
afterEach(function () {
sandbox.restore();
getCachedImageSizeFromUrl.__set__('imageSizeCache', {});
});
it('should return dimension for images', function (done) {
var metaData = {
coverImage: {
url: 'http://mysite.com/content/image/mypostcoverimage.jpg'
},
authorImage: {
url: 'http://mysite.com/author/image/url/me.jpg'
},
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
ogImage: {
url: 'http://mysite.com/content/image/super-facebook-image.jpg'
},
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
blog: {
logo: {
url: 'http://mysite.com/author/image/url/logo.jpg'
}
}
};
sizeOfStub.returns({
width: 50,
height: 50,
type: 'jpg'
});
getImageDimensions.__set__('getCachedImageSizeFromUrl', sizeOfStub);
getImageDimensions(metaData).then(function (result) {
should.exist(result);
sizeOfStub.calledWith(metaData.coverImage.url).should.be.true();
sizeOfStub.calledWith(metaData.authorImage.url).should.be.true();
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
sizeOfStub.calledWith(metaData.ogImage.url).should.be.true();
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
sizeOfStub.calledWith(metaData.blog.logo.url).should.be.true();
result.coverImage.should.have.property('dimensions');
result.coverImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.coverImage.dimensions.should.have.property('width', 50);
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.coverImage.dimensions.should.have.property('height', 50);
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.authorImage.should.have.property('dimensions');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.authorImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.authorImage.dimensions.should.have.property('width', 50);
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.authorImage.dimensions.should.have.property('height', 50);
result.ogImage.should.have.property('dimensions');
result.ogImage.should.have.property('url');
result.ogImage.dimensions.should.have.property('width', 50);
result.ogImage.dimensions.should.have.property('height', 50);
result.blog.logo.should.have.property('dimensions');
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
result.blog.logo.should.have.property('url');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.blog.logo.dimensions.should.have.property('width', 50);
result.blog.logo.dimensions.should.have.property('height', 50);
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
done();
}).catch(done);
});
it('should return metaData if url is undefined or null', function (done) {
var metaData = {
coverImage: {
url: undefined
},
authorImage: {
url: null
},
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
ogImage: {
url: ''
},
twitterImage: {
url: null
},
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
blog: {
logo: {
url: 'noUrl'
}
}
};
sizeOfStub.returns({});
getImageDimensions.__set__('getCachedImageSizeFromUrl', sizeOfStub);
getImageDimensions(metaData).then(function (result) {
should.exist(result);
sizeOfStub.calledWith(metaData.coverImage.url).should.be.true();
sizeOfStub.calledWith(metaData.authorImage.url).should.be.true();
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
sizeOfStub.calledWith(metaData.ogImage.url).should.be.true();
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
sizeOfStub.calledWith(metaData.blog.logo.url).should.be.true();
result.coverImage.should.not.have.property('dimensions');
result.coverImage.should.have.property('url');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.authorImage.should.not.have.property('dimensions');
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
result.authorImage.should.have.property('url');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.ogImage.should.not.have.property('dimensions');
result.ogImage.should.have.property('url');
result.blog.logo.should.not.have.property('dimensions');
result.blog.logo.should.have.property('url');
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
done();
}).catch(done);
});
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
it('should not try to fetch image dimensions for logo if already set', function (done) {
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
var metaData = {
coverImage: {
url: 'http://mysite.com/content/image/mypostcoverimage.jpg'
},
authorImage: {
url: 'http://mysite.com/author/image/url/me.jpg'
},
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
ogImage: {
url: 'http://mysite.com/content/image/super-facebook-image.jpg'
},
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
blog: {
logo: {
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
url: 'http://mysite.com/author/image/url/favicon.ico',
dimensions: {
width: 60,
height: 60
}
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
}
}
};
sizeOfStub.returns({
width: 480,
height: 80,
type: 'jpg'
});
getImageDimensions.__set__('getCachedImageSizeFromUrl', sizeOfStub);
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
getImageDimensions(metaData).then(function (result) {
should.exist(result);
sizeOfStub.calledWith(metaData.coverImage.url).should.be.true();
sizeOfStub.calledWith(metaData.authorImage.url).should.be.true();
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
sizeOfStub.calledWith(metaData.ogImage.url).should.be.true();
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
sizeOfStub.calledWith(metaData.blog.logo.url).should.be.false();
result.coverImage.should.have.property('dimensions');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.coverImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.coverImage.dimensions.should.have.property('height', 80);
result.coverImage.dimensions.should.have.property('width', 480);
result.authorImage.should.have.property('dimensions');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.authorImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.authorImage.dimensions.should.have.property('height', 80);
result.authorImage.dimensions.should.have.property('width', 480);
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.ogImage.should.have.property('dimensions');
result.ogImage.should.have.property('url');
result.ogImage.dimensions.should.have.property('height', 80);
result.ogImage.dimensions.should.have.property('width', 480);
result.blog.logo.should.have.property('dimensions');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.blog.logo.should.have.property('url');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.blog.logo.dimensions.should.have.property('height', 60);
result.blog.logo.dimensions.should.have.property('width', 60);
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
done();
}).catch(done);
});
it('should fake image dimension for publisher.logo if .ico file is too big', function (done) {
var metaData = {
coverImage: {
url: 'http://mysite.com/content/image/mypostcoverimage.jpg'
},
authorImage: {
url: 'http://mysite.com/author/image/url/me.jpg'
},
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
ogImage: {
url: 'http://mysite.com/content/image/super-facebook-image.jpg'
},
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
blog: {
logo: {
url: 'http://mysite.com/author/image/url/favicon.ico',
dimensions: {
width: 128,
height: 128
}
}
}
};
sizeOfStub.returns({
width: 480,
height: 480,
type: 'jpg'
});
getImageDimensions.__set__('getCachedImageSizeFromUrl', sizeOfStub);
getImageDimensions(metaData).then(function (result) {
should.exist(result);
sizeOfStub.calledWith(metaData.coverImage.url).should.be.true();
sizeOfStub.calledWith(metaData.authorImage.url).should.be.true();
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
sizeOfStub.calledWith(metaData.ogImage.url).should.be.true();
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
sizeOfStub.calledWith(metaData.blog.logo.url).should.be.false();
result.coverImage.should.have.property('dimensions');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.coverImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.coverImage.dimensions.should.have.property('height', 480);
result.coverImage.dimensions.should.have.property('width', 480);
result.authorImage.should.have.property('dimensions');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.authorImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.authorImage.dimensions.should.have.property('height', 480);
result.authorImage.dimensions.should.have.property('width', 480);
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.ogImage.should.have.property('dimensions');
result.ogImage.should.have.property('url');
result.ogImage.dimensions.should.have.property('height', 480);
result.ogImage.dimensions.should.have.property('width', 480);
result.blog.logo.should.have.property('dimensions');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.blog.logo.should.have.property('url');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.blog.logo.dimensions.should.have.property('height', 60);
result.blog.logo.dimensions.should.have.property('width', 60);
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
done();
}).catch(done);
});
it('should fake image dimension for publisher.logo if non-.ico file is too big and square', function (done) {
var metaData = {
coverImage: {
url: 'http://mysite.com/content/image/mypostcoverimage.jpg'
},
authorImage: {
url: 'http://mysite.com/author/image/url/me.jpg'
},
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
ogImage: {
url: 'http://mysite.com/content/image/super-facebook-image.jpg'
},
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
blog: {
logo: {
url: 'http://mysite.com/author/image/url/favicon.png'
}
}
};
sizeOfStub.returns({
width: 480,
height: 480,
type: 'jpg'
});
getImageDimensions.__set__('getCachedImageSizeFromUrl', sizeOfStub);
getImageDimensions(metaData).then(function (result) {
should.exist(result);
sizeOfStub.calledWith(metaData.coverImage.url).should.be.true();
sizeOfStub.calledWith(metaData.authorImage.url).should.be.true();
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
sizeOfStub.calledWith(metaData.ogImage.url).should.be.true();
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
sizeOfStub.calledWith(metaData.blog.logo.url).should.be.true();
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.coverImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.coverImage.should.have.property('dimensions');
result.coverImage.dimensions.should.have.property('height', 480);
result.coverImage.dimensions.should.have.property('width', 480);
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.blog.logo.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.blog.logo.should.have.property('dimensions');
result.blog.logo.dimensions.should.have.property('height', 60);
result.blog.logo.dimensions.should.have.property('width', 60);
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.authorImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.authorImage.should.have.property('dimensions');
result.authorImage.dimensions.should.have.property('height', 480);
result.authorImage.dimensions.should.have.property('width', 480);
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.ogImage.should.have.property('url');
result.ogImage.should.have.property('dimensions');
result.ogImage.dimensions.should.have.property('height', 480);
result.ogImage.dimensions.should.have.property('width', 480);
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
done();
}).catch(done);
});
it('should not fake dimension for publisher.logo if a logo is too big but not square', function (done) {
var metaData = {
coverImage: {
url: 'http://mysite.com/content/image/mypostcoverimage.jpg'
},
authorImage: {
url: 'http://mysite.com/author/image/url/me.jpg'
},
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
ogImage: {
url: 'http://mysite.com/content/image/super-facebook-image.jpg'
},
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
blog: {
logo: {
url: 'http://mysite.com/author/image/url/logo.jpg'
}
}
};
sizeOfStub.returns({
width: 80,
height: 480,
type: 'jpg'
});
getImageDimensions.__set__('getCachedImageSizeFromUrl', sizeOfStub);
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
getImageDimensions(metaData).then(function (result) {
should.exist(result);
sizeOfStub.calledWith(metaData.coverImage.url).should.be.true();
sizeOfStub.calledWith(metaData.authorImage.url).should.be.true();
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
sizeOfStub.calledWith(metaData.ogImage.url).should.be.true();
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
sizeOfStub.calledWith(metaData.blog.logo.url).should.be.true();
result.coverImage.should.have.property('dimensions');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.coverImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.coverImage.dimensions.should.have.property('height', 480);
result.coverImage.dimensions.should.have.property('width', 80);
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
result.authorImage.should.have.property('dimensions');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.authorImage.should.have.property('url');
🙇 Blog icon utils and publisher.logo for JSON-LD (#8297) refs #8221, closes #7688, refs #7558 🙇 Improve meta data publisher logo behaviour This is a follow-up PR for #8285. Reasons: The code changes of #8285 caused error messages when falling back to the default `favicon.ico`, as the `image-size` tool doesn't support `ico` files. This PR takes the logic to decide which logo needs to be listed in our schema into a new fn `blog_logo.js`. There we have now three decisions: 1. If we have a publication **logo**, we'll take that one 2. If we have no publication logo, but an **icon** we'll use this one. 3. If we have none of the above things, we fall back to our default `favicon.ico` Additional, we're hard coding image dimensions for whenever the logo is an `.ico` file and built and extra decision to not call `image-size` when the dimension are already given. I will create another follow-up PR, which checks the extension type for the file and offers it as a util. 🛠 Blog icon util refs #7688 Serve functionality around the blog icon in its own util: - getIconDimensions -> async function that takes the filepath of on ico file and returns its dimensions - isIcoImageType -> returns true if file has `.ico` extension - getIconType -> returns icon-type (`x-icon` or `png`) - getIconUrl -> returns the absolut or relativ URL for the favicon: `[subdirectory or not]favicon.[ico or png]` 📖 Get .ico sizes for meta data & logo improvement refs #7558 refs #8221 Use the new `blogIconUtil` in meta data to fetch the dimensions of `.ico` files. Improvements for `publisher.logo`: We're now returning a hard-coded 'faked' image dimensions value to render an `imageObject` and prevent error our schema (Google structured data). As soon as an image (`.ico` or non-`.ico`) is too large, but - in case of non-`.ico` - a square format, be set the image-dimensions to 60px width and height. This reduces the chances of getting constantly error messages from Googles' webmaster tools. - add getIconPath util
2017-04-11 19:32:06 +03:00
result.authorImage.dimensions.should.have.property('height', 480);
result.authorImage.dimensions.should.have.property('width', 80);
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.ogImage.should.have.property('dimensions');
result.ogImage.should.have.property('url');
result.ogImage.dimensions.should.have.property('height', 480);
result.ogImage.dimensions.should.have.property('width', 80);
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
result.blog.logo.should.have.property('url');
✨ Facebook and Twitter data per post feature (#8827) closes #8334 - adds title, image and description to structured data to be rendered as open graph and twitter data. - if meta title and description for a post exists already, the custom structured data will overwrite those for `og:` and `twitter:` data. `JSON-LD` (Schema.org`) is not affected and will stay the same. - adds tests - adds new og and twitter fields to schema incl. migration
2017-08-03 14:48:39 +03:00
result.blog.logo.should.not.have.property('dimensions');
✨ [FEATURE] AMP⚡ (#7229) closes #6588, #7095 * `ImageObject` with image dimensions (#7152, #7151, #7153) - Returns meta data as promise - returns a new Promise from meta data - uses `Promise.props()` to resolve `getClient()` and `getMetaData()` - Adds 'image-size' util The util returns an object like this ``` { height: 50, url: 'http://myblog.com/images/cat.jpg', width: 50 }; ``` if the dimensions can be fetched and rejects with error, if not. In case we get a locally stored image or a not complete url (like `//www.gravatar.com/andsoon`), we add the protocol to the incomplete one and use `urlFor()` to get the absolute URL. If the request fails or `image-size` is not able to read the file, we reject with error. - adds 'image-size' module to dependencies - adds `getImageSizeFromUrl` function that returns image dimensions - In preparation of AMP support and to improve our schema.org JSON-LD and structured data, I made the following changes: - Changes the following properties to be `Objects`, which have a `url` property by default and a `dimensions` property, if `width` and `height` are available: - `metaData.coverImage` - `metaData.authorImage` - `metaData.blog.logo` - Checks cache by calling `getCachedImageSizeFromUrl`. If image dimensions were fetched already, returns them from cache instead of fetching them again. - If we have image dimensions on hand, the output in our JSON-LD changes from normal urls to be full `ImageObjects`. Applies to all images and logos. - Special case for `publisher.logo` as it has size restrictions: if the image doesn't fulfil the restrictions (<=600 width and <=60 height), we simply output the url instead, so like before. - Adds new property for schema.org JSON-LD: `mainEntityOfPage` as an Object. - Adds additional Open Graph data (if we have the image size): `og:image:width` and `og:image:height` - Adds/updates tests * AMP router and controller (#7171, #7157) Implements AMP in `/apps/`: - renders `amp.hbs` if route is `/:slug/amp/` - updates `setResponseContext` to set context to `['amp', 'post']` for a amp post and `['amp', 'page']` for a page, but will not render amp template for a page - updates `context_spec` - registers 'amp' as new internal app - adds the `amp.hbs` template to `core/server/apps/amp` which will be the default template for AMP posts. - adds `isAmpURL` to `post-lookup` * 🎨 Use `context` in meta as array (#7205) Instead of reading the first value of the context array, we're checking if it includes certain context values. This is a preparation change for AMP, where the context will be delivered as `['amp', 'post']`. * ✨ AMP helpers (#7174, #7216, #7215, #7223) - Adds AMP helpers `{{amp_content}}`, `{{amp_component}}` and `{{amp_ghost_head}}` to support AMP: - `{{amp_content}}`: - Adds `Amperize` as dependency - AMP app uses new helper `{{amp_content}}` to render AMP HTML - `Amperize` transforms regular HTML into AMP HTML - Adds test for `{{amp_content}}` helper - Adds 'Sanitize-HTML` as dependendy - After the HTML get 'amperized' we still might have some HTML tags, which are prohibited in AMP HTML, so we use `sanitize-html` to remove those. With every update, `Amperize` gets and it is able to transform more HTML tags, they valid AMP HTML tags (e. g. `video` and `amp-video`) and will therefore not be removed. - `{{amp_ghost_head}}`: - registers `{{amp_ghost_head}}` helper, but uses `{{ghost_head}}` code - uses `{{amp_ghost_head}}` in `amp.hbs` instead of `{{ghost_head}}` - `{{ghost_head}}`: - Render `amphtml` link in metadata for post, which links to the amp post (`getAmpUrl`) - Updates all test in metadata to support `amp` context - Changes context conditionals to work with full array instead of first array value - Adds conditionals, so no additional javascript gets rendered in `{{ghost_head}}` - Removes trailing `/amp/` in URLs, so only `amphtml` link on regular post renders it - Adds a conditional, so no code injection will be included, for an `amp` context. - `{{amp_components}}`: - AMP app uses new helper `{{amp_components}}` to render necessary script tags for AMP extended components as `amp-iframe`, `amp-anime` and `amp-form` - Adds test for `{{amp_components}}`
2016-08-22 19:49:27 +03:00
done();
}).catch(done);
});
});
Reference in New Issue Copy Permalink