closes https://github.com/TryGhost/Product/issues/3799
- the recommendations_enabled setting is updated when a recommendation
is created or deleted. It's enabled as soon as there is at least one
recommendation in the database
- the recommendations_enabled setting exists to avoid fetching the
recommendation count from the database directly in themes. The setting
is cached and doesn't need a read every time from the database
closes https://github.com/TryGhost/Product/issues/3827
- links following a line break in the editor were being rendered before the line break when previewing/publishing
- bumps Koenig packages which includes relevant fix in `@tryghost/kg-lexical-html-renderer`
reverts TryGhost/Ghost#17912
- unfortunately dropping save tasks when one is already running has side-effects for code that is initiating the save tasks
- e.g. the slug or title update actions call `saveTask.perform()` and if that related save request fails they expect to get a standard request error so they can show a message and perform a model rollback. However with `keepLatest` the save task can be dropped and "fail" immediately with a `TaskCancelation` error which has unintended side-effects:
1. error handling is no longer tied to the specific request meaning we could have slug-related failures being handled by non-slug-save code which is unexpected
2. the internal `TaskCancelation` error is handled as if it was general error and we end up showing a useless error in the red error bar that makes it look like something failed when it didn't
3. we initiate a model rollback when we do not have a failure situation that requires it meaning we can lose changes
reverts TryGhost/Ghost#17912
- unfortunately dropping save tasks when one is already running has side-effects for code that is initiating the save tasks
- e.g. the slug or title update actions call `saveTask.perform()` and if that related save request fails they expect to get a standard request error so they can show a message and perform a model rollback. However with `keepLatest` the save task can be dropped and "fail" immediately with a `TaskCancelation` error which has unintended side-effects:
1. error handling is no longer tied to the specific request meaning we could have slug-related failures being handled by non-slug-save code which is unexpected
2. the internal `TaskCancelation` error is handled as if it was general error and we end up showing a useless error in the red error bar that makes it look like something failed when it didn't
3. we initiate a model rollback when we do not have a failure situation that requires it meaning we can lose changes
refs https://github.com/TryGhost/Product/issues/3815
- recommendations are rendered in a random order, using Fisher-Yates
shuffle
- only 5 recommendations are rendered by default, the other ones are
hidden behind a "Show all" button
- recommendations are fetched all at once from the backend, as we assume
there won't be more than 100-ish recommendations per publication
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/70
- I've moved the code and history into the Actions repo to keep these
things more maintainable
- this commit updates the reference to the action
refs https://github.com/TryGhost/Ghost/issues/17932
- we were missing `chunk.208.dbf172ad32f72f21a5dc.js` from our published tarball
- turns out this is due to the lines in the `.npmignore` file to remove
.db files, which also matched this file
- we can make the regex more specific to avoid these cases
refs https://github.com/TryGhost/Product/issues/3745
---
This pull request adds a new feature to the `admin-x-settings` app that
allows users to customize the colors of their email newsletters. It also
simplifies and refactors the routing logic and the components related to
integrations, newsletters, and users. It introduces new dependencies and
components for color manipulation and selection, and updates the
existing components and stories to use them.
refs https://github.com/TryGhost/Product/issues/3349https://ghost.slack.com/archives/C0568LN2CGJ/p1693556448443489
- fixes an issue that's caused an infinite loop in the Portal design modal and stressing the CPU.
---
<!-- Leave the line below if you'd like GitHub Copilot to generate a
summary from your commit -->
<!--
copilot:summary
-->
### <samp>🤖 Generated by Copilot at ac33e3e</samp>
Refactors error handling logic for signup options form fields in
`SignupOptions.tsx` using `useCallback` and `useEffect` hooks. This
enhances the code quality and efficiency.
closes https://github.com/TryGhost/Product/issues/3675
refs c98bf80248
As part of our architecture guidelines Repository implementations should protect
against invalid or malformed data in persistence. We do not want read operations
of Entities to throw because of such data. For some fields that bad data can be
fixed or handled in the constructor or static create factory method and replaced
with valid data, others will cause the factory to throw.
This means that Repositories should catch these errors and exclude those
entities from their results. We log the errors in Sentry so that we have
visibility on the state of bad data in DBs
JSDoc has a problem with using values as types across repositories, rather than
getting `Offer` as the type we end up with `typeof Offer` as the type - which is
incorrect. Instead we use `import` syntax inside of JSDoc which resolves correctly
As per our architecture guidelines we want to keep bookshelf implementations of
Repositories in Ghost core, so that all the bookshelf code is kept together, and
the packages implementing business logic with entities and services require less
dependencies to test. This separation should also help us inadvertently add
business logic to repository implementations by having a more "physical"
boundary between them.
I don't think we need to instantiate and use the `equals` method here. It adds
an extra dependency to the Repository implementation, but it is slightly more
"correct" as it means that we leak internals by comparing strings exactly?
The ValueObject pattern here was very much a trial and isn't something we're
necessarily sticking with, so I don't see a problem with this string comparison.
We do not want our Repositories to implement business logic like deciding which
events should be created. As that creates too tight of a coupling, and makes it
harder to swap out repositories in future. Instead they should only be concerned
with the storage, retrieval and hydration of Entities from the persistence engine.
no issue
- Also fixes a backend issue with nullable fields
- Fixes blurring the url input and setting the value to '/'
automatically while we expect absolute urls
- Added autoFocus to inputs
no issue
- adds explicit waits for the two save tasks when leaving the editor before any other checks or saves are triggered
- cleans up some errors around task cancellation that could be triggered when leaving the editor with an existing save running
no issue
- when a post is new it has no revisions but in the `willTransition` hook we were using `lastRevision.get` even though `lastRevision` was null
- adjusted the `hasChangedSinceLastRevision` conditional to always be `false` for new posts
