refs PROD-60, PROD-222, PROD-223, PROD-89, PROD-94
- Indicator shows up in the monthly/yearly toggle if there are any paid
tiers with yearly discount, and shows the highest discount in order to
nudge visitors towards checking out yearly plan
- A couple of smaller portal improvements: typos, spacing, alignment
---------
Co-authored-by: Simon Backx <simon@ghost.org>
refs https://github.com/TryGhost/Product/issues/2795
---
<!-- Leave the line below if you'd like GitHub Copilot to generate a
summary from your commit -->
<!--
copilot:summary
-->
### <samp>🤖 Generated by Copilot at 2a6b633</samp>
This pull request improves the localization of the portal feature for
Serbian users by adding or updating translations in the `portal.json`
file.
fixes https://github.com/TryGhost/DevOps/issues/120
- we've seen errors in CI where the unit tests for the apps folder are
being run concurrently, but the build assets are not present so
multiple builds are happening for the same folder
- this leads to errors because Vite tries to cleanup or build folders
at the same time
- this should fix that by eagerly building the apps and caching the
output so unit tests run quicker
closes https://github.com/TryGhost/Product/issues/4227
- added `@onTKCountChange` to `<KoenigLexicalEditorInput>`
- when present the `isTKEnabled` flag will be turned on and the `<TKCountPlugin>` registered
- added `@registerAPI` support to `<KoenigLexicalEditorInput>` so we can focus the caption editor when its TK indicator is clicked
- added manual display of TK indicator for the caption input
- default editor indicator positioning doesn't work for this input because its container is not full editor width
- hid it by adding `overflow: hidden` to the inner caption container
- added custom indicator button shown when we have a non-zero count
no issue
- recently we introduced code that broke the editor in older versions of
Safari but we weren't alerted to it until we started getting customer
reports
- we have an `ErrorBoundary` around the React editor components but this
wasn't reporting the error anywhere and simply showed an error message
- updated the boundary to report to Sentry when configured so we can
notice and fix any editor-breaking issues faster
refs https://github.com/TryGhost/DevOps/issues/119
- members_newsletters needs members_subscribe_events, but it was also
then generating `subscriptions` records and the whole thing was really
slow
- for now, subscriptions is not a used table so we can remove use of it
- also adds support for generating more than one subscription record
with an 80% chance of being subscribed
refs https://github.com/TryGhost/DevOps/issues/119
- this function can simply call the `import` function, which performs
the same code as we had here
- this makes the code cleaner to read and understand
refs https://github.com/TryGhost/DevOps/issues/119
- this switches away from using a static list of names in favor of ones
generated by faker, so we don't run into duplicate names
- also minor code re-arranging
refs https://github.com/TryGhost/DevOps/issues/118
- we should standardize how we run MySQL, so there aren't massive gaps
in developer experience
- Docker is great for this, and it's pretty easy to set up
- this adds a docker-compose.yml file with a small MySQL setup
- also configures `yarn setup` to spin up the Docker container and add
it to config.local.json
- in the near future, we'll provide a base SQL file in .github/scripts/mysql-preload
to ensure the DB is in a known state
refs https://ghost.slack.com/archives/C02G9E68C/p1701939292474999?thread_ts=1701881060.000299&cid=C02G9E68C
- when you change branch or do a `git pull`, Nx will kill the watch
command
- this becomes annoying when you're doing local development because it
tears down the whole `yarn dev` command
- this puts the nx watch command in an infinite loop so it's just
restart again and concurrently doesn't detect it as a failure
refs ARCH-21
- We currently have NewRelic setup for a few of our largest customers
for monitoring performance, but it is too expensive to enable across all
sites
- Sentry has similar (but simpler) performance monitoring tools to keep
track of response times that are available to us for free, but we just
haven't configured them
- This PR sets up Sentry Performance monitoring for API requests so we
can have one place for monitoring errors + performance so we can stay on
top of response times more easily.
- Tracing is disabled by default, so there is no additional overhead
unless `sentry.tracing.enabled` is set to `true` in the site's config.
Additionally, `sentry.tracing.sampleRate` should be set to a decimal
value between 0 and 1. This value defaults to 0 to avoid accidentally
blowing through quota, and requires a value to explicitly be set in
order to send the traces to Sentry.
