Ghost/core/server/middleware/theme-handler.js

113 lines
4.4 KiB
JavaScript
Raw Normal View History

var _ = require('lodash'),
hbs = require('express-hbs'),
config = require('../config'),
utils = require('../utils'),
errors = require('../errors'),
i18n = require('../i18n'),
settingsCache = require('../settings/cache'),
✨ New fully-loaded & validated activeTheme concept (#8146) 📡 Add debug for the 3 theme activation methods There are 3 different ways that a theme can be activated in Ghost: A. On boot: we load the active theme from the file system, according to the `activeTheme` setting B. On API "activate": when an /activate/ request is triggered for a theme, we validate & change the `activeTheme` setting C. On API "override": if uploading a theme with the same name, we override. Using a dirty hack to make this work. A: setting is done, should load & validate + next request does mounting B: load is done, should validate & change setting + next request does mounting C: load, validate & setting are all done + a hack is needed to ensure the next request does mounting ✨ Validate w/ gscan when theme activating on boot - use the new gscan validation validate.check() method when activating on boot ✨ New concept of active theme - add ActiveTheme class - make it possible to set a theme to be active, and to get the active theme - call the new themes.activate() method in all 3 cases where we activate a theme 🎨 Use new activeTheme to simplify theme code - make use of the new concept where we can, to reduce & simplify code - use new hasPartials() method so we don't have to do file lookups - use path & name getters to reduce use of getContentPath etc - remove requirement on req.app.get('activeTheme') from static-theme middleware (more on this soon) 🚨 Improve theme unit tests (TODO: fix inter-dep) - The theme unit tests are borked! They all pass because they don't test the right things. - This improves them, but they are still dependent on each-other - configHbsForContext tests don't pass if the activateTheme tests aren't run first - I will fix this in a later PR
2017-03-13 23:13:17 +03:00
themeUtils = require('../themes'),
themeHandler;
themeHandler = {
// ### configHbsForContext Middleware
// Setup handlebars for the current context (admin or theme)
configHbsForContext: function configHbsForContext(req, res, next) {
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
// Static information, same for every request unless the settings change
// @TODO: bind this once and then update based on events?
var blogData = {
title: settingsCache.get('title'),
description: settingsCache.get('description'),
facebook: settingsCache.get('facebook'),
twitter: settingsCache.get('twitter'),
timezone: settingsCache.get('activeTimezone'),
navigation: settingsCache.get('navigation'),
icon: settingsCache.get('icon'),
cover: settingsCache.get('cover'),
logo: settingsCache.get('logo'),
amp: settingsCache.get('amp')
},
labsData = _.cloneDeep(settingsCache.get('labs')),
themeData = {};
if (themeUtils.getActive()) {
themeData.posts_per_page = themeUtils.getActive().config('posts_per_page');
}
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
// Request-specific information
// These things are super dependent on the request, so they need to be in middleware
blogData.url = utils.url.urlFor('home', {secure: req.secure}, true);
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
// Pass 'secure' flag to the view engine
// so that templates can choose to render https or http 'url', see url utility
res.locals.secure = req.secure;
// @TODO: only do this if something changed?
hbs.updateTemplateOptions({
data: {
blog: blogData,
labs: labsData,
config: themeData
}
});
next();
},
// ### Activate Theme
// Helper for updateActiveTheme
✨ New fully-loaded & validated activeTheme concept (#8146) 📡 Add debug for the 3 theme activation methods There are 3 different ways that a theme can be activated in Ghost: A. On boot: we load the active theme from the file system, according to the `activeTheme` setting B. On API "activate": when an /activate/ request is triggered for a theme, we validate & change the `activeTheme` setting C. On API "override": if uploading a theme with the same name, we override. Using a dirty hack to make this work. A: setting is done, should load & validate + next request does mounting B: load is done, should validate & change setting + next request does mounting C: load, validate & setting are all done + a hack is needed to ensure the next request does mounting ✨ Validate w/ gscan when theme activating on boot - use the new gscan validation validate.check() method when activating on boot ✨ New concept of active theme - add ActiveTheme class - make it possible to set a theme to be active, and to get the active theme - call the new themes.activate() method in all 3 cases where we activate a theme 🎨 Use new activeTheme to simplify theme code - make use of the new concept where we can, to reduce & simplify code - use new hasPartials() method so we don't have to do file lookups - use path & name getters to reduce use of getContentPath etc - remove requirement on req.app.get('activeTheme') from static-theme middleware (more on this soon) 🚨 Improve theme unit tests (TODO: fix inter-dep) - The theme unit tests are borked! They all pass because they don't test the right things. - This improves them, but they are still dependent on each-other - configHbsForContext tests don't pass if the activateTheme tests aren't run first - I will fix this in a later PR
2017-03-13 23:13:17 +03:00
activateTheme: function activateTheme(blogApp) {
var hbsOptions = {
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
partialsDir: [config.get('paths').helperTemplates],
onCompile: function onCompile(exhbs, source) {
return exhbs.handlebars.compile(source, {preventIndent: true});
}
};
✨ New fully-loaded & validated activeTheme concept (#8146) 📡 Add debug for the 3 theme activation methods There are 3 different ways that a theme can be activated in Ghost: A. On boot: we load the active theme from the file system, according to the `activeTheme` setting B. On API "activate": when an /activate/ request is triggered for a theme, we validate & change the `activeTheme` setting C. On API "override": if uploading a theme with the same name, we override. Using a dirty hack to make this work. A: setting is done, should load & validate + next request does mounting B: load is done, should validate & change setting + next request does mounting C: load, validate & setting are all done + a hack is needed to ensure the next request does mounting ✨ Validate w/ gscan when theme activating on boot - use the new gscan validation validate.check() method when activating on boot ✨ New concept of active theme - add ActiveTheme class - make it possible to set a theme to be active, and to get the active theme - call the new themes.activate() method in all 3 cases where we activate a theme 🎨 Use new activeTheme to simplify theme code - make use of the new concept where we can, to reduce & simplify code - use new hasPartials() method so we don't have to do file lookups - use path & name getters to reduce use of getContentPath etc - remove requirement on req.app.get('activeTheme') from static-theme middleware (more on this soon) 🚨 Improve theme unit tests (TODO: fix inter-dep) - The theme unit tests are borked! They all pass because they don't test the right things. - This improves them, but they are still dependent on each-other - configHbsForContext tests don't pass if the activateTheme tests aren't run first - I will fix this in a later PR
2017-03-13 23:13:17 +03:00
if (themeUtils.getActive().hasPartials()) {
hbsOptions.partialsDir.push(themeUtils.getActive().partialsPath);
}
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
// reset the asset hash
config.set('assetHash', null);
// clear the view cache
blogApp.cache = {};
// Set the views and engine
✨ New fully-loaded & validated activeTheme concept (#8146) 📡 Add debug for the 3 theme activation methods There are 3 different ways that a theme can be activated in Ghost: A. On boot: we load the active theme from the file system, according to the `activeTheme` setting B. On API "activate": when an /activate/ request is triggered for a theme, we validate & change the `activeTheme` setting C. On API "override": if uploading a theme with the same name, we override. Using a dirty hack to make this work. A: setting is done, should load & validate + next request does mounting B: load is done, should validate & change setting + next request does mounting C: load, validate & setting are all done + a hack is needed to ensure the next request does mounting ✨ Validate w/ gscan when theme activating on boot - use the new gscan validation validate.check() method when activating on boot ✨ New concept of active theme - add ActiveTheme class - make it possible to set a theme to be active, and to get the active theme - call the new themes.activate() method in all 3 cases where we activate a theme 🎨 Use new activeTheme to simplify theme code - make use of the new concept where we can, to reduce & simplify code - use new hasPartials() method so we don't have to do file lookups - use path & name getters to reduce use of getContentPath etc - remove requirement on req.app.get('activeTheme') from static-theme middleware (more on this soon) 🚨 Improve theme unit tests (TODO: fix inter-dep) - The theme unit tests are borked! They all pass because they don't test the right things. - This improves them, but they are still dependent on each-other - configHbsForContext tests don't pass if the activateTheme tests aren't run first - I will fix this in a later PR
2017-03-13 23:13:17 +03:00
blogApp.set('views', themeUtils.getActive().path);
blogApp.engine('hbs', hbs.express3(hbsOptions));
// Set active theme variable on the express server
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
// Note: this is effectively the "mounted" theme, which has been loaded into the express app
✨ New fully-loaded & validated activeTheme concept (#8146) 📡 Add debug for the 3 theme activation methods There are 3 different ways that a theme can be activated in Ghost: A. On boot: we load the active theme from the file system, according to the `activeTheme` setting B. On API "activate": when an /activate/ request is triggered for a theme, we validate & change the `activeTheme` setting C. On API "override": if uploading a theme with the same name, we override. Using a dirty hack to make this work. A: setting is done, should load & validate + next request does mounting B: load is done, should validate & change setting + next request does mounting C: load, validate & setting are all done + a hack is needed to ensure the next request does mounting ✨ Validate w/ gscan when theme activating on boot - use the new gscan validation validate.check() method when activating on boot ✨ New concept of active theme - add ActiveTheme class - make it possible to set a theme to be active, and to get the active theme - call the new themes.activate() method in all 3 cases where we activate a theme 🎨 Use new activeTheme to simplify theme code - make use of the new concept where we can, to reduce & simplify code - use new hasPartials() method so we don't have to do file lookups - use path & name getters to reduce use of getContentPath etc - remove requirement on req.app.get('activeTheme') from static-theme middleware (more on this soon) 🚨 Improve theme unit tests (TODO: fix inter-dep) - The theme unit tests are borked! They all pass because they don't test the right things. - This improves them, but they are still dependent on each-other - configHbsForContext tests don't pass if the activateTheme tests aren't run first - I will fix this in a later PR
2017-03-13 23:13:17 +03:00
blogApp.set('activeTheme', themeUtils.getActive().name);
},
// ### updateActiveTheme
// Updates the blogApp's activeTheme variable and subsequently
// activates that theme's views with the hbs templating engine if it
// is not yet activated.
updateActiveTheme: function updateActiveTheme(req, res, next) {
var blogApp = req.app,
✨ New fully-loaded & validated activeTheme concept (#8146) 📡 Add debug for the 3 theme activation methods There are 3 different ways that a theme can be activated in Ghost: A. On boot: we load the active theme from the file system, according to the `activeTheme` setting B. On API "activate": when an /activate/ request is triggered for a theme, we validate & change the `activeTheme` setting C. On API "override": if uploading a theme with the same name, we override. Using a dirty hack to make this work. A: setting is done, should load & validate + next request does mounting B: load is done, should validate & change setting + next request does mounting C: load, validate & setting are all done + a hack is needed to ensure the next request does mounting ✨ Validate w/ gscan when theme activating on boot - use the new gscan validation validate.check() method when activating on boot ✨ New concept of active theme - add ActiveTheme class - make it possible to set a theme to be active, and to get the active theme - call the new themes.activate() method in all 3 cases where we activate a theme 🎨 Use new activeTheme to simplify theme code - make use of the new concept where we can, to reduce & simplify code - use new hasPartials() method so we don't have to do file lookups - use path & name getters to reduce use of getContentPath etc - remove requirement on req.app.get('activeTheme') from static-theme middleware (more on this soon) 🚨 Improve theme unit tests (TODO: fix inter-dep) - The theme unit tests are borked! They all pass because they don't test the right things. - This improves them, but they are still dependent on each-other - configHbsForContext tests don't pass if the activateTheme tests aren't run first - I will fix this in a later PR
2017-03-13 23:13:17 +03:00
// We use the settingsCache here, because the setting will be set, even if the theme itself is
// not usable because it is invalid or missing.
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
activeThemeName = settingsCache.get('activeTheme'),
mountedThemeName = blogApp.get('activeTheme');
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
// This means that the theme hasn't been loaded yet i.e. there is no active theme
✨ New fully-loaded & validated activeTheme concept (#8146) 📡 Add debug for the 3 theme activation methods There are 3 different ways that a theme can be activated in Ghost: A. On boot: we load the active theme from the file system, according to the `activeTheme` setting B. On API "activate": when an /activate/ request is triggered for a theme, we validate & change the `activeTheme` setting C. On API "override": if uploading a theme with the same name, we override. Using a dirty hack to make this work. A: setting is done, should load & validate + next request does mounting B: load is done, should validate & change setting + next request does mounting C: load, validate & setting are all done + a hack is needed to ensure the next request does mounting ✨ Validate w/ gscan when theme activating on boot - use the new gscan validation validate.check() method when activating on boot ✨ New concept of active theme - add ActiveTheme class - make it possible to set a theme to be active, and to get the active theme - call the new themes.activate() method in all 3 cases where we activate a theme 🎨 Use new activeTheme to simplify theme code - make use of the new concept where we can, to reduce & simplify code - use new hasPartials() method so we don't have to do file lookups - use path & name getters to reduce use of getContentPath etc - remove requirement on req.app.get('activeTheme') from static-theme middleware (more on this soon) 🚨 Improve theme unit tests (TODO: fix inter-dep) - The theme unit tests are borked! They all pass because they don't test the right things. - This improves them, but they are still dependent on each-other - configHbsForContext tests don't pass if the activateTheme tests aren't run first - I will fix this in a later PR
2017-03-13 23:13:17 +03:00
if (!themeUtils.getActive()) {
🎨 🐛 Improve theme lib, middleware & error handling (#8145) no issue 🎨 simplify loader - use loadOneTheme for init - use loadOneTheme for init - move updateThemeList to the one place that it is used - this just reduces the surface area of the loader 🎨 Move init up to index temporarily - need to figure out what stuff goes in here as well as loading themes - will move it again later once I've got it figured out 🎨 Reorder & cleanup theme middleware - move the order in blog/app.js so that theme middleware isn't called for shared assets - add comments & cleanup in the middleware itself, for clarity 🎨 Simplify the logic in themes middleware - Separate out config dependent on settings changing and config dependent on request - Move blogApp.set('views') - no reason why this isn't in the theme activation method as it's actually simpler if it is there, we already know the active theme exists & can remove the if-guard 🎨 Improve error handling for missing theme - ensure we display a warning - don't have complex logic for handling errors - move loading of an empty hbs object into the error-handler as this will support more cases 🐛 Fix assetHash clearing bug on theme switch - asset hash wasn't correctly being set on theme switch 🎨 Remove themes.read & test loader instead - Previously, we've simplified loader & improved error handling - We are now able to completely remove theme.read as it's nothing more than a wrapper for package.read - This also means we can change our tests from testing the theme reader to loader
2017-03-13 19:30:35 +03:00
// This is the one place we ACTUALLY throw an error for a missing theme
// As it's a request we cannot serve
return next(new errors.InternalServerError({
message: i18n.t('errors.middleware.themehandler.missingTheme', {theme: activeThemeName})
}));
// If there is an active theme AND it has changed, call activate
} else if (activeThemeName !== mountedThemeName) {
// This is effectively "mounting" a theme into express, the theme is already "active"
✨ New fully-loaded & validated activeTheme concept (#8146) 📡 Add debug for the 3 theme activation methods There are 3 different ways that a theme can be activated in Ghost: A. On boot: we load the active theme from the file system, according to the `activeTheme` setting B. On API "activate": when an /activate/ request is triggered for a theme, we validate & change the `activeTheme` setting C. On API "override": if uploading a theme with the same name, we override. Using a dirty hack to make this work. A: setting is done, should load & validate + next request does mounting B: load is done, should validate & change setting + next request does mounting C: load, validate & setting are all done + a hack is needed to ensure the next request does mounting ✨ Validate w/ gscan when theme activating on boot - use the new gscan validation validate.check() method when activating on boot ✨ New concept of active theme - add ActiveTheme class - make it possible to set a theme to be active, and to get the active theme - call the new themes.activate() method in all 3 cases where we activate a theme 🎨 Use new activeTheme to simplify theme code - make use of the new concept where we can, to reduce & simplify code - use new hasPartials() method so we don't have to do file lookups - use path & name getters to reduce use of getContentPath etc - remove requirement on req.app.get('activeTheme') from static-theme middleware (more on this soon) 🚨 Improve theme unit tests (TODO: fix inter-dep) - The theme unit tests are borked! They all pass because they don't test the right things. - This improves them, but they are still dependent on each-other - configHbsForContext tests don't pass if the activateTheme tests aren't run first - I will fix this in a later PR
2017-03-13 23:13:17 +03:00
themeHandler.activateTheme(blogApp);
}
next();
}
};
module.exports = themeHandler;