Ghost/core/server/services/settings/index.js
Katharina Irrgang b392d1925a
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 19:02:20 +02:00

95 lines
3.1 KiB
JavaScript

/**
* Settings Lib
* A collection of utilities for handling settings including a cache
*/
const _ = require('lodash'),
SettingsModel = require('../../models/settings').Settings,
SettingsCache = require('./cache'),
SettingsLoader = require('./loader'),
ensureSettingsFiles = require('./ensure-settings'),
common = require('../../lib/common'),
debug = require('ghost-ignition').debug('services:settings:index');
module.exports = {
init: function init() {
const knownSettings = this.knownSettings();
debug('init settings service for:', knownSettings);
// Make sure that supported settings files are available
// inside of the `content/setting` directory
return ensureSettingsFiles(knownSettings)
.then(() => {
// Update the defaults
return SettingsModel.populateDefaults();
})
.then((settingsCollection) => {
// Initialise the cache with the result
// This will bind to events for further updates
SettingsCache.init(settingsCollection);
});
},
/**
* Global place to switch on more available settings.
*/
knownSettings: function knownSettings() {
return ['routes'];
},
/**
* Getter for YAML settings.
* Example: `settings.get('routes').then(...)`
* will return an Object like this:
* {routes: {}, collections: {}, resources: {}}
* @param {String} setting type of supported setting.
* @returns {Object} settingsFile
* @description Returns settings object as defined per YAML files in
* `/content/settings` directory.
*/
get: function get(setting) {
const knownSettings = this.knownSettings();
// CASE: this should be an edge case and only if internal usage of the
// getter is incorrect.
if (!setting || _.indexOf(knownSettings, setting) < 0) {
throw new common.errors.IncorrectUsageError({
message: `Requested setting is not supported: '${setting}'.`,
help: `Please use only the supported settings: ${knownSettings}.`
});
}
return SettingsLoader(setting);
},
/**
* Getter for all YAML settings.
* Example: `settings.getAll().then(...)`
* will return an Object like this (assuming we're supporting `routes`
* and `globals`):
* {
* routes: {
* routes: null,
* collections: { '/': [Object] },
* resources: { tag: '/tag/{slug}/', author: '/author/{slug}/' }
* },
* globals: {
* config: { url: 'testblog.com' }
* }
* }
* @returns {Object} settingsObject
* @description Returns all settings object as defined per YAML files in
* `/content/settings` directory.
*/
getAll: function getAll() {
const knownSettings = this.knownSettings(),
settingsToReturn = {};
_.each(knownSettings, function (setting) {
settingsToReturn[setting] = SettingsLoader(setting);
});
return settingsToReturn;
}
};