refs https://github.com/TryGhost/Toolbox/issues/283
- The header is needed to signal to the webhook subscribers the content version they are being served. This should imrove API version compatibility and allow for the client to handle incoming data better
refs https://github.com/TryGhost/Toolbox/issues/283
- In tests we need assurance that the triggering of webhooks has been finished before making assertions. Doing this was impossible with a previous fire-and-forget style of the request call.
- The change also adds an optional "request" parameter to be able to override the request library used internally - this is purely for testing purposes.
refs https://github.com/TryGhost/Toolbox/issues/283
- Current trigger module handling webhook paypload delivery isn't testable! It sucks to add features to it without assurance things still work
- Apart from expanding the test suite this changeset also needs live testing - setting up webhooks etc.
refs: https://github.com/TryGhost/Team/issues/1599
refs: f3d5d9cf6b
- this commit adds the concept of a frontend data service, intended for passing data to the frontend from the server in a clean way. This is the start of a new & improved pattern, to hopefully reduce coupling
- the newly added internal frontend key is then exposed through this pattern so that the frontend can make use of it
- the first use case is so that portal can use it to talk to the content API instead of having weird endpoints for portal
- this key will also be used by other internal scripts in future, it's public and therefore safe to expose, but it's meant for internal use only and therefore is not exposed in a generic way e.g. as a helper
refs https://github.com/TryGhost/Team/issues/1603
When previewing a scheduled/published post via Post editor menu > E-mail newsletter > Preview in browser. The e-mail template from the default newsletter was used instead of the newsletter that was selected when scheduling the post.
no issue
The message was removed somewhere, but the git history looks to be modified so I couldn't find the reference to when and why it was removed (the message seems to be added and removed in the same commit).
Added in: e849167472
No reference to where it was removed. But after the same commit above, it wasn't present any longer.
- These settings no longer exist, having been renamed to timezone and lang
- As of 5.0 we no longer need any kind of backwards compatibility outside of the importer
- We making breaking changes and cleaning up as many old code paths as possible
- We have not really exposed the admin Settings API, meaning backwards compatibility was more for internal use
- We will be changing lang back to locale, but that's a separate issue and won't need backwards compatibility
closes: https://github.com/TryGhost/Toolbox/issues/324
refs: https://github.com/TryGhost/Ghost/issues/14446
- Currently, if url is configured to http but a request is marked secure, Ghost will handle upgrading all internal URLs to https so that there are no mixed content warnings
- From 5.0 that feature is going away, in favour of strictly honouring the configured URL
- Ghost will serve URLs exactly as configured and won't upgrade http to https anymore
- This use case was common when Ghost was first built, but in 2022 the web is mostly https.
- The code needed to support the feature creates a lot of additional complexity & maintenance overhead, so removing this gives us space to do more cool and useful stuff in 2022
refs https://github.com/TryGhost/Toolbox/issues/309
- this column is not used and I was going to add `validation` to it but
it's better to clean it up and re-add the column if we need it again
- async/await makes the code easier to read
- also means we can get rid of usages of Promise, and some unnecessary usages of Bluebird
- this refactor is done for the 4 async helpers and the code that wraps async helpers so the whole pipeline is async/await and more understandable
refs https://github.com/TryGhost/Toolbox/issues/292
- Copy improvements were done base on feedback. Makes the information in the email more concise and removes unecessary/unsecure bits like query strings.
refs: https://github.com/TryGhost/Team/issues/626
- calculated settings are simplified settings (booleans) that are based on other settings or data
- they make it easier for us to determine what state features are in elsewhere in ghost e.g. admin and themes
- this duplicates some of the members config concepts in the settings service
no issue
- When applying an incorrect limits config, or missing expected values, Ghost would not boot as the errors would interrupt this process, which should not happen
- This commit catches the error thrown by the limit-service on boot sequence and transforms it into a warning if it's an `IncorectUsageError`. Other errors are handled as before
- Added a test for the limit-service service
refs: e68cb8b314
- a couple of months ago when improving the test coverage here I found some weird behaviour with falsey values
- turned out it didn't matter at the time because we didn't have any settings that are false
- with the introduction of calculated settings we will have: https://github.com/TryGhost/Ghost/pull/14766
- whilst building that, I found settings that should be returned as false were being returned as null
- fixing it in a separate commit to keep the work clean
- It's time, we want to be able to use more modern features, and now we're on node 14 min this makes sense
- @TODO: do this in eslint-plugin-ghost and add new rules to guard the new features
- by default, the model will auto-refresh when you save
- in MySQL, which doesn't support RETURNING, this is implemented by
doing a SELECT after your actual query
- `email_recipients` is a huge table and `processed_at` is not an
indexed column, so the query times can become realllyyyyyyy big
- given we don't even need the result of the model save, we can just
disable fetching all the affected records again
- Bookshelf gives us this ability in the form of `autoRefresh: false`
refs https://github.com/TryGhost/Toolbox/issues/309
- these stopped being added to the DB in v3 but there was never a
migration to clean up existing permissions and the role link in the DB
- we now have the utils to do this cleanly, so we can drop all the
permissions in this migration
no issue
- Setting a dedicated source for imported members was already done with 455778662c
- This unifies the same source but keeps the usage of context setting on init alive
- The recently refactored path matching code forgot to take into account that originalUrl can include the subdir
- Added more permutations to tests and ensured that all tests pass
- This means we don't have to worry about what sort of path we pass to the function, it'll figure out the version and api info
- this will drop the link between a role and a permission, and then
delete the permission
- required minor refactoring to aid in creating migrations for dropping
the links and permission
- I'm refactoring the utils to make way for dropping permissions but the
utils are in a real mess
- to aid my refactoring, I want to make the utils a folder, so the
migrations that require utils as a file need updating
- this commit does that
refs: https://github.com/TryGhost/Team/issues/1599
- add an internal integration for Ghost's frontend to talk to the content API
- this is so that portal and future features can access our APIs through the correct mechanism of an API key
refs https://github.com/TryGhost/Toolbox/issues/325
- this was used for an alpha proof-of-concept for member activity data
collection but we're rethinking the strategy so this is the easiest
way to ensure it can't be enabled when the database table has been deleted
refs https://github.com/TryGhost/Toolbox/issues/292
- Providing user-defined Integration name instead of API client's UserAgent gives a lot more control to instance administrators identifying which integration is being used incorrectly.
- It's best practice to create an Integration with a set of API keys per API client - which should be enough to identify an outdated one.
refs https://github.com/TryGhost/Toolbox/issues/309
- this table was used an an experiment for member analytics
- as we rethink the strategy, we can take the opportunity to clean the table up
- we have these rules in place to force the developer to think about the
performance impact of their code
- unless they are enforced, it's easy for them to slip by and miss them
- this commit changes the warnings to errors, which will fail CI
- developers still have the ability to disable lines that flag the
linting in case there is a valid use-case
