Ghost/core/server/api/themes.js

220 lines
7.7 KiB
JavaScript
Raw Normal View History

// # Themes API
// RESTful API for Themes
const debug = require('ghost-ignition').debug('api:themes'),
✨ 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
Promise = require('bluebird'),
fs = require('fs-extra'),
localUtils = require('./utils'),
common = require('../lib/common'),
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
settingsModel = require('../models/settings').Settings,
settingsCache = require('../services/settings/cache'),
themeUtils = require('../services/themes'),
themeList = themeUtils.list;
let themes;
/**
* ## Themes API Methods
*
* **See:** [API Methods](constants.js.html#api%20methods)
*/
themes = {
/**
* Every role can browse all themes. The response contains a list of all available themes in your content folder.
* The active theme get's marked as `active:true` and contains an extra object `templates`, which
* contains the custom templates of the active theme. These custom templates are used to show a dropdown
* in the PSM to be able to choose a custom post template.
*/
browse(options) {
return localUtils
// Permissions
.handlePermissions('themes', 'browse')(options)
// Main action
.then(() => {
// Return JSON result
return themeUtils.toJSON();
});
},
activate(options) {
let themeName = options.name,
newSettings = [{
key: 'active_theme',
value: themeName
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
}],
loadedTheme,
checkedTheme;
return localUtils
// Permissions
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
.handlePermissions('themes', 'activate')(options)
// Validation
.then(() => {
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
loadedTheme = themeList.get(themeName);
if (!loadedTheme) {
return Promise.reject(new common.errors.ValidationError({
message: common.i18n.t('notices.data.validation.index.themeCannotBeActivated', {themeName: themeName}),
context: 'active_theme'
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
}));
}
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
return themeUtils.validate.check(loadedTheme);
})
// Update setting
.then((_checkedTheme) => {
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
checkedTheme = _checkedTheme;
// We use the model, not the API here, as we don't want to trigger permissions
return settingsModel.edit(newSettings, options);
})
// Call activate
.then(() => {
✨ 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
// Activate! (sort of)
debug('Activating theme (method B on API "activate")', themeName);
themeUtils.activate(loadedTheme, checkedTheme);
// Return JSON result
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
return themeUtils.toJSON(themeName, checkedTheme);
});
},
upload(options) {
options = options || {};
// consistent filename uploads
options.originalname = options.originalname.toLowerCase();
let zip = {
path: options.path,
name: options.originalname,
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
shortName: themeUtils.storage.getSanitizedFileName(options.originalname.split('.zip')[0])
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
},
checkedTheme;
// check if zip name is casper.zip
if (zip.name === 'casper.zip') {
throw new common.errors.ValidationError({message: common.i18n.t('errors.api.themes.overrideCasper')});
}
return localUtils
// Permissions
.handlePermissions('themes', 'add')(options)
// Validation
.then(() => {
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
return themeUtils.validate.check(zip, true);
})
// More validation (existence check)
.then((_checkedTheme) => {
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
checkedTheme = _checkedTheme;
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
return themeUtils.storage.exists(zip.shortName);
})
// If the theme existed we need to delete it
.then((themeExists) => {
// delete existing theme
if (themeExists) {
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
return themeUtils.storage.delete(zip.shortName);
}
})
.then(() => {
// store extracted theme
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
return themeUtils.storage.save({
name: zip.shortName,
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
path: checkedTheme.path
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
});
})
.then(() => {
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
// Loads the theme from the filesystem
// Sets the theme on the themeList
return themeUtils.loadOne(zip.shortName);
})
.then((loadedTheme) => {
✨ 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 this is the active theme, we are overriding
// This is a special case of activation
if (zip.shortName === settingsCache.get('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
// Activate! (sort of)
debug('Activating theme (method C, on API "override")', zip.shortName);
themeUtils.activate(loadedTheme, checkedTheme);
}
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
// @TODO: unify the name across gscan and Ghost!
return themeUtils.toJSON(zip.shortName, checkedTheme);
})
.finally(() => {
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
// @TODO we should probably do this as part of saving the theme
// remove zip upload from multer
// happens in background
fs.remove(zip.path)
.catch((err) => {
common.logging.error(new common.errors.GhostError({err: err}));
});
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
// @TODO we should probably do this as part of saving the theme
// remove extracted dir from gscan
// happens in background
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
if (checkedTheme) {
fs.remove(checkedTheme.path)
.catch((err) => {
common.logging.error(new common.errors.GhostError({err: err}));
});
}
});
},
download(options) {
let themeName = options.name,
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
theme = themeList.get(themeName);
if (!theme) {
return Promise.reject(new common.errors.BadRequestError({message: common.i18n.t('errors.api.themes.invalidThemeName')}));
}
return localUtils
// Permissions
.handlePermissions('themes', 'read')(options)
.then(() => {
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
return themeUtils.storage.serve({
name: themeName
});
});
},
/**
* remove theme zip
* remove theme folder
*/
destroy(options) {
let themeName = options.name,
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
theme;
return localUtils
// Permissions
.handlePermissions('themes', 'destroy')(options)
// Validation
.then(() => {
if (themeName === 'casper') {
throw new common.errors.ValidationError({message: common.i18n.t('errors.api.themes.destroyCasper')});
}
if (themeName === settingsCache.get('active_theme')) {
throw new common.errors.ValidationError({message: common.i18n.t('errors.api.themes.destroyActive')});
✨ Themes API activation permissions & validation (#8104) refs #8093 ✨ Add activate theme permission - add permission to activate themes - update tests - also: update tests for invites TODO: change how the active theme setting is updated to reduce extra permissions ✨ Move theme validation to gscan - add a new gscan validation method and use it for upload - update activate endpoint to do validation also using gscan - change to using SettingsModel instead of API so that we don't call validation or permissions on the settings API - remove validation from the settings model - remove the old validation function - add new invalid theme message to translations & remove a bunch of theme validation related unused keys 📖 Planned changes 🚨 Tests for theme activation API endpoint 🐛 Don't allow deleting the active theme 🚫 Prevent activeTheme being set via settings API - We want to control how this happens in future. - We still want to store the information in settings, via the model. - We just don't want to be able to change this info via the settings edit endpoint 🐛 ✨ Fix warnings for uploads & add for activations - warnings for uploads were broken in f8b498d - fix the response + adds tests to cover that warnings are correctly returned - add the same response to activations + more tests - activations now return a single theme object - the theme that was activated + any warnings 🎨 Improve how we generate theme API responses - remove the requirement to pass in the active theme! - move this to a specialist function, away from the list 🎨 Do not load gscan on boot
2017-03-13 14:44:44 +03:00
}
theme = themeList.get(themeName);
if (!theme) {
throw new common.errors.NotFoundError({message: common.i18n.t('errors.api.themes.themeDoesNotExist')});
}
// Actually do the deletion here
😱 🎨 Refactor storage adapter (#8229) refs #7687 There are four main changes in this PR: we have outsourced the base storage adapter to npm, because for storage developers it's annoying to inherit from a script within Ghost we hacked theme storage handling into the default local storage adapter - this was reverted, instead we have added a static theme storage here use classes instead of prototyping optimise the storage adapter in general - everything is explained in each commit ---- * rename local-file-store to LocalFileStorage I would like to keep the name pattern i have used for scheduling. If a file is a class, the file name reflects the class name. We can discuss this, if concerns are raised. * Transform LocalFileStorage to class and inherit from new base - inherit from npm ghost-storage-base - rewrite to class - no further refactoring, happens later * Rename core/test/unit/storage/local-file-store_spec.js -> core/test/unit/storage/LocalFileStorage_spec.js * Fix wrong require in core/test/unit/storage/LocalFileStorage_spec.js * remove base storage and test - see https://github.com/kirrg001/Ghost-Storage-Base - the test has moved to this repo as well * Use npm ghost-storage-base in storage/index.js * remove the concept of getStorage('themes') This concept was added when we added themes as a feature. Back then, we have changed the local storage adapter to support images and themes. This has added some hacks into the local storage adapters. We want to revert this change and add a simple static theme storage. Will adapt the api/themes layer in the next commits. * Revert LocalFileStorage - revert serve - revert delete * add storagePath as property to LocalFileStorage - define one property which holds the storage path - could be considered to pass from outside, but found that not helpful, as other storage adapters do not need this property - IMPORTANT: save has no longer a targetDir option, because this was used to pass the alternative theme storage path - IMPORTANT: exists has now an alternative targetDir, this makes sense, because - you can either ask the storage exists('my-file') and it will look in the base storage path - or you pass a specific path where to look exists('my-file', /path/to/dir) * LocalFileStorage: get rid of store pattern - getUniqueFileName(THIS) - this doesn't make sense, instances always have access to this by default * Add static theme storage - inherits from the local file storage, because they both operate on the file system - IMPORTANT: added a TODO to consider a merge of themes/loader and themes/storage - but will be definitely not part of this PR * Use new static theme storage in api/themes - storage functions are simplified! * Add https://github.com/kirrg001/Ghost-Storage-Base as dependency - tarball for now, as i am still testing - will release if PR review get's accepted * Adapt tests and jscs/jshint * 🐛 fix storage.read in favicon utility - wrong implementation of error handling * 🎨 optimise error messages for custom storage adapter errors * little renaming in the storage utlity - purpose is to have access to the custom storage instance and to the custom storage class - see next commit why * optimise instanceof base storage - instanceof is always tricky in javascript - if multiple modules exist, it can happen that instanceof is false * fix getTargetDir - the importer uses the `targetDir` option to ensure that images land in the correct folder * ghost-storage-base@0.0.1 package.json dependency
2017-04-05 17:10:34 +03:00
return themeUtils.storage.delete(themeName);
})
// And some extra stuff to maintain state here
.then(() => {
themeList.del(themeName);
// Delete returns an empty 204 response
});
}
};
module.exports = themes;