refs https://github.com/TryGhost/Toolbox/issues/226
- We are on the finish line to release 5.0 - the instance should be validating it's themes agains v5 set of rules.
- The prominent deprecations are `{{author}}` and `@blog` helpers removals - will throw 'fatal' errors when encountered.
- we have two JSON error response formats one old, one new (v2)
- we couldn't use the new one everywhere before without changing the response from older versions
- that is totally irrelevant in Ghost 5.0 as there is only one API version
- therefore we can and should use the new response format everywhere
- eventually we should rename it so it doesn't have v2 in it
refs https://ghost.slack.com/archives/C02G9E68C/p1651484563907609
- When the site has an empty name, it is set to `NULL` in settings.
- The name column is not nullable in newsletters, breaking the migration in that case.
- Fixed by excluding all non-nullable columns
- Replaced JS Date object with raw SQL `CURRENT_TIMESTAMP`
refs https://github.com/TryGhost/Toolbox/issues/308
- we have a pattern of using plurals around Ghost but this was singular
- this shouldn't change any API functionality, it's just code
refactoring
closes: https://github.com/TryGhost/Toolbox/issues/296
- This is a small change to permit any known API version to redirect to an unversioned URL
- We include v2 because although it should have been deleted in 5.0 anyway, in the spirit of the change away from versioned URLs there's
absolutely no sense in forcing people to update clients that still work for no reason.
- We use a 307, because this preserves the original HTTP method, allowing POSTS, PUTs and DELETEs through as well as GETs
- We set the accept-version header on the redirect, meaning that for example with a request to the old /v4/ api, Ghost will respond as though
the client sent `accept-version: v4.0` and if there are known breaking changes, it may choose to inform the admin and owner users of these
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
