refs https://github.com/TryGhost/Toolbox/issues/308
- this endpoint is currently used to send a test email with the post
- it currently returns a 200 with whatever the response of the mail
service is
- this body isn't used in Admin nor is useful generally because it just
contains the ID of the mailgun response
- it's better than we change it to 204 and no response
- this commit does that and updates the tests
refs https://github.com/TryGhost/Toolbox/issues/268
- After the logic change the number of posts no longer decreases - reassignment does not delete posts
- In a follow up commit will add a more sophisticated check for actual reassignment
refs https://github.com/TryGhost/Toolbox/issues/268
- When the user is removed our current pattern was deleting their posts. This didn't work well and created all sorts of problems
- As a solution we now reassign any posts that are only authored by the deleted user to the owner user
- This change also reduced the dependency on "author" field
refs https://github.com/TryGhost/Toolbox/issues/308
- I recently pluralised the API endpoint but never made the changes to
the controller file and everywhere else it's needed
- this commit cleans up that inconsistency so it should be clearer
refs https://github.com/TryGhost/Toolbox/issues/308
- we had a few mentions of `subscribers` in the test suite data generator
but this shouldn't be used any more because it's an ancienttttt concept
- removing this for v5 as it helps to clean the codebase
refs https://github.com/TryGhost/Toolbox/issues/308
- these endpoints return no body but they were implemented to return a
200 error code
- 204 would be more suitable so this commit changes that for v5
- also removes the passthrough serializer and updates the snapshots to
reflect the changes
refs https://github.com/TryGhost/Toolbox/issues/308
- this endpoint has no body to return but it was initially implemented
as returning a 200 which we couldn't change until 5.0
- this changes it to a 204, removes the serializer and updates tests to
take this into account
refs https://github.com/TryGhost/Toolbox/issues/308
- I've just renamed the `/authentication/passwordreset` API endpoint to
`/authentication/password_reset` and noticed the body object is also
badly named
- this clears that up in code and tests
refs https://github.com/TryGhost/Toolbox/issues/308
- we have a pattern of using plurals for API endpoints but it was missed
when we implemented email previews
- this fixes that for v5 and updates the tests accordingly
- there's some cleanup here to fix the API controller name too which
I'll add to the list
refs https://github.com/TryGhost/Toolbox/issues/308
- this endpoint isn't used by Admin, nor Ghost, and isn't documented
publicly
- we are nuking it in v5 so the easiest step to achieve that is by
removing the API route mounts
- there's plenty of cleanup here, including refactoring other API
controllers to avoid using the `mail` API controller, but this is the
easiest way to achieve what we want
refs https://github.com/TryGhost/Toolbox/issues/300
- the previous commit deleted all v1/v2/v3 migrations
- Ghost-CLI forces you to update to the latest minor in your major
before you upgrade but people who aren't on the latest minor, who don't
use Ghost-CLI and try to update to v5 might have missed migrations that
I've just deleted
- the way to protect against this is to add some migrations for the last
minor in each major, that will throw an error if they get run
- this uses a feature of knex-migrator where it will always try to
backfill missing migrations when you run Ghost, so these new migrations
should _only_ be run if the Ghost DB hasn't already run the same number
of migrations in that minor
- by throwing an error, it'll cause knex-migrator to fail and the user
shouldn't be able to update, which is good
- v2 and v3 only have 1 migration so I can just replace that, but v1 has
2 migrations. I think it makes more sense that the first one errors
and the second one is a no-op otherwise it'll run the first migration,
succeed, run the second, error, and then rollback the second and first
one
- the new migration names are different from the original ones but that
shouldn't matter because we're not comparing nor storing them
refs https://github.com/TryGhost/Toolbox/issues/300
- due to Node compatibility, it only makes sense that users on the latest
v3 (and v4) can update to v5
- therefore, we don't need v1/2/3 migrations as it's more maintenance in
the long run
- this deletes over 5000 lines of code (!!)
- In the interest of simplifying and cleaning up this code which affects Ghost's boot process
- Moved config to DI, injecting only known properties. It's expected that you must restart the server to pick up new config
- Even in tests!
- Got rid of unused bluebird code, but also reworked some promise-based code to be simpler using util.promisify
- As far as we know this is no longer used by anyone
- It was added by a contributor many moons ago, before we had Ghost CLI
- As we're prepping to ship a stripped-back 5.0, this seemed like a great deletion candidate.
- If anyone used it, they can add it back in with tests :)
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>
