no issue
- The `test:*` commands in `ghost/core` are all implicitly dependent on
the TS packages in the whole monorepo being built, but we hadn't
explicitly declared this dependency to NX.
- Now if you run `yarn nx run ghost:test:e2e` (or any other `test:*`
commands in ghost), NX will know that it needs to rebuild the TS
packages, unless they are cached and haven't changed.
- With this, you should be able to directly clone the repo and run `yarn
nx run ghost:test:e2e` to run e2e tests, without running `yarn dev` or
`yarn nx run-many -t build:ts` first.
- This is especially useful for getting tests to run properly in docker
no issue
- I apparently never added @tryghost/metrics-server as a dependency to
ghost/core/package.json. It worked in most cases as a 'phantom
dependency' — yarn installs all node_modules in a flat structure, so
even though it wasn't a dependency in package.json, it still resolved to
the correct package, as long as the typescript packages were all built
first.
- This passed CI because we explicitly run ts:build on all packages
before running tests, and it worked in production because we build the
TS packages as part of the docker build. However, when trying to run
tests locally, it would sometimes fail unless you explicitly ran nx
run-many -t build:ts at the top level before running the tests.
- Adding it as a dependency in package.json fixes this problem.
ref https://linear.app/tryghost/issue/ONC-387/
With some recent changes, we added validation to unsubscribe URLs to verify the source, allowing us to cut down on spam and improving security, as the underlying key could be re-generated should the need arise. This had the side effect of making unsubscribe URLs difficult to reconstruct when using third-party/downstream integrations, such as ActiveCampaign, which fills a gap in the current Ghost feature set.
Now any authenticated query to `/api/members` will return an `unsubscribe_url` field that can be used directly.
no ref
When running tests, occasionally we'll see some varying sort in the
members api response because members are generally all created with the
same timestamp. While `ObjectId` should be progressive, and our defalut
sort is `ORDER BY created_at desc, id desc`, we still would sometimes
see issues. This ought to remove any flakiness.
no ref
Stubbed expected test errors. In general, we should be expecting these
errors in the tests as we write them as that is the expected behavior
(or that behavior should change).
closes#16748
The members/:member_id/signin_urls endpoint currently only does
cookie-based authentication. When #21249 is merged, turning on 2FA is
going to break any 3rd party processes that use it (including my social
sign-in offering).
This patch gives admin API keys 'read' permission on this endpoint, and
enables 3rd party processes to handle user logins the right way, instead
of via a staff member's email/password.
Migration included. Feedback appreciated.
I have the wrong name on my migration. I can see it doesn't follow the
naming convention, but I'm not sure how the names are generated.
---------
Co-authored-by: Michael Barrett <mike182uk@gmail.com>
ref https://linear.app/tryghost/issue/ONC-433
- due to a regression introduced in commit 871d21a, incoming
recommendations were not rendering in Admin Settings anymore, as they
were marked as deleted
- this commit updates the refresh logic of incoming recommendations on
boot: previously deleted incoming recommendations are refetched, and if
now available, restored
- when a recommendation is restored, we don't send a staff email
notification
ref https://linear.app/tryghost/issue/ONC-433
- due to a regression introduced in commit 871d21a, incoming
recommendations were not rendering in Admin Settings anymore, as they
were marked as deleted
- this commit updates the refresh logic of incoming recommendations on
boot: previously deleted incoming recommendations are refetched, and if
now available, restored
- when a recommendation is restored, we don't send a staff email
notification
- concat is too heavy of a function to call on the hotpath, so we can
just replace it with a native spread, which is much faster
- this cuts ~1.5% from boot time for sites with a lot of posts
No issue
Wrapped a missing /month and /year string. Should work with and without
trials now.
Added a few additional translations for Japanese and French.
Adjusted German - some strings were too long to fit in the layout.
Changed (the German equivalents of) "Start a X day free trial" to
"Select", because the German is just not going to fit on the button.
ref https://linear.app/tryghost/issue/DEV-32/remove-migratejs-script
- we want to switch to using this code path instead of our separate
migrate.js script on Pro
- the main things we're missing are metrics + monitoring for when things
go wrong, so this adds that to the DatabaseStateManager
- this allows us to eventually delete the script without losing
functionality
- the code kept an array of IDs, and would check new entries against the
values of this array
- this algorithm is O(n^2) and became quite slow when the site had a lot
of redirects
- we can do away with this entirely, and just compute the keys of the
redirects to get the IDs
- this speeds up loading redirects by 3x or so
- this will prevent the `ready` variable from being set to true if there
is an error with minification, as we have not correctly generated the
assets yet
- we don't need any of these fields to do URL service calculations, so
we can exclude them from being fetched, which improves performance of
URL service init
- ultimately, we should switch this to an include list to make this more
explicit
- this code is on the hotpath for the URL service and has shown to be
slow for sites with a lot of posts
- this is due to the overhead of the lodash functions we use here
- we can take advantage of how JS executes if-statements and move the
variable into the if-statement, which lazy evaluates it (for the URL
service, this branch is not hit, so it's a big win)
- this cuts about 2% from CPU time
- this code is a hotpath for the URL service and has shown to be slow
for sites with a lot of posts
- this is because of the overhead of lodash
- we can just do away with lodash and use native JS, which has
a negligible performance cost
- this cuts about 5% CPU time during boot of large sites
- moment calls are unbelievably heavy and we should do away with it
where possible
- this code doesn't need moment and we can just use native JS Date here
- this saves about 5% CPU time when booting sites with a lot of posts
- this code has shown to be chronically slow, due to the `Object.assign`
- we don't really need this, as we can just use a normal assign in this
case
- this cuts 15% CPU from boot time for sites with a lot of resources
(posts)
- it turns out we it the false case of this if-statement quite a lot,
and _generateUrl is heavy enough that we should try and do it less
- by moving it into the if-statement, we cut 4% CPU time from boot on
heavy sites
- lodash adds non-negligible runtime to this loop, so we can just
replace it with native JS and cut 3% CPU time from boot for sites
with a large number of posts
- we have to deserialize the values from the DB to turn them into moment + boolean values
- the use of lodash adds unnecessary overhead to the function, and writing it in native JS
is a low faster
- also fixes the naming of the functions to make it clearer in flamegraphs
no issue
- config helpers are required early during boot and it requiring lodash added some unnecessary require+compile time
- switched to using an inlined escapeRegExp function in place of requiring lodash
no issue
- config utils are required early during boot and it requiring lodash added some unnecessary require+compile time
- switched to using native JS for the few lodash methods we used
no issue
- bumped gscan version to provide `skipChecks` flag to `check` function
- added `optimization:themes:skipBootChecks` config flag defaulting to `false` to maintain current behaviour
- updated theme service initialization to use `skipChecks: true` when the config flag is set
- we only want to skip the checks during boot in specific cases to improve performance, they are still useful for general development and any production use-cases where themes get edited directly on the server
- updated our theme validate module to accept and pass through `skipChecks` option
- switched the `isZip` positional argument of `validate.check()` to an options object property to make usage cleaner
- right now, we minify the assets on boot. This is wasteful because they're not even needed
- this commit implements a change which lazy-minifies these assets and
allows for cache invalidation when the theme changes
- it also introduces some middleware that each asset calls to ensure
that the assets are minified before serving
