Ghost/core/server/models/settings.js

186 lines
6.4 KiB
JavaScript
Raw Normal View History

const Promise = require('bluebird'),
_ = require('lodash'),
uuid = require('uuid'),
crypto = require('crypto'),
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
ghostBookshelf = require('./base'),
common = require('../lib/common'),
validation = require('../data/validation'),
internalContext = {context: {internal: true}};
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
let Settings, defaultSettings;
// For neatness, the defaults file is split into categories.
// It's much easier for us to work with it as a single level
// instead of iterating those categories every time
function parseDefaultSettings() {
var defaultSettingsInCategories = require('../data/schema/').defaultSettings,
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
defaultSettingsFlattened = {},
dynamicDefault = {
db_hash: uuid.v4(),
public_hash: crypto.randomBytes(15).toString('hex')
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
};
_.each(defaultSettingsInCategories, function each(settings, categoryName) {
_.each(settings, function each(setting, settingName) {
setting.type = categoryName;
setting.key = settingName;
🎨 ⏱ Cleanup / optimise the server.init() function (#7985) refs #2182 * 🔥 Remove unused options from server init - this is left over from old code and is now unused * 🎨 Move knex-migrator check to db health - Move complex check function into own module - Call module from server/index.js - This just improves the readability of server/index.js * 🔥 Remove old comments - These comments all make no sense now! * 🎨 ⏱ Move model init out of promise chain - Model.init() does not return a promise - Therefore, we can move it to the top of the init function, outside of the promise change - This should be a minor optimisation, and again improves readability /clarity of what's happening * ✨ ⁉️ Move DBHash init / first run to Settings model - this structure is left over from when we had code we executed on the first run of Ghost - the implementation used the API to initialise one setting before populateDefaults is called - this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work - the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults() - it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!) - perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁 * ⏱ Optimise require order so config is first - the first require to config will cause the files to be read etc - this ensures that it happens early, and isn't confusingly timed as part of loading a different module * 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
if (dynamicDefault[setting.key]) {
setting.defaultValue = dynamicDefault[setting.key];
}
defaultSettingsFlattened[settingName] = setting;
});
});
return defaultSettingsFlattened;
}
function getDefaultSettings() {
if (!defaultSettings) {
defaultSettings = parseDefaultSettings();
}
return defaultSettings;
}
// Each setting is saved as a separate row in the database,
// but the overlying API treats them as a single key:value mapping
Settings = ghostBookshelf.Model.extend({
tableName: 'settings',
defaults: function defaults() {
return {
type: 'core'
};
},
emitChange: function emitChange(event, options) {
const eventToTrigger = 'settings' + '.' + event;
ghostBookshelf.Model.prototype.emitChange.bind(this)(this, eventToTrigger, options);
},
onDestroyed: function onDestroyed(model, options) {
model.emitChange('deleted', options);
model.emitChange(model._previousAttributes.key + '.' + 'deleted', options);
},
onCreated: function onCreated(model, response, options) {
model.emitChange('added', options);
model.emitChange(model.attributes.key + '.' + 'added', options);
},
onUpdated: function onUpdated(model, response, options) {
model.emitChange('edited', options);
model.emitChange(model.attributes.key + '.' + 'edited', options);
},
onValidate: function onValidate() {
var self = this;
return ghostBookshelf.Model.prototype.onValidate.apply(this, arguments)
.then(function then() {
return validation.validateSettings(getDefaultSettings(), self);
});
}
}, {
findOne: function (data, options) {
if (_.isEmpty(data)) {
options = data;
}
// Allow for just passing the key instead of attributes
if (!_.isObject(data)) {
data = {key: data};
}
return Promise.resolve(ghostBookshelf.Model.findOne.call(this, data, options));
},
Sorted out the mixed usages of `include` and `withRelated` (#9425) no issue - this commit cleans up the usages of `include` and `withRelated`. ### API layer (`include`) - as request parameter e.g. `?include=roles,tags` - as theme API parameter e.g. `{{get .... include="author"}}` - as internal API access e.g. `api.posts.browse({include: 'author,tags'})` - the `include` notation is more readable than `withRelated` - and it allows us to use a different easier format (comma separated list) - the API utility transforms these more readable properties into model style (or into Ghost style) ### Model access (`withRelated`) - e.g. `models.Post.findPage({withRelated: ['tags']})` - driven by bookshelf --- Commits explained. * Reorder the usage of `convertOptions` - 1. validation - 2. options convertion - 3. permissions - the reason is simple, the permission layer access the model layer - we have to prepare the options before talking to the model layer - added `convertOptions` where it was missed (not required, but for consistency reasons) * Use `withRelated` when accessing the model layer and use `include` when accessing the API layer * Change `convertOptions` API utiliy - API Usage - ghost.api(..., {include: 'tags,authors'}) - `include` should only be used when calling the API (either via request or via manual usage) - `include` is only for readability and easier format - Ghost (Model Layer Usage) - models.Post.findOne(..., {withRelated: ['tags', 'authors']}) - should only use `withRelated` - model layer cannot read 'tags,authors` - model layer has no idea what `include` means, speaks a different language - `withRelated` is bookshelf - internal usage * include-count plugin: use `withRelated` instead of `include` - imagine you outsource this plugin to git and publish it to npm - `include` is an unknown option in bookshelf * Updated `permittedOptions` in base model - `include` is no longer a known option * Remove all occurances of `include` in the model layer * Extend `filterOptions` base function - this function should be called as first action - we clone the unfiltered options - check if you are using `include` (this is a protection which could help us in the beginning) - check for permitted and (later on default `withRelated`) options - the usage is coming in next commit * Ensure we call `filterOptions` as first action - use `ghostBookshelf.Model.filterOptions` as first action - consistent naming pattern for incoming options: `unfilteredOptions` - re-added allowed options for `toJSON` - one unsolved architecture problem: - if you override a function e.g. `edit` - then you should call `filterOptions` as first action - the base implementation of e.g. `edit` will call it again - future improvement * Removed `findOne` from Invite model - no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
edit: function (data, unfilteredOptions) {
var options = this.filterOptions(unfilteredOptions, 'edit'),
self = this;
if (!Array.isArray(data)) {
data = [data];
}
return Promise.map(data, function (item) {
// Accept an array of models as input
if (item.toJSON) {
item = item.toJSON();
}
if (!(_.isString(item.key) && item.key.length > 0)) {
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.models.settings.valueCannotBeBlank')}));
}
item = self.filterData(item);
return Settings.forge({key: item.key}).fetch(options).then(function then(setting) {
if (setting) {
// it's allowed to edit all attributes in case of importing/migrating
if (options.importing) {
return setting.save(item, options);
} else {
// If we have a value, set it.
if (item.hasOwnProperty('value')) {
setting.set('value', item.value);
}
// Internal context can overwrite type (for fixture migrations)
if (options.context && options.context.internal && item.hasOwnProperty('type')) {
setting.set('type', item.type);
}
// If anything has changed, save the updated model
if (setting.hasChanged()) {
return setting.save(null, options);
}
return setting;
}
}
return Promise.reject(new common.errors.NotFoundError({message: common.i18n.t('errors.models.settings.unableToFindSetting', {key: item.key})}));
🎨 configurable logging with bunyan (#7431) - 🛠 add bunyan and prettyjson, remove morgan - ✨ add logging module - GhostLogger class that handles setup of bunyan - PrettyStream for stdout - ✨ config for logging - @TODO: testing level fatal? - ✨ log each request via GhostLogger (express middleware) - @TODO: add errors to output - 🔥 remove errors.updateActiveTheme - we can read the value from config - 🔥 remove 15 helper functions in core/server/errors/index.js - all these functions get replaced by modules: 1. logging 2. error middleware handling for html/json 3. error creation (which will be part of PR #7477) - ✨ add express error handler for html/json - one true error handler for express responses - contains still some TODO's, but they are not high priority for first implementation/integration - this middleware only takes responsibility of either rendering html responses or return json error responses - 🎨 use new express error handler in middleware/index - 404 and 500 handling - 🎨 return error instead of error message in permissions/index.js - the rule for error handling should be: if you call a unit, this unit should return a custom Ghost error - 🎨 wrap serve static module - rule: if you call a module/unit, you should always wrap this error - it's always the same rule - so the caller never has to worry about what comes back - it's always a clear error instance - in this case: we return our notfounderror if serve static does not find the resource - this avoid having checks everywhere - 🎨 replace usages of errors/index.js functions and adapt tests - use logging.error, logging.warn - make tests green - remove some usages of logging and throwing api errors -> because when a request is involved, logging happens automatically - 🐛 return errorDetails to Ghost-Admin - errorDetails is used for Theme error handling - 🎨 use 500er error for theme is missing error in theme-handler - 🎨 extend file rotation to 1w
2016-10-04 18:33:43 +03:00
});
});
},
Sorted out the mixed usages of `include` and `withRelated` (#9425) no issue - this commit cleans up the usages of `include` and `withRelated`. ### API layer (`include`) - as request parameter e.g. `?include=roles,tags` - as theme API parameter e.g. `{{get .... include="author"}}` - as internal API access e.g. `api.posts.browse({include: 'author,tags'})` - the `include` notation is more readable than `withRelated` - and it allows us to use a different easier format (comma separated list) - the API utility transforms these more readable properties into model style (or into Ghost style) ### Model access (`withRelated`) - e.g. `models.Post.findPage({withRelated: ['tags']})` - driven by bookshelf --- Commits explained. * Reorder the usage of `convertOptions` - 1. validation - 2. options convertion - 3. permissions - the reason is simple, the permission layer access the model layer - we have to prepare the options before talking to the model layer - added `convertOptions` where it was missed (not required, but for consistency reasons) * Use `withRelated` when accessing the model layer and use `include` when accessing the API layer * Change `convertOptions` API utiliy - API Usage - ghost.api(..., {include: 'tags,authors'}) - `include` should only be used when calling the API (either via request or via manual usage) - `include` is only for readability and easier format - Ghost (Model Layer Usage) - models.Post.findOne(..., {withRelated: ['tags', 'authors']}) - should only use `withRelated` - model layer cannot read 'tags,authors` - model layer has no idea what `include` means, speaks a different language - `withRelated` is bookshelf - internal usage * include-count plugin: use `withRelated` instead of `include` - imagine you outsource this plugin to git and publish it to npm - `include` is an unknown option in bookshelf * Updated `permittedOptions` in base model - `include` is no longer a known option * Remove all occurances of `include` in the model layer * Extend `filterOptions` base function - this function should be called as first action - we clone the unfiltered options - check if you are using `include` (this is a protection which could help us in the beginning) - check for permitted and (later on default `withRelated`) options - the usage is coming in next commit * Ensure we call `filterOptions` as first action - use `ghostBookshelf.Model.filterOptions` as first action - consistent naming pattern for incoming options: `unfilteredOptions` - re-added allowed options for `toJSON` - one unsolved architecture problem: - if you override a function e.g. `edit` - then you should call `filterOptions` as first action - the base implementation of e.g. `edit` will call it again - future improvement * Removed `findOne` from Invite model - no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
populateDefaults: function populateDefaults(unfilteredOptions) {
var options = this.filterOptions(unfilteredOptions, 'populateDefaults'),
self = this;
Sorted out the mixed usages of `include` and `withRelated` (#9425) no issue - this commit cleans up the usages of `include` and `withRelated`. ### API layer (`include`) - as request parameter e.g. `?include=roles,tags` - as theme API parameter e.g. `{{get .... include="author"}}` - as internal API access e.g. `api.posts.browse({include: 'author,tags'})` - the `include` notation is more readable than `withRelated` - and it allows us to use a different easier format (comma separated list) - the API utility transforms these more readable properties into model style (or into Ghost style) ### Model access (`withRelated`) - e.g. `models.Post.findPage({withRelated: ['tags']})` - driven by bookshelf --- Commits explained. * Reorder the usage of `convertOptions` - 1. validation - 2. options convertion - 3. permissions - the reason is simple, the permission layer access the model layer - we have to prepare the options before talking to the model layer - added `convertOptions` where it was missed (not required, but for consistency reasons) * Use `withRelated` when accessing the model layer and use `include` when accessing the API layer * Change `convertOptions` API utiliy - API Usage - ghost.api(..., {include: 'tags,authors'}) - `include` should only be used when calling the API (either via request or via manual usage) - `include` is only for readability and easier format - Ghost (Model Layer Usage) - models.Post.findOne(..., {withRelated: ['tags', 'authors']}) - should only use `withRelated` - model layer cannot read 'tags,authors` - model layer has no idea what `include` means, speaks a different language - `withRelated` is bookshelf - internal usage * include-count plugin: use `withRelated` instead of `include` - imagine you outsource this plugin to git and publish it to npm - `include` is an unknown option in bookshelf * Updated `permittedOptions` in base model - `include` is no longer a known option * Remove all occurances of `include` in the model layer * Extend `filterOptions` base function - this function should be called as first action - we clone the unfiltered options - check if you are using `include` (this is a protection which could help us in the beginning) - check for permitted and (later on default `withRelated`) options - the usage is coming in next commit * Ensure we call `filterOptions` as first action - use `ghostBookshelf.Model.filterOptions` as first action - consistent naming pattern for incoming options: `unfilteredOptions` - re-added allowed options for `toJSON` - one unsolved architecture problem: - if you override a function e.g. `edit` - then you should call `filterOptions` as first action - the base implementation of e.g. `edit` will call it again - future improvement * Removed `findOne` from Invite model - no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
if (!options.context) {
options.context = internalContext.context;
}
return this
.findAll(options)
.then(function checkAllSettings(allSettings) {
var usedKeys = allSettings.models.map(function mapper(setting) {
return setting.get('key');
}),
insertOperations = [];
_.each(getDefaultSettings(), function forEachDefault(defaultSetting, defaultSettingKey) {
var isMissingFromDB = usedKeys.indexOf(defaultSettingKey) === -1;
if (isMissingFromDB) {
defaultSetting.value = defaultSetting.defaultValue;
insertOperations.push(Settings.forge(defaultSetting).save(null, options));
}
});
if (insertOperations.length > 0) {
return Promise.all(insertOperations).then(function fetchAllToReturn() {
return self.findAll(options);
});
}
return allSettings;
});
}
});
module.exports = {
Settings: ghostBookshelf.model('Settings', Settings)
};