ref https://linear.app/tryghost/issue/ENG-1254
- we currently only store a cancellation reason when a member cancels
manually in Portal
- we now also store "Payment failed" when the cancellation is automatic
due to several payment failures
refs
[ENG-709](https://linear.app/tryghost/issue/ENG-709/%F0%9F%90%9B-bad-redirects-causing-container-tear-down)
Added validation to prevent RegEx's susceptible to ReDoS from being used
with custom redirects. Also moved error details out of `context` and
into `errorDetails` to be consistent with error logging elsewhere as
well as fix issue in admin-x where blank screen would be shown when an
error occurred during redirects upload (due to logic not accounting for
`context` being an object)
fixes https://linear.app/tryghost/issue/ENG-642
- When a subscription is in the `canceled` state the corresponding
Member has no access to the Ghost site. The only time a Member will
continue to have access if their subscription is due to cancel at the
period end is if it is still in an active state, which is one of
`active` `trialing` `unpaid` or `past_due`
- When a subscription is canceled immediately (i.e. before the end of
the current billing period), we now render "Ended" without a date,
because we don't store the cancellation date in the subscription object.
We previously used "Ended {current_period_end}" which would sometimes
lead to dates in the future
- Bonus: refactored code and added unit tests
---------
Co-authored-by: Sag <guptazy@gmail.com>
- the existing code creates a new moment instance, takes away some days
and then formats the result
- this is run for every entry of the member attribution stats, which
means dashboards for big sites with a lot of attribution data become
slow
- this value doesn't change across each iteration of the filter, so we
can just extract it out and calculate it once
- this commit removes this code block from the flamegraph completely
fix https://linear.app/tryghost/issue/ENG-779/%F0%9F%90%9B-cmds-does-not-save-member-profile-changes
- previously, pressing Cmd+S on a member profile would save the profile,
but the dirty attributes weren't being cleaned, so the application
would trigger the leave confirmation when exiting
- now, we've fixed the code to keep a dynamic scratch member,
- long term, we should get rid of the scratch model, but this still
allows us to fix the bug for now
closes https://linear.app/tryghost/issue/ENG-1255
- updated Koenig packages including:
- addition of `/preview` for public preview card
- fix for HTML import from Google Docs
- fix for embed thumbnails being cut off in email
- fix for wide image card width on medium screens
- multiple fixes for unhandled (but non user-visible) errors causing noise in console and error logging
ref https://linear.app/tryghost/issue/ONC-111
- changed posts fetching/display behavior to be client-side instead of server-side
- admin will issue (potentially multiple) requests based on the desired status(es)
- updated admin acceptance test for missing coverage
I've pulled the sort from the database query as this triple sort
performs very poorly at scale (taking ~4s+ past ~20k posts sometimes).
Instead, we now split up the fetch to grab only one status at a time and
use the front-end logic to handle displaying scheduled, then drafts,
then published. This should result in a much more responsive view.
We will separately change the default sort on the Admin API as that was the ultimate intent for this change.
- `faker` was the original dependency but the maintainer ended up
deleting the repo, so development continued in `@faker-js/faker`
- we're already using that dependency, so we can make a few simple
changes and remove the old dependency from our repo
DES-27
There are two patterns used in settings modals for action buttons:
1. [Cancel] and [Save & close] (sometimes it's [Cancel] and [OK],
inconsistently) — example: Staff details, Tier details, Navigation,
Recommendation
2. [Close] and [Save] — example: Design settings, Portal, Newsletter
details etc.
This is confusing and leaves people confused and uncertain about what's
going to happen in one or the other case.
ref https://linear.app/tryghost/issue/SLO-173/removed-distinct-from-member-count-query
Performance of GET /members API can be improved by dropping the distinct from the total members count query.
select count(distinct members.id) as aggregate from `members`; // 275ms
select count(*) as aggregate from `members`; // 30ms
In this case we know that the result set will always be unique.
ref https://linear.app/tryghost/issue/ONC-111
- added composite index to posts_tags for post_id,tag_id for faster
lookup
- added composite index to posts for updated_at; this is commonly used
by get helpers on the front end to display data like the latest posts
In testing, this provided a very dramatic improvement for simple get
helper requests like 'filter="id:-{{post.id}}+tag:sampleTag" limit="3"'
which are by default sorted by updated_at desc. I'm not entirely clear
why when sorting by published_at we do not need a composite index - so
far it doesn't seem to be necessary. This should cover the primary cases
for get helpers - the latest posts with a given tag or set of tags.
fix https://linear.app/tryghost/issue/SLO-168/rangeerror-maximum-call-stack-size-exceeded
- this code takes the API output and reduces it down to collect together
stats per date
- the current code is recursive, and we've seen errors with the
recursion hitting a `RangeError: Maximum call stack size exceeded`
error
- as well as that, we're doing a lot of array concat'ing and cloning,
which burns memory and CPU time
- instead, we can just use `.reduce`
- the new implementation is much faster than the existing one (1ms vs
85ms) and uses no recursion, so those errors should go away
- I've also verified that the output is the same between the two
functions
