refs https://github.com/TryGhost/Arch/issues/86
- When PostEditedEvent data contains no visible changes we can skip the matching collections update process alltogether. Each call to `updatePostInMatchingCollections` creates a transaction in addition to fetching all collections. There's no need to process anything when there are no relevant changes in the post edit!
refs https://github.com/TryGhost/Product/issues/3809
When an input is added to a custom sign-up form with the attribute
`data-members-newsletter`, the value of the input will be used as the
newsletter to subscribe the member to.
refs https://github.com/TryGhost/Product/issues/3770
- Site is not always defined, so the things broke when using the signup action without a defined site, where it wants to read the recommendations_enabled setting
- Fixed this by removing the welcome page and looking for the existing query params instead
closes https://github.com/TryGhost/Arch/issues/85
- Added a cache configuration option to signal "reuse of redis connection" for Redis cache adapter. The connection reuse it turned on by default to be shared between caches. They rely on unique "keyPrefix" structure, so there is no collision side-effects when reusing same Redis Store.
- The Redis connection options like "ttl" are shared with the first connection that's crated. So if there's a need to have unique configuration, a separate connection has to be created by passing `"reuseConnection": false` parameter
closes https://github.com/TryGhost/Product/issues/3803
Previously when the beta editor was enabled, using `?source=html` to create posts via the API would create posts in the old editor rather than the beta. This change switches conversion over to the new editor format when the beta is enabled so the full flow can be tested.
- added `htmlToLexicalConverter` method to our lexical library
- updated post and page input serializers to add html-to-lexical conversion when the beta editor is enabled
- updated post model to handle the mobiledoc+lexical co-existing state
- this is a special case that is only valid for `?source=html` because providing both directly via the API is prohibited
- we need the extra check here because at the input serializer layer we don't have access to the model to check if we're updating a mobiledoc post or a lexical post so the serializer sets both formats on a `?source=html` request when the beta is enabled and lets the model handle choosing the correct one
fixes https://github.com/TryGhost/Product/issues/3820
- This adds a new public site endpoint in the members API to check if a
site can offer the one-click-subscribe feature
- This is implemented on the members API as a copy of the `site`
endpoint because the admin API site endpoint is protected by CORS and
mainly because it can be served on a different domain than the
recommended site and this is hard to detect reliably from the frontend
- Added a new calculated setting `allow_self_signup`, which can replace
the setting that is currently used in Portal (best to do this after a
release otherwise we risk creating issues if a patch release happens)
no issue
- recently added code to grab apple touch icons or SVGs before falling back to the default metascraper behaviour wrongly assumed that every size would have a `rel` and `href` attribute which is not the case
no issue
- recently added code to grab apple touch icons or SVGs before falling back to the default metascraper behaviour wrongly assumed that every size would have a `rel` and `href` attribute which is not the case
refs https://github.com/TryGhost/Product/issues/3807
- Added announcement bar customisation to Admin X
---
<!-- Leave the line below if you'd like GitHub Copilot to generate a
summary from your commit -->
<!--
copilot:summary
-->
### <samp>🤖 Generated by Copilot at 91368ce</samp>
This pull request enhances the `AnnouncementBarModal` component to
enable users to customize the announcement bar on their site. It adds
editing and previewing features, as well as API integration and toast
notifications.
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
