Ghost/core/frontend/services/url/UrlGenerator.js

259 lines
7.8 KiB
JavaScript
Raw Normal View History

Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
const _ = require('lodash'),
nql = require('@nexes/nql'),
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
debug = require('ghost-ignition').debug('services:url:generator'),
localUtils = require('../../../server/lib/url-utils'),
// @TODO: merge with filter plugin
EXPANSIONS = [{
key: 'author',
replacement: 'authors.slug'
}, {
key: 'tags',
replacement: 'tags.slug'
}, {
key: 'tag',
replacement: 'tags.slug'
}, {
key: 'authors',
replacement: 'authors.slug'
}, {
key: 'primary_tag',
replacement: 'primary_tag.slug'
}, {
key: 'primary_author',
replacement: 'primary_author.slug'
}];
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
/**
* The UrlGenerator class is responsible to generate urls based on a router's conditions.
* It is the component which sits between routers and resources and connects them together.
* Each url generator can own resources. Each resource can only be owned by one generator,
* because each resource can only live on one url at a time.
*
* Each router is represented by a url generator.
*/
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
class UrlGenerator {
✨Dynamic Routing Beta (#9596) refs #9601 ### Dynamic Routing This is the beta version of dynamic routing. - we had a initial implementation of "channels" available in the codebase - we have removed and moved this implementation - there is now a centralised place for dynamic routing - server/services/routing - each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts - keep as much as possible logic of routing helpers, middlewares and controllers - ensure test coverage - connect all the things together - yaml file + validation - routing + routers - url service - sitemaps - url access - deeper implementation of yaml validations - e.g. hard require slashes - ensure routing hierarchy/order - e.g. you enable the subscriber app - you have a custom static page, which lives under the same slug /subscribe - static pages are stronger than apps - e.g. the first collection owns the post it has filtered - a post cannot live in two collections - ensure apps are still working and hook into the routers layer (or better said: and register in the routing service) - put as much as possible comments to the code base for better understanding - ensure a clean debug log - ensure we can unmount routes - e.g. you have a collection permalink of /:slug/ represented by {globals.permalink} - and you change the permalink in the admin to dated permalink - the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/ - unmount without server restart, yey - ensure we are backwards compatible - e.g. render home.hbs for collection index if collection route is / - ensure you can access your configured permalink from the settings table with {globals.permalink} ### Render 503 if url service did not finish - return 503 if the url service has not finished generating the resource urls ### Rewrite sitemaps - we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime - we generate all urls on bootstrap - the sitemaps service will consume created resource and router urls - these urls will be shown on the xml pages - we listen on url events - we listen on router events - we no longer have to fetch the resources, which is nice - the urlservice pre-fetches resources and emits their urls - the urlservice is the only component who knows which urls are valid - i made some ES6 adaptions - we keep the caching logic -> only regenerate xml if there is a change - updated tests - checked test coverage (100%) ### Re-work usage of Url utility - replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId` - only for resources e.g. post, author, tag - this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime - adapt url utility - adapt tests
2018-06-05 20:02:20 +03:00
constructor(router, queue, resources, urls, position) {
this.router = router;
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
this.queue = queue;
this.urls = urls;
this.resources = resources;
this.uid = position;
debug('constructor', this.toString());
✨Dynamic Routing Beta (#9596) refs #9601 ### Dynamic Routing This is the beta version of dynamic routing. - we had a initial implementation of "channels" available in the codebase - we have removed and moved this implementation - there is now a centralised place for dynamic routing - server/services/routing - each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts - keep as much as possible logic of routing helpers, middlewares and controllers - ensure test coverage - connect all the things together - yaml file + validation - routing + routers - url service - sitemaps - url access - deeper implementation of yaml validations - e.g. hard require slashes - ensure routing hierarchy/order - e.g. you enable the subscriber app - you have a custom static page, which lives under the same slug /subscribe - static pages are stronger than apps - e.g. the first collection owns the post it has filtered - a post cannot live in two collections - ensure apps are still working and hook into the routers layer (or better said: and register in the routing service) - put as much as possible comments to the code base for better understanding - ensure a clean debug log - ensure we can unmount routes - e.g. you have a collection permalink of /:slug/ represented by {globals.permalink} - and you change the permalink in the admin to dated permalink - the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/ - unmount without server restart, yey - ensure we are backwards compatible - e.g. render home.hbs for collection index if collection route is / - ensure you can access your configured permalink from the settings table with {globals.permalink} ### Render 503 if url service did not finish - return 503 if the url service has not finished generating the resource urls ### Rewrite sitemaps - we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime - we generate all urls on bootstrap - the sitemaps service will consume created resource and router urls - these urls will be shown on the xml pages - we listen on url events - we listen on router events - we no longer have to fetch the resources, which is nice - the urlservice pre-fetches resources and emits their urls - the urlservice is the only component who knows which urls are valid - i made some ES6 adaptions - we keep the caching logic -> only regenerate xml if there is a change - updated tests - checked test coverage (100%) ### Re-work usage of Url utility - replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId` - only for resources e.g. post, author, tag - this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime - adapt url utility - adapt tests
2018-06-05 20:02:20 +03:00
// CASE: routers can define custom filters, but not required.
if (this.router.getFilter()) {
this.filter = this.router.getFilter();
Revert post.page->post.type handling no issue - the column addition/removal can be too slow for large sites - will be added back in 3.0 --- Revert "Fixed canary api for page/type column" This reverts commit a5a7e7e919d83af3ea9cd7402a75dff60f2d7e9c. Revert "Updated frontend canary url config for page/type" This reverts commit 19100ec5e6edbe67464c4938521fe25d7ec15041. Revert "Updated canary api to handle type column correctly (#11006)" This reverts commit c3e8ba0523f5460662dcd3cddf0affd337b26eba. Revert "Ensured `page` filter works in routes.yaml" This reverts commit 9037c19e50c4da026f4b797413a682e1411b032f. Revert "Replaced usage of mongo util with nql-map-key-values" This reverts commit 8c5f1d0ef0ad9a03fb3e362c31063e47a0173411. Revert "Added shared nql-map-key-values module" This reverts commit ef4fd4b8ef3824290a00a371dad5a505431ab689. Revert "Ensured page prop is present on content api response" This reverts commit cfa0a0862bf7b247cfeb9b689cfdf6b8e3fb0c10. Revert "Fixed failing regression tests" This reverts commit 9c2bb3811fba8ea127b22f13d21112dcf1f5a46d. Revert "Updated xmlrpc and slack service to use type column" This reverts commit 44a02c7d3635967dd3fe8f96b793b50fd398bd40. Revert "Updated v0.1 posts api to work with type column" This reverts commit 2c81d7c914ac0a2c3b7f1d6d0385479e61d15f18. Revert "Removed updates to v0.1 specific code" This reverts commit 08d83c1f5332b7db6b96814651b496e707c2e124. Revert "Added missing context from ValidationError" This reverts commit cd45ab4f54abefeee8605df84cfc864fff1ad385. Revert "Renamed page->type in the page&posts serializers" This reverts commit df99e724e3d7dc1665916844983849494deea80d. Revert "Added mongo helper to input serializers" This reverts commit fb8eadb4a8109ba987d79decfe331c669a446609. Revert "Passed mongoTransformer through to NQL" This reverts commit 0ae3f0fdfc864dcf5c90c6b56cf975997974742c. Revert "Permitted mongoTransformer option for read methods" This reverts commit a89376bf2618520626d2cf1b8d86f3c8c453db23. Revert "Updated the count plugin to reference the type column" This reverts commit a52f15d3d3503bc9ce4e20961c1f4a0fd49316c7. Revert "Updated hashes for db integrity check" This reverts commit bb6b337be3d30e919e4edfdc2e59182cb81e9e5d. Revert "Remove page column and remaining references" This reverts commit 9d7190d69255ac011848c6bf654886be81abeedc. Revert "Added type column to data generator" This reverts commit e59806cb45c47e0bd547801de54ac5332913fbf5. Revert "Removed references to page column in rss tests" This reverts commit 04d0f855dede1a1bd910c1bc7ca4913ae27472ae. Revert "Removed page column references in validation tests" This reverts commit f0afbc5cc06449ccae034b930709e29133ca8374. Revert "Updated the post model to use the `type` column" This reverts commit 1189bc823ac6adde4f25d63d9fc83ca94e38d672. Revert "Updated url service to use type column" This reverts commit 61612ba8fd38a72d8ef6af5b2c199a9dcd80b80b. Revert "Updated the v2 api to deal with type column" This reverts commit 57afb2de2baf702575a2ea3e4d8e1b914f769e00. Revert "Added type property to post model defaults" This reverts commit dc3345b1c59d03261ecd678a9cbad0ec91ef5a38. Revert "Added type property to the default post fixtures" This reverts commit 82d8c380336b6455ad09622edf7ecd803d0cbe23. Revert "Added type column to posts table" This reverts commit 9b85fc6a69363c27d11963a5078136cedc696156.
2019-08-16 19:46:00 +03:00
this.nql = nql(this.filter, {expansions: EXPANSIONS});
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
debug('filter', this.filter);
}
this._listeners();
}
/**
* @description Helper function to register listeners for each url generator instance.
* @private
*/
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
_listeners() {
/**
* @NOTE: currently only used if the permalink setting changes and it's used for this url generator.
* @TODO: https://github.com/TryGhost/Ghost/issues/10699
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
*/
✨Dynamic Routing Beta (#9596) refs #9601 ### Dynamic Routing This is the beta version of dynamic routing. - we had a initial implementation of "channels" available in the codebase - we have removed and moved this implementation - there is now a centralised place for dynamic routing - server/services/routing - each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts - keep as much as possible logic of routing helpers, middlewares and controllers - ensure test coverage - connect all the things together - yaml file + validation - routing + routers - url service - sitemaps - url access - deeper implementation of yaml validations - e.g. hard require slashes - ensure routing hierarchy/order - e.g. you enable the subscriber app - you have a custom static page, which lives under the same slug /subscribe - static pages are stronger than apps - e.g. the first collection owns the post it has filtered - a post cannot live in two collections - ensure apps are still working and hook into the routers layer (or better said: and register in the routing service) - put as much as possible comments to the code base for better understanding - ensure a clean debug log - ensure we can unmount routes - e.g. you have a collection permalink of /:slug/ represented by {globals.permalink} - and you change the permalink in the admin to dated permalink - the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/ - unmount without server restart, yey - ensure we are backwards compatible - e.g. render home.hbs for collection index if collection route is / - ensure you can access your configured permalink from the settings table with {globals.permalink} ### Render 503 if url service did not finish - return 503 if the url service has not finished generating the resource urls ### Rewrite sitemaps - we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime - we generate all urls on bootstrap - the sitemaps service will consume created resource and router urls - these urls will be shown on the xml pages - we listen on url events - we listen on router events - we no longer have to fetch the resources, which is nice - the urlservice pre-fetches resources and emits their urls - the urlservice is the only component who knows which urls are valid - i made some ES6 adaptions - we keep the caching logic -> only regenerate xml if there is a change - updated tests - checked test coverage (100%) ### Re-work usage of Url utility - replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId` - only for resources e.g. post, author, tag - this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime - adapt url utility - adapt tests
2018-06-05 20:02:20 +03:00
this.router.addListener('updated', () => {
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
const myResources = this.urls.getByGeneratorId(this.uid);
myResources.forEach((object) => {
this.urls.removeResourceId(object.resource.data.id);
object.resource.release();
this._try(object.resource);
});
});
/**
* Listen on two events:
*
* - init: bootstrap or url reset
* - added: resource was added to the database
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
*/
this.queue.register({
event: 'init',
tolerance: 100
}, this._onInit.bind(this));
this.queue.register({
event: 'added'
}, this._onAdded.bind(this));
}
/**
* @description Listener which get's called when the resources were fully fetched from the database.
*
* Each url generator will be called and can try to own resources now.
*
* @private
*/
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
_onInit() {
debug('_onInit', this.router.getResourceType());
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
// @NOTE: get the resources of my type e.g. posts.
const resources = this.resources.getAllByType(this.router.getResourceType());
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
debug(resources.length);
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
_.each(resources, (resource) => {
this._try(resource);
});
}
/**
* @description Listener which get's called when a resource was added on runtime.
* @param {String} event
* @private
*/
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
_onAdded(event) {
debug('onAdded', this.toString());
// CASE: you are type "pages", but the incoming type is "users"
if (event.type !== this.router.getResourceType()) {
return;
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
}
const resource = this.resources.getByIdAndType(event.type, event.id);
this._try(resource);
}
/**
* @description Try to own a resource and generate it's url if so.
* @param {Resource} resource
* @returns {boolean}
* @private
*/
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
_try(resource) {
/**
* CASE: another url generator has taken this resource already.
*
* We have to remember that, because each url generator can generate a different url
* for a resource. So we can't directly check `this.urls.getUrl(url)`.
*/
if (resource.isReserved()) {
return false;
}
const url = this._generateUrl(resource);
// CASE 1: route has no custom filter, it will own the resource for sure
// CASE 2: find out if my filter matches the resource
if (!this.filter) {
this.urls.add({
url: url,
generatorId: this.uid,
resource: resource
});
resource.reserve();
this._resourceListeners(resource);
return true;
} else if (this.nql.queryJSON(resource.data)) {
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
this.urls.add({
url: url,
generatorId: this.uid,
resource: resource
});
resource.reserve();
this._resourceListeners(resource);
return true;
} else {
return false;
}
}
/**
* @description Generate url based on the permlink configuration of the target router.
*
* @NOTE We currently generate relative urls (https://github.com/TryGhost/Ghost/commit/7b0d5d465ba41073db0c3c72006da625fa11df32).
*/
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
_generateUrl(resource) {
✨Dynamic Routing Beta (#9596) refs #9601 ### Dynamic Routing This is the beta version of dynamic routing. - we had a initial implementation of "channels" available in the codebase - we have removed and moved this implementation - there is now a centralised place for dynamic routing - server/services/routing - each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts - keep as much as possible logic of routing helpers, middlewares and controllers - ensure test coverage - connect all the things together - yaml file + validation - routing + routers - url service - sitemaps - url access - deeper implementation of yaml validations - e.g. hard require slashes - ensure routing hierarchy/order - e.g. you enable the subscriber app - you have a custom static page, which lives under the same slug /subscribe - static pages are stronger than apps - e.g. the first collection owns the post it has filtered - a post cannot live in two collections - ensure apps are still working and hook into the routers layer (or better said: and register in the routing service) - put as much as possible comments to the code base for better understanding - ensure a clean debug log - ensure we can unmount routes - e.g. you have a collection permalink of /:slug/ represented by {globals.permalink} - and you change the permalink in the admin to dated permalink - the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/ - unmount without server restart, yey - ensure we are backwards compatible - e.g. render home.hbs for collection index if collection route is / - ensure you can access your configured permalink from the settings table with {globals.permalink} ### Render 503 if url service did not finish - return 503 if the url service has not finished generating the resource urls ### Rewrite sitemaps - we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime - we generate all urls on bootstrap - the sitemaps service will consume created resource and router urls - these urls will be shown on the xml pages - we listen on url events - we listen on router events - we no longer have to fetch the resources, which is nice - the urlservice pre-fetches resources and emits their urls - the urlservice is the only component who knows which urls are valid - i made some ES6 adaptions - we keep the caching logic -> only regenerate xml if there is a change - updated tests - checked test coverage (100%) ### Re-work usage of Url utility - replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId` - only for resources e.g. post, author, tag - this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime - adapt url utility - adapt tests
2018-06-05 20:02:20 +03:00
const permalink = this.router.getPermalinks().getValue();
return localUtils.replacePermalink(permalink, resource.data);
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
}
/**
* @description Helper function to register resource listeners.
*
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
* I want to know if my resources changes.
*
* If the owned resource get's updated, we simply release/free the resource and push it back to the queue.
* This is the easiest, less error prone implementation.
*
* Imagine you have two collections: `featured:true` and `page:false`.
* If a published post status get's featured and you have not explicitly defined `featured:false`, we wouldn't
* be able to figure out if this resource still belongs to me, because the filter still matches.
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
*/
_resourceListeners(resource) {
const onUpdate = (updatedResource) => {
// 1. remove old resource
this.urls.removeResourceId(updatedResource.data.id);
// 2. free resource, the url <-> resource connection no longer exists
updatedResource.release();
// 3. post has the change to get owned from a different collection again
debug('put back in queue', updatedResource.data.id);
this.queue.start({
event: 'added',
action: 'added:' + resource.data.id,
eventData: {
id: resource.data.id,
type: this.router.getResourceType()
}
});
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
};
const onRemoved = (removedResource) => {
this.urls.removeResourceId(removedResource.data.id);
removedResource.release();
};
resource.removeAllListeners();
resource.addListener('updated', onUpdate.bind(this));
resource.addListener('removed', onRemoved.bind(this));
}
/**
* @description Figure out if this url generator own's a resource id.
* @param {String} id
* @returns {boolean}
*/
hasId(id) {
const existingUrl = this.urls.getByResourceId(id);
✨Dynamic Routing Beta (#9596) refs #9601 ### Dynamic Routing This is the beta version of dynamic routing. - we had a initial implementation of "channels" available in the codebase - we have removed and moved this implementation - there is now a centralised place for dynamic routing - server/services/routing - each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts - keep as much as possible logic of routing helpers, middlewares and controllers - ensure test coverage - connect all the things together - yaml file + validation - routing + routers - url service - sitemaps - url access - deeper implementation of yaml validations - e.g. hard require slashes - ensure routing hierarchy/order - e.g. you enable the subscriber app - you have a custom static page, which lives under the same slug /subscribe - static pages are stronger than apps - e.g. the first collection owns the post it has filtered - a post cannot live in two collections - ensure apps are still working and hook into the routers layer (or better said: and register in the routing service) - put as much as possible comments to the code base for better understanding - ensure a clean debug log - ensure we can unmount routes - e.g. you have a collection permalink of /:slug/ represented by {globals.permalink} - and you change the permalink in the admin to dated permalink - the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/ - unmount without server restart, yey - ensure we are backwards compatible - e.g. render home.hbs for collection index if collection route is / - ensure you can access your configured permalink from the settings table with {globals.permalink} ### Render 503 if url service did not finish - return 503 if the url service has not finished generating the resource urls ### Rewrite sitemaps - we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime - we generate all urls on bootstrap - the sitemaps service will consume created resource and router urls - these urls will be shown on the xml pages - we listen on url events - we listen on router events - we no longer have to fetch the resources, which is nice - the urlservice pre-fetches resources and emits their urls - the urlservice is the only component who knows which urls are valid - i made some ES6 adaptions - we keep the caching logic -> only regenerate xml if there is a change - updated tests - checked test coverage (100%) ### Re-work usage of Url utility - replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId` - only for resources e.g. post, author, tag - this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime - adapt url utility - adapt tests
2018-06-05 20:02:20 +03:00
if (existingUrl && existingUrl.generatorId === this.uid) {
✨Dynamic Routing Beta (#9596) refs #9601 ### Dynamic Routing This is the beta version of dynamic routing. - we had a initial implementation of "channels" available in the codebase - we have removed and moved this implementation - there is now a centralised place for dynamic routing - server/services/routing - each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts - keep as much as possible logic of routing helpers, middlewares and controllers - ensure test coverage - connect all the things together - yaml file + validation - routing + routers - url service - sitemaps - url access - deeper implementation of yaml validations - e.g. hard require slashes - ensure routing hierarchy/order - e.g. you enable the subscriber app - you have a custom static page, which lives under the same slug /subscribe - static pages are stronger than apps - e.g. the first collection owns the post it has filtered - a post cannot live in two collections - ensure apps are still working and hook into the routers layer (or better said: and register in the routing service) - put as much as possible comments to the code base for better understanding - ensure a clean debug log - ensure we can unmount routes - e.g. you have a collection permalink of /:slug/ represented by {globals.permalink} - and you change the permalink in the admin to dated permalink - the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/ - unmount without server restart, yey - ensure we are backwards compatible - e.g. render home.hbs for collection index if collection route is / - ensure you can access your configured permalink from the settings table with {globals.permalink} ### Render 503 if url service did not finish - return 503 if the url service has not finished generating the resource urls ### Rewrite sitemaps - we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime - we generate all urls on bootstrap - the sitemaps service will consume created resource and router urls - these urls will be shown on the xml pages - we listen on url events - we listen on router events - we no longer have to fetch the resources, which is nice - the urlservice pre-fetches resources and emits their urls - the urlservice is the only component who knows which urls are valid - i made some ES6 adaptions - we keep the caching logic -> only regenerate xml if there is a change - updated tests - checked test coverage (100%) ### Re-work usage of Url utility - replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId` - only for resources e.g. post, author, tag - this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime - adapt url utility - adapt tests
2018-06-05 20:02:20 +03:00
return true;
}
return false;
}
/**
* @description Get all urls of this url generator.
* @returns {Array}
*/
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
getUrls() {
return this.urls.getByGeneratorId(this.uid);
}
/**
* @description Override of `toString`
* @returns {string}
*/
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
toString() {
✨Dynamic Routing Beta (#9596) refs #9601 ### Dynamic Routing This is the beta version of dynamic routing. - we had a initial implementation of "channels" available in the codebase - we have removed and moved this implementation - there is now a centralised place for dynamic routing - server/services/routing - each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts - keep as much as possible logic of routing helpers, middlewares and controllers - ensure test coverage - connect all the things together - yaml file + validation - routing + routers - url service - sitemaps - url access - deeper implementation of yaml validations - e.g. hard require slashes - ensure routing hierarchy/order - e.g. you enable the subscriber app - you have a custom static page, which lives under the same slug /subscribe - static pages are stronger than apps - e.g. the first collection owns the post it has filtered - a post cannot live in two collections - ensure apps are still working and hook into the routers layer (or better said: and register in the routing service) - put as much as possible comments to the code base for better understanding - ensure a clean debug log - ensure we can unmount routes - e.g. you have a collection permalink of /:slug/ represented by {globals.permalink} - and you change the permalink in the admin to dated permalink - the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/ - unmount without server restart, yey - ensure we are backwards compatible - e.g. render home.hbs for collection index if collection route is / - ensure you can access your configured permalink from the settings table with {globals.permalink} ### Render 503 if url service did not finish - return 503 if the url service has not finished generating the resource urls ### Rewrite sitemaps - we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime - we generate all urls on bootstrap - the sitemaps service will consume created resource and router urls - these urls will be shown on the xml pages - we listen on url events - we listen on router events - we no longer have to fetch the resources, which is nice - the urlservice pre-fetches resources and emits their urls - the urlservice is the only component who knows which urls are valid - i made some ES6 adaptions - we keep the caching logic -> only regenerate xml if there is a change - updated tests - checked test coverage (100%) ### Re-work usage of Url utility - replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId` - only for resources e.g. post, author, tag - this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime - adapt url utility - adapt tests
2018-06-05 20:02:20 +03:00
return this.router.toString();
Rewrite url service (#9550) refs https://github.com/TryGhost/Team/issues/65 We are currently work on dynamic routing (aka channels). An important piece of this feature is the url service, which always knows the url of a resource at any time. Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature. ### Key Notes - each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration - static pages are an internal concept - they sit at the end of the subscriber queue - we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps) - two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url - in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served - loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug) - the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource) - the bootstrap time will decrease a very little (depending on the amount of resources you have in your database) - we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem - **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.** ---- - the url service generates urls based on resources (posts, pages, users, tags) - the url service keeps track of resource changes - the url service keeps track of resource removal/insert - the architecture: - each routing type is represented by a url generator - a routing type is a collection, a taxonomiy or static pages - a queue which ensures that urls are unique and can be owned by one url generator - the hierarchy of registration defines that - we query knex, because bookshelf is too slow - removed old url service files + logic - added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
}
}
module.exports = UrlGenerator;