As discussed with the product team we want to enforce kebab-case file names for
all files, with the exception of files which export a single class, in which
case they should be PascalCase and reflect the class which they export.
This will help find classes faster, and should push better naming for them too.
Some files and packages have been excluded from this linting, specifically when
a library or framework depends on the naming of a file for the functionality
e.g. Ember, knex-migrator, adapter-manager
refs https://github.com/TryGhost/Team/issues/1666
- it seems like we may have a situation where `.activateTheme()` can be called simultaneously resulting in unexpected behaviour in the sync such as duplicate theme setting records
- adjusted behaviour to keep track of the currently running activation within the service and if `.activateTheme()` is called again whilst it's in progress it will wait for completion of the first sync before exiting early or continuing with a new activation
**Note:** There is a known edge-case if there are _more_ than 2 parallel `.activateTheme()` calls. We don't believe that will be an issue but calling it out in case we do still see duplicated custom setting records being created.
Co-authored-by: Kevin Ansfield <kevin@lookingsideways.co.uk>
no issue
- we were passing the theme name directly in the model query filter string without any surrounding `'` chars meaning we were generating invalid filters
no issue
Ghost allows multiple themes with the same `name` value in `package.json` so it assigns custom names based on the file name. When syncing we were only looking at the package.json `name` value so there could be a syncing clash when swapping between active themes.
- added `name` as the first argument to `.activateTheme(name, theme)` so that the service's consumer is in control of settings sync applying to it's known theme name
refs https://github.com/TryGhost/Team/issues/1104
- better matches the context of the request as we're validating known keys and valid options from multiple settings
- "404 Not Found" didn't make sense because `/custom_theme_settings/` _does_ exist, it's just that one setting key wasn't known
- "400 Bad Request" didn't make sense because the request was understood, it just failed validation of the setting values
refs https://github.com/TryGhost/Team/issues/1104
- there was a mismatch of template options when throwing error on invalid select value meaning we were erroring but with the wrong error type and message
- added missing `lodash` dependency in package.json
refs https://github.com/TryGhost/Team/issues/1104
- `.get('key')` would error because it was incorrectly expecting the internal content object to contain `{key, value}` objects
- changed `.getAll()` to return a shallow copy of the internal content object so we don't leak references that can result in unexpected changes to the cache content
- changed the internal content object naming to `_content` to highlight that it's an internal/private implementation detail rather than a public API
no issue
- the `.browse()` call to fetch themes was not structured to filter out themes correctly so it was fetching all theme settings rather than only settings related to the current theme
no issue
- `for .. of` loop contained a `return` rather than a `continue` so the whole function was being exited with an unexpected `undefined` return value after the first loop where an unknown setting is removed
refs https://github.com/TryGhost/Team/issues/1070
- receives settings array as provided by through Ghost's API
- errors if a provided setting key does not already exist in the database (settings are only created when syncing with a theme)
- errors if a provided select setting value does not match the theme-provided options
- providing there were no errors, updates each value in the database if it's changed along with the internal cache of full setting objects and the public key/value cache
- returns the same list of settings as `.listSettings()` for API consistency
refs https://github.com/TryGhost/Team/issues/1070
- if the cache is repopulated, keys that already existed in the cache but that don't exist in the new group of settings were left in the cache
- added a `.clear()` method that removes all items from the cache and call it when populating so the cache only contains what it was last populated with
- deletes properties on the internal content object so that references aren't lost
refs https://github.com/TryGhost/Team/issues/1070
- return re-fetched settings after sync so they can be used in later activation steps
- added internal `activeThemeSettings` cache that stores full setting data along with saved values for use in API output
- added `listSettings()` that converts internal cache object into a settings array that matches API format
refs https://github.com/TryGhost/Team/issues/1070
- having a dependency on a model in the cache service meant that Ghost had to know about that and pre-initialize the cache during boot, even though that didn't actually do anything except create a cache instance
- by making the cache a simple key/value store able to be populated from the cache settings service when a theme is activated it means that Ghost doesn't need to perform any extra initialization when the cache is initialized via `require`
refs https://github.com/TryGhost/Team/issues/1070
- added `bread` util that acts as a wrapper for the provided model, if we have any business functionality needed when settings are added/removed then it will go here
- added primary "server" service that handles syncing of custom theme data extracted from a theme with the settings that are in the database and exported as "Service". Syncing rules on theme activation:
- if a new setting is seen, create it with the default value
- if a setting has it's type changed, remove it and create a new setting with the default value
- if a select setting's value is not a valid option, reset it to the default value
- added shared "frontend/server" service that exposes an in-memory cache of key/value pairs for the currently active theme
