- this is only a temporary fix until we have time to go and investigate
some performance issues in the tests
- we keep seeing random failures due to timeouts in the integration
tests, and it's incredibly distracting
- Ghost doesn't prevent itself from running the `shutdown` procedure more than once
- if you spam Ctrl-C, you can reproduce this
- this might not be the case when running using `yarn dev` because
some Grunt code captures the SIGINT/SIGTERM, but that is changing
very soon
- whilst not necessary a problem now, we might introduce code that runs
during a shutdown but only expects to happen once
- this commit introduces a flag to say that Ghost is shutting down, and
prevents the `shutdown` function from executing further once true
refs https://ghost.org/docs/faq/supported-databases/
- the supported database changes we were putting in place for v5 are
now applicable, so the copy needs to change
- also including minor design updates to make it look like an error
- as part of our effort to reduce our usage of Grunt in favor of more
maintainable (and maintained) alternatives, this commit removes Grunt
from Admin
- the main difference here is switching from subgrunt to shell, which
should be a nice stepping stone to removing Grunt altogether one day
- up until now, we've been sending the `safe` version as data in
metrics, but this only includes major.minor
- we'd like to be able to see how every release affects the results, so
this commit switches to using the version that was supplied in the
package.json so we've got more of a granular overview
no issue
- has a default class of `koenig-react-editor` which can be added to by using `@className`
- adds classes of `koenig-react-editor-loading` and `koenig-react-editor-error` to the `<p>` elements rendered during loading or when loading fails
refs https://github.com/TryGhost/Toolbox/issues/364
- Settings Manager used to store all of it's settings values in a hash - an in memory cache in disguise. Having a hidden cache made it hard to reason about it's impact of memory usage and did not allow to swap it out for an alternative storage metchanism easily. Having a cache storage abstraction in Settings Manager allows to get rid of long lasting memory problems + decouples storage mechanism from the logic around transforming stored values.
refs https://github.com/TryGhost/Toolbox/issues/364
- This is groundwork to substitute in memory caches we use across the codebase. The first candidate would be settings cache. The interface of the memory cache was kept to the minimum. The "keys" method is a somewhat acceptable alternative to the "getAll" method used in the codebase right now.
- The next iteration over this would be adding async methods are alternative key/value storage methanisms like Redis.
refs https://github.com/TryGhost/Toolbox/issues/364
- Passing "cache" through constructor did not work out because cache setting is still dependent upon on the model layer (gets called before it has a chance to initialize during db migrations)
- To remove the initialization dependency blockers were:
"defaults" method in the post model - the value resolved to "undefined" anyway during the fixture insertion
validate-password module - checks the password against "undefined" during fixture initialization
- Passing the cache through "init" method works too, but is not as clear as with constructor DI pattern.
no issue
- when running locally with local development version of koenig-react without any proxies we were previously forcing `https://` even if the specific url in config was `http://` meaning a proxy was required
- switched to allowing both http and https urls in config
refs https://github.com/TryGhost/Team/issues/1716
- Adds the bio field to the API output
- Allow setting bio when updating the member
- Includes new E2E tests for the members API that were missing
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>
- we're meant to be running our CSS through csscomb in order to apply
specific code styles, but the reality is that it never gets used
- keeping csscomb around just adds to the package cruft and so this
commit cleans up references to it in order to
no issue
- jsdelivr has heavy CDN and local caching for 7 days which makes it difficult to test the frequent package bumps whilst we're actively working on the experimental package. Switching back to unpkg for now to take advantage of it's 60s cache
refs https://forum.ghost.org/t/admin-template-issues-default-install/31750
- we recently switched to using different folders within `core/built`, to
indicate the assets that are applicable for development/production
environments
- unfortunately, this came with the side effect of the "development" assets
missing in the published tarball, which meant Admin wouldn't load when
running in development mode
- this was a regression from how it previously worked because we used to
just copy the production HTML file to the development HTML name, and
use the same assets
- after thinking about it, I think we can get rid of the split folders
for assets, because I don't think the use-case is there for having
them:
- if you run Ghost from source, you're 99% only using the
development-built assets
- if you want production ones, you can run with a flag, but the
development ones get wiped anyway
- those running Ghost from a published package are using the same
assets and HTML file
- therefore, I think we can make our lives simpler by removing the env
folders and using a folder under `core/built/admin/...`
- this commit implements that across Ghost and Admin
refs https://github.com/TryGhost/Team/issues/1724
- storing trial period days allows site owners to give free trial for N days to all members signing up on a tier
- by default, all tiers have 0 trial period days(same as no trial)
refs https://github.com/TryGhost/Toolbox/issues/365
- some of this was barely used anyway, but now Admin is a package in the
monorepo, we don't need to be installing dependencies twice
refs https://github.com/TryGhost/Toolbox/issues/363
- this shared library is standalone, and it used in various places of
Ghost core, so we can pull it out to keep it easier to reason about
- we also use the `html-to-text` dependency in another package but it's
outdated and could now switch to this new package
