- these have been lingering around for a while but don't really get a
lot of love
- I'm planning on moving the migration utils/schema commands into a
separate package at some point, and these files are just cluttering
things up
- to make life easier, I'm going to inline them for now
refs https://github.com/TryGhost/Ghost/pull/9097
- this was originally added to measure the AMP parsing time but AMP is
becoming less and less important (it's disabled by default in Ghost
now)
- this also causes a lot of noise when viewing logs, and I've never
experienced an issue with AMP parsing time that we've needed to review
these logs
- therefore, this commit deletes it
closes https://github.com/TryGhost/Toolbox/issues/525
- When the update check is run as an offloaded job (in a worker thread) the errors that are handled over "logger.error" do not get bubbled up to the job manager to be handled fully. With an optional "rethrowErrors" flag it's not possible to throw errors when the update check is run as a "job" and handle as usual when run in the main thread (through the admin route trigger)
refs https://github.com/TryGhost/Ghost/issues/15502
- this adds the package to Portal and integrates it into the state we
pass around
- note: I've currently left the detection of the language
(`site.locale`) commented for now until we flesh more of the
implementation out
refs https://github.com/TryGhost/Toolbox/issues/525
refs https://github.com/TryGhost/Ghost/pull/16224
- The update check job has been failing due to uninitialized Members Service. Loading Tiers in the context of update check is not important because all we are looking for is the posts count.
- The products repository list service is also about to be replace by Tiers repository, so getting correctly initialized members service is not crucial.
no issue
- Reduced the amount of diffeerent properties by not populating a `currentARR` and `currentMembers` fields, but use a `currentValue` instead.
- The type of milestone can still be determined by its `type` property, so we actually don't need two different props here
no issue
- Switches to used newly added config values throughout the services
- Updated the `shouldSendEmail` fn to check if actual value is too far from achieved milestone as determined by the percentage setting (e. g. 998 members should not accidentally receive an email for achieving 100 members)
no issue
- Instead of having those values hard coded, make them quickly configurable
- Those values are deciding if we send an email or not, the milestones will be created either way:
- minDaysSinceImported: the amount of that days should've passed since the last member was imported
- minDaysSinceLastEmail: minimum amount of days that need to pass
- maxPercentageFromMilestone: the max percentage that the current value can be away from the achieved milestone (e. g. 999 members should not send and email for 100 members)
no issue
Before, when base data included labels for members, the random generated labels would also be generated. This prevents that, and ensures that the base-data labels are applied correctly to members.
fixes https://github.com/TryGhost/Team/issues/2601
Sets the value of outbound_link_tagging to the same value of
members_track_sources, so that is disabled by default for privacy
sensitive sites.
Also makes sure the `outbound_link_tagging` setting is available in
admin (currently excluded because it is in the analytics group)
refs https://github.com/TryGhost/Toolbox/issues/522
- Using a generic resource repository for caching purposes didn't prove to be effective as code was moved to api-level caching. There's no need to introduce extra abstraction level for simple calls like findPage when there's no extra logic to it.
refs https://github.com/TryGhost/Toolbox/issues/522
- Caching on a repository level was pretty hard to achieve with more complex models like "posts", so that approach was abandoned in favor of API-response level caching.
- Also removed use of "public-resource-repository" as it was not serving any specific purpose anymore.
no issue
- The caching has been moved down the layer - the the api-framework's "pipeline", so there's no need to add complexity to post fetching logic with repository pattern.
refs https://github.com/TryGhost/Toolbox/issues/522
- When caching responses the posts cache can create a situation where it becomes stale within the TTL period and would give stale responses to shared caches.
- Having full cache reset on 'site.changed' event makes cached content evergreen reducing the risk of caching stale content in shared caches
refs https://github.com/TryGhost/Toolbox/issues/522
- The main feature of this cache wrapper is being able to "reset" the the cache without calling the "reset" on the wrapped cache. Being able to invalidate caches without accessing the data is a feature needed to run on caches with shared environment.
- Cache invalidation happens through a special "reset time" key being added to each key when setting or getting a value, when the cache is reset the reset time is set to a new value - essentially invalidating all previously accessible values.
refs https://github.com/TryGhost/Toolbox/issues/522
- The public posts "browse" endpoint is causing the most strain on the instance performance. Caching responses with small TTL would allow to reduce the amount of request processing.
refs https://github.com/TryGhost/Toolbox/issues/522
- API-level response caching allows to cache responses bypassing the "pipeline" processing
- The main usecase for these caches is caching GET requests for expensive Content API requests
- To enable response caching add a "cache" key with a cache instance as a value, for example for posts public cache configuration can look like:
```
module.exports = {
docName: 'posts',
browse: {
cache: postsPublicService.api.cache,
options: [ ...
```
no refs
-spam prevention test was causing subsequent tests to fail randomly
-moving to the end ensures (for now) we don't interrupt other tests
-seems to be an issue with awaiting the jobservice which do concurrent
