2019-04-22 18:31:56 +03:00
|
|
|
const _ = require('lodash');
|
2019-01-28 20:06:47 +03:00
|
|
|
const debug = require('ghost-ignition').debug('themes');
|
2021-05-03 19:29:44 +03:00
|
|
|
const i18n = require('../../../shared/i18n');
|
2020-05-28 21:30:23 +03:00
|
|
|
const logging = require('../../../shared/logging');
|
2020-05-22 21:22:20 +03:00
|
|
|
const errors = require('@tryghost/errors');
|
2019-01-28 20:06:47 +03:00
|
|
|
const themeLoader = require('./loader');
|
Moved activate from themes to the bridge
refs: https://github.com/TryGhost/Ghost/commit/bf0823c9a2ddbc93ad0ddcec36eed130c8c5a203
- continuing the work of splitting up the theme service into logical components
Theme activations are a trickier piece of the theme split puzzle because they are called from the API and theme service on boot in different ways.
Activations require a theme to have been validated at different levels. Validations are also tricky - do they belong to the theme engine, or the theme service?
There are then several different flows for activations:
- On Boot
- API "activate" call
- API override on upload or install via setFromZip, which is a method in the storage layer
These calls all have quite different logical flows at the moment, and need to be unified
For now, I've moved the existing "activate" function onto the bridge. This allows the theme service to be split from the frontend, and refactoring can start from there.
I hope to move this so there is less code in the actual bridge very soon, but my goal is not to require any server packages in the frontend part of this
I think ideally:
- all activation code, including validation, should probably be part of the theme engine
- the theme engine should offer 3 methods: getActive() canActivate() and activate()
- the theme service is then only responsible for loading themes in and out of storage, JSON responses for the API, and handing themes to the frontend via the bridge at the appropriate moment
2021-04-27 14:49:48 +03:00
|
|
|
const bridge = require('../../../bridge');
|
2019-01-28 20:06:47 +03:00
|
|
|
const validate = require('./validate');
|
2019-07-09 17:35:18 +03:00
|
|
|
const list = require('./list');
|
2021-04-27 15:28:04 +03:00
|
|
|
const settingsCache = require('../settings/cache');
|
2019-01-28 20:06:47 +03:00
|
|
|
|
2017-02-22 02:26:19 +03:00
|
|
|
module.exports = {
|
2017-03-13 19:30:35 +03:00
|
|
|
// Init themes module
|
|
|
|
// TODO: move this once we're clear what needs to happen here
|
|
|
|
init: function initThemes() {
|
2020-04-29 18:44:27 +03:00
|
|
|
const activeThemeName = settingsCache.get('active_theme');
|
2017-03-13 23:13:17 +03:00
|
|
|
|
2017-03-13 19:30:35 +03:00
|
|
|
debug('init themes', activeThemeName);
|
|
|
|
// Just read the active theme for now
|
|
|
|
return themeLoader
|
|
|
|
.loadOneTheme(activeThemeName)
|
2017-03-13 23:13:17 +03:00
|
|
|
.then(function activeThemeHasLoaded(theme) {
|
|
|
|
// Validate
|
|
|
|
return validate
|
|
|
|
.check(theme)
|
2017-10-11 16:19:12 +03:00
|
|
|
.then(function validationSuccess(checkedTheme) {
|
2019-04-22 18:31:56 +03:00
|
|
|
if (!validate.canActivate(checkedTheme)) {
|
2020-05-22 21:22:20 +03:00
|
|
|
const checkError = new errors.ThemeValidationError({
|
2021-04-27 15:22:26 +03:00
|
|
|
message: i18n.t('errors.middleware.themehandler.invalidTheme', {theme: activeThemeName}),
|
2019-04-22 18:31:56 +03:00
|
|
|
errorDetails: Object.assign(
|
|
|
|
_.pick(checkedTheme, ['checkedVersion', 'name', 'path', 'version']), {
|
|
|
|
errors: checkedTheme.results.error
|
|
|
|
}
|
|
|
|
)
|
|
|
|
});
|
|
|
|
|
2020-05-22 21:22:20 +03:00
|
|
|
logging.error(checkError);
|
2017-05-31 19:42:42 +03:00
|
|
|
|
Moved activate from themes to the bridge
refs: https://github.com/TryGhost/Ghost/commit/bf0823c9a2ddbc93ad0ddcec36eed130c8c5a203
- continuing the work of splitting up the theme service into logical components
Theme activations are a trickier piece of the theme split puzzle because they are called from the API and theme service on boot in different ways.
Activations require a theme to have been validated at different levels. Validations are also tricky - do they belong to the theme engine, or the theme service?
There are then several different flows for activations:
- On Boot
- API "activate" call
- API override on upload or install via setFromZip, which is a method in the storage layer
These calls all have quite different logical flows at the moment, and need to be unified
For now, I've moved the existing "activate" function onto the bridge. This allows the theme service to be split from the frontend, and refactoring can start from there.
I hope to move this so there is less code in the actual bridge very soon, but my goal is not to require any server packages in the frontend part of this
I think ideally:
- all activation code, including validation, should probably be part of the theme engine
- the theme engine should offer 3 methods: getActive() canActivate() and activate()
- the theme service is then only responsible for loading themes in and out of storage, JSON responses for the API, and handing themes to the frontend via the bridge at the appropriate moment
2021-04-27 14:49:48 +03:00
|
|
|
bridge.activateTheme(theme, checkedTheme, checkError);
|
2019-04-22 18:31:56 +03:00
|
|
|
} else {
|
|
|
|
// CASE: inform that the theme has errors, but not fatal (theme still works)
|
|
|
|
if (checkedTheme.results.error.length) {
|
2020-05-22 21:22:20 +03:00
|
|
|
logging.warn(new errors.ThemeValidationError({
|
2019-04-22 18:31:56 +03:00
|
|
|
errorType: 'ThemeWorksButHasErrors',
|
2021-04-27 15:22:26 +03:00
|
|
|
message: i18n.t('errors.middleware.themehandler.themeHasErrors', {theme: activeThemeName}),
|
2019-04-22 18:31:56 +03:00
|
|
|
errorDetails: Object.assign(
|
|
|
|
_.pick(checkedTheme, ['checkedVersion', 'name', 'path', 'version']), {
|
|
|
|
errors: checkedTheme.results.error
|
|
|
|
}
|
|
|
|
)
|
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
debug('Activating theme (method A on boot)', activeThemeName);
|
|
|
|
|
Moved activate from themes to the bridge
refs: https://github.com/TryGhost/Ghost/commit/bf0823c9a2ddbc93ad0ddcec36eed130c8c5a203
- continuing the work of splitting up the theme service into logical components
Theme activations are a trickier piece of the theme split puzzle because they are called from the API and theme service on boot in different ways.
Activations require a theme to have been validated at different levels. Validations are also tricky - do they belong to the theme engine, or the theme service?
There are then several different flows for activations:
- On Boot
- API "activate" call
- API override on upload or install via setFromZip, which is a method in the storage layer
These calls all have quite different logical flows at the moment, and need to be unified
For now, I've moved the existing "activate" function onto the bridge. This allows the theme service to be split from the frontend, and refactoring can start from there.
I hope to move this so there is less code in the actual bridge very soon, but my goal is not to require any server packages in the frontend part of this
I think ideally:
- all activation code, including validation, should probably be part of the theme engine
- the theme engine should offer 3 methods: getActive() canActivate() and activate()
- the theme service is then only responsible for loading themes in and out of storage, JSON responses for the API, and handing themes to the frontend via the bridge at the appropriate moment
2021-04-27 14:49:48 +03:00
|
|
|
bridge.activateTheme(theme, checkedTheme);
|
2019-04-22 18:31:56 +03:00
|
|
|
}
|
2017-03-13 23:13:17 +03:00
|
|
|
});
|
|
|
|
})
|
2020-05-22 21:22:20 +03:00
|
|
|
.catch(errors.NotFoundError, function (err) {
|
2017-05-31 19:42:42 +03:00
|
|
|
// CASE: active theme is missing, we don't want to exit because the admin panel will still work
|
2021-04-27 15:22:26 +03:00
|
|
|
err.message = i18n.t('errors.middleware.themehandler.missingTheme', {theme: activeThemeName});
|
2020-05-22 21:22:20 +03:00
|
|
|
logging.error(err);
|
2017-10-11 16:19:12 +03:00
|
|
|
})
|
|
|
|
.catch(function (err) {
|
|
|
|
// CASE: theme threw an odd error, we don't want to exit because the admin panel will still work
|
|
|
|
// This is the absolute catch-all, at this point, we do not know what went wrong!
|
2020-05-22 21:22:20 +03:00
|
|
|
logging.error(err);
|
2017-03-13 19:30:35 +03:00
|
|
|
});
|
|
|
|
},
|
2019-07-09 17:35:18 +03:00
|
|
|
getJSON: require('./to-json'),
|
2019-07-01 17:56:23 +03:00
|
|
|
activate: function (themeName) {
|
2019-07-09 17:35:18 +03:00
|
|
|
const loadedTheme = list.get(themeName);
|
2019-01-03 22:30:35 +03:00
|
|
|
|
2019-07-01 17:56:23 +03:00
|
|
|
if (!loadedTheme) {
|
2020-05-22 21:22:20 +03:00
|
|
|
return Promise.reject(new errors.ValidationError({
|
2021-04-27 15:22:26 +03:00
|
|
|
message: i18n.t('notices.data.validation.index.themeCannotBeActivated', {themeName: themeName}),
|
2019-07-01 17:56:23 +03:00
|
|
|
errorDetails: themeName
|
2017-10-11 16:19:12 +03:00
|
|
|
}));
|
|
|
|
}
|
2019-07-01 17:56:23 +03:00
|
|
|
|
|
|
|
return validate.checkSafe(loadedTheme)
|
|
|
|
.then((checkedTheme) => {
|
|
|
|
debug('Activating theme (method B on API "activate")', themeName);
|
Moved activate from themes to the bridge
refs: https://github.com/TryGhost/Ghost/commit/bf0823c9a2ddbc93ad0ddcec36eed130c8c5a203
- continuing the work of splitting up the theme service into logical components
Theme activations are a trickier piece of the theme split puzzle because they are called from the API and theme service on boot in different ways.
Activations require a theme to have been validated at different levels. Validations are also tricky - do they belong to the theme engine, or the theme service?
There are then several different flows for activations:
- On Boot
- API "activate" call
- API override on upload or install via setFromZip, which is a method in the storage layer
These calls all have quite different logical flows at the moment, and need to be unified
For now, I've moved the existing "activate" function onto the bridge. This allows the theme service to be split from the frontend, and refactoring can start from there.
I hope to move this so there is less code in the actual bridge very soon, but my goal is not to require any server packages in the frontend part of this
I think ideally:
- all activation code, including validation, should probably be part of the theme engine
- the theme engine should offer 3 methods: getActive() canActivate() and activate()
- the theme service is then only responsible for loading themes in and out of storage, JSON responses for the API, and handing themes to the frontend via the bridge at the appropriate moment
2021-04-27 14:49:48 +03:00
|
|
|
bridge.activateTheme(loadedTheme, checkedTheme);
|
2019-07-01 17:56:23 +03:00
|
|
|
|
|
|
|
return checkedTheme;
|
|
|
|
});
|
2017-03-21 12:03:09 +03:00
|
|
|
},
|
2019-07-09 17:35:18 +03:00
|
|
|
storage: require('./storage'),
|
2021-02-22 20:30:25 +03:00
|
|
|
/**
|
|
|
|
* Load all inactive themes
|
|
|
|
*/
|
|
|
|
loadInactiveThemes: async () => {
|
|
|
|
return await themeLoader.loadAllThemes();
|
|
|
|
}
|
2017-02-22 02:26:19 +03:00
|
|
|
};
|