no ref
Expose (some) Portal error strings for translations
💩This is a somewhat hacky (but test-passing and individual inspection
passing) solution to the way Portal handles errors. Or rather, the
half-dozen ways Portal handles errors.
Passing 't' around with context and state, and occasionally recreating
it from the site object. Yes, I am also somewhat horrified, but a better
implementation will need a major rewrite of Portal.
Addresses errors in both the popover React app and in the
data-attributes.
There are probably more. Since Portal exposes raw API responses in some
places, it's hard to enumerate everything that /might/ end up being
client-facing, but at least I've gotten the ones that I've commonly
seen.
Improvements very welcome.
no ref
- this caused some troubles with error representation and changed
defaulting behavior
Going back to the drawing board on this one. I've been working on a
larger scale refactor so that this could be a hook, which feels much
more appropriate, though a much more substantial change.
no ref
- Portal was not set up in a way to allow for easy use of the i18n
module for errors, as they weren't a React component
- moved away from the class model to a functional component that could
utilize React state (AppContext)
I'm working on a different refactor that would convert more of Portal to
hooks & functional components so that the codebase is more consistent
and easier to read. This will have to work for the moment while that is
being done, as that's no small task.
ref KTLO-1
These tokens should prevent untargeted attacks, as the magic link
endpoint needs a token that was generated by the server, similar to a
CSRF token, but without needing any server-side state, or a cookie to
be set for unauthenticated users.
no issue
- During the one click subscribe flow, the outboundLinkTagging should
affect whether we send a history or not to the signup endpoint. But for
internal history this is the members_track_sources setting. This happens
in the backend normally.
- Do not send a (constructed) history to external sites (= one click
subscribe flow in recommendations) if outboundLinkTagging is false
- Do always send a history internally for local signups (backend handles
whether to store it based on the members_track_sources setting that is
currently not exposed in the frontend). The history is not built if this
setting is disabled, but we could have an old history entry if this
setting was enabled in the past.
no issue
- Do not set ?ref in recommendations if analytics is disabled
- Do not send url_history if analytics is disabled
- Expose outboundLinkTagging as a public setting
refs https://github.com/TryGhost/Product/issues/3770
- Site is not always defined, so the things broke when using the signup action without a defined site, where it wants to read the recommendations_enabled setting
- Fixed this by removing the welcome page and looking for the existing query params instead
refs https://github.com/TryGhost/Product/issues/3771
- if recommendations are enabled, render the recommendation modal on
sign up, in Portal
- for free signups, the recommendations modal is rendered after clicking
on the magic link
- for paid signups, the recommendations modal is rendered after Stripe
Checkout
- the recommendations modal is not rendered on a free to paid upgrade
refs https://github.com/TryGhost/DevOps/issues/50
- `react-app` comes from `eslint-config-react-app`, which is a CRA package
- we're moving away from that so this commit switches the linting over
to a more recently updated plugin
- once that was removed, we started using a newer version of
`@typescript-eslint/eslint-plugin`, so there were plenty of
updates/exemptions to make
