Ghost/core/server/data/meta/index.js

91 lines
3.3 KiB
JavaScript
Raw Normal View History

var Promise = require('bluebird'),
settingsCache = require('../../settings/cache'),
utils = require('../../utils'),
🙇 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
logging = require('../../logging'),
getUrl = require('./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
getImageDimensions = require('./image-dimensions'),
getCanonicalUrl = require('./canonical_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
getAmpUrl = require('./amp_url'),
getPaginatedUrl = require('./paginated_url'),
getAuthorUrl = require('./author_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
getBlogLogo = require('./blog_logo'),
getRssUrl = require('./rss_url'),
getTitle = require('./title'),
getDescription = require('./description'),
getCoverImage = require('./cover_image'),
getAuthorImage = require('./author_image'),
getAuthorFacebook = require('./author_fb_url'),
getCreatorTwitter = require('./creator_url'),
getKeywords = require('./keywords'),
getPublishedDate = require('./published_date'),
getModifiedDate = require('./modified_date'),
getOgType = require('./og_type'),
getStructuredData = require('./structured_data'),
getSchema = require('./schema'),
getExcerpt = require('./excerpt');
function getMetaData(data, root) {
var metaData = {
url: getUrl(data, true),
canonicalUrl: getCanonicalUrl(data),
✨ [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
ampUrl: getAmpUrl(data),
previousUrl: getPaginatedUrl('prev', data, true),
nextUrl: getPaginatedUrl('next', data, true),
authorUrl: getAuthorUrl(data, true),
rssUrl: getRssUrl(data, true),
metaTitle: getTitle(data, root),
metaDescription: getDescription(data, root),
✨ [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
coverImage: {
url: getCoverImage(data, true)
},
authorImage: {
url: getAuthorImage(data, true)
},
authorFacebook: getAuthorFacebook(data),
creatorTwitter: getCreatorTwitter(data),
keywords: getKeywords(data),
publishedDate: getPublishedDate(data),
modifiedDate: getModifiedDate(data),
ogType: getOgType(data),
// @TODO: pass into each meta helper - wrap each helper
blog: {
title: settingsCache.get('title'),
description: settingsCache.get('description'),
url: utils.url.urlFor('home', true),
facebook: settingsCache.get('facebook'),
twitter: settingsCache.get('twitter'),
timezone: settingsCache.get('activeTimezone'),
navigation: settingsCache.get('navigation'),
icon: settingsCache.get('icon'),
cover: settingsCache.get('cover'),
logo: settingsCache.get('logo'),
amp: settingsCache.get('amp')
}
};
🙇 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
return Promise.props(getBlogLogo()).then(function (result) {
metaData.blog.logo = result;
🙇 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
// TODO: cleanup these if statements
if (data.post && data.post.html) {
metaData.excerpt = getExcerpt(data.post.html, {words: 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
if (data.post && data.post.author && data.post.author.name) {
metaData.authorName = data.post.author.name;
}
🙇 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
return Promise.props(getImageDimensions(metaData)).then(function () {
metaData.structuredData = getStructuredData(metaData);
metaData.schema = getSchema(metaData, data);
🙇 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
return metaData;
});
}).catch(function (err) {
logging.error(err);
✨ [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
return metaData;
});
}
module.exports = getMetaData;