refs: cf514cdf7
- in commit cf514cdf7 we moved the loadSettings call up to the bridge
- here we can call the async method, so we can remove loadSettingsSync altogether
- all the tests have now been changed to use the async method
- following on from removing api versioning logic from the frontend, it's possible to make more sense of what's happening
- this commit first introduces a proper jsdoc'd object that gets passed through the frontent load & reload flow
- that object contains the urlService and optionally our routeSettings processed from routes.yaml
- additionally, we were passing around a start boolean, which told the routerManager whether to just init, or init+start
- with this refactor, we always pass in the routeSettings when we want to do init+start, so we no longer need a boolean
- The refactor itself moves logic from the reload function in site.js and urlservice + routesettings fetching logic from routes.js
into the reloadFrontend function in bridge.js.
- This makes it clearer to see what happens when we call reloadFrontend.
- This commit also makes it clearer to see what is happening with the route settings, where they are needed and why
- Ideally we'd also clean up the weird dupliated logic and somewhat unnecessary routes.js file
refs: https://github.com/TryGhost/Toolbox/issues/229
- we are getting rid of the concept of having multiple api versions in a single ghost install
- removed all the code for multiple api versions & left canary wired up, but without the version in the URL
- TODO: reorganise the folders so there's no canary folder when we're closer to shipping
we need to minimise the pain of merging changes across from main for now
refs: https://github.com/TryGhost/Toolbox/issues/229
- we are getting rid of the concept of having multiple api versions in a single ghost install
- we no longer need to worry about what version of the API we should use to schedulei content
- this, as with all of our api versioning logic, was questionable anyway, and mostly just unnecessary complexity
refs: https://github.com/TryGhost/Toolbox/issues/229
- we are getting rid of the concept of having multiple api versions in a single ghost install
- we no longer need to worry about what version of the API we should use to send content
- this, as with all of our api versioning logic, was questionable anyway, and mostly just unnecessary complexity
refs: https://github.com/TryGhost/Toolbox/issues/228
- we are getting rid of the concept of having multiple api versions in a single ghost install
- we no longer need versioned routing configs
- we are getting rid of the concept of having multiple api versions in a single ghost install
- we no longer need to pass the apiVersion around using res.locals
- To simplify code that uses our frontend proxy the proxy now _only_ exposes canary
refs: https://github.com/TryGhost/Toolbox/issues/228
- we are getting rid of the concept of api versions from Ghost
- this means getting rid of them from the frontend as well, and from themes
refs TryGhost/Team#1495
With multiple newsletters, members are allowed to manage their newsletter pref via email unsubscribe link with member uuid. Since Portal needs to manage member's newsletter pref via their UUID, we need new endpoints on members that allow fetch/update of newsletter subscriptions via only uuid. The endpoints return only limited data for a member that are needed for the UI.
- adds endpoint to fetch newsletter subscriptions for member via uuid
- adds endpoint to update newsletter subscriptions for member via uuid
no issue
needs 82eb861955
Set the context to `importer` for any members importer actions which will determine the correct source of origin in the members events table
- these packages contain minor code or dependency updates but we're
forced to publish them because of Lerna
- this commit rolls up all pending updates into one commit to save noise
refs https://github.com/TryGhost/Team/issues/1495
With multiple newsletters, members are allowed to manage their newsletter pref via email unsubscribe link with member uuid. Since Portal is now taking over handling unsubscribe for members, we don't need to keep the current `/unsubscribe` page as Portal can load the member's newsletter pref on site home page directly.
The redirect change is only enabled behind the `multipleNewslettersUI` flag as its in beta.
- `.substr()` is deprecated so we replace it with .slice() which works similarly but isn't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
closes: #14440
- use best available values to provide alt tags on images in amp.hbs
- this prevents certain tools from reporting errors/warnings with our amp pages
- Newsletter defaults were a static object with the default UUID resolved once
- This caused conflicts on subsequent create requests
- Defaults are now resolved as a function so each call gets a new UUID
- Promoted the flag to beta to allow manual enabling via the database
- The UI for this flag is intentionally still gated behind developer experiments in Admin
refs TryGhost/Team#1566
- Mocking a labs flag (regardless of enabled/disabled) currently has a side effect of setting any other flag to undefined.
- This meant in a test where we set a flag e.g. members-importer where we set multipleProducts, multipleNewsletters is always disabled
- This fix preserves the default state of all labs flags that are not mocked so that labs behaves how we expect
- Removed usage of GA flags in tests
- Removed tests that had GA flags disabled
Co-authored-by: Simon Backx <simon@ghost.org>
refs https://github.com/TryGhost/Team/issues/1550
- Updated email template and seder options to use the settings specified for the related newsletter
- Falls back to the default newsletter, and uses the default newsletter settings for the publishing preview because we only assign a newsletter at the point a post is published
Co-authored-by: Thibaut Patel <thibaut.patel@gmail.com>
Co-authored-by: Matt Hanley <git@matthanley.co.uk>
refs https://github.com/TryGhost/Team/issues/1545
**Changes (`members-api`)**
- Compare via https://github.com/TryGhost/Members/compare/%40tryghost/members-api%406.0.0...%40tryghost/members-api%406.1.0
- Added mapping from member subscribed to newsletters on edit/create
- When editing or creating a member with the subscribed property, it is mapped to the corresponding newletters value
- Defaults to all active newsletters with visibility = members and subscribe_on_signup = true
**Tests**
- Adds test that adds a member with subscribed = true
- Adds test that adds a member with subscribed = false
- Adds test that edits a member with subscribed = true
- Adds test that edits a member with subscribed = false
refs https://github.com/TryGhost/Team/issues/1561
With multiple newsletters, unsubscribe links will also need to have a unique reference to the newsletter that the email is for, so that we can unsubscribe members from the particular newsletter automatically when they click on the link.
As our existing pattern for members is to use UUID as the external unique reference, this change adds UUID to newsletter schema and populates the existing newsletters with a UUID value.
- adds new `uuid` column to newsletter schema
- updates newsletter model to add default uuid
- updates default newsletter migration to add `uuid`
- drops nullable on `uuid` column later in migrations once we have populated existing newsletters
- these packages contain only code changes or dependency updates but
we're force to publish new versions due to Lerna's limitations
- this commit bulk updates the packages to save having many commits
refs 58ace0af76
- please see the referenced commit above for full context but this
commit bumps `@tryghost/nodemailer`, which contains a fix for reading
credentials when using the SES mail transport
- credits to @touzoku
closes: https://github.com/TryGhost/Team/issues/1553
- we want to be explicit in what values are supported
- we want the values that are supported to be supported to also be explicit and clear
- without this API users can set the value to anything and the active/not active logic will work, until such time as we introduce further statuses
- this means introducing a new status could be a potential breaking change and lands us in horrible hot water
