Google AMP is on the way out. In Ghost 5.0 we changed the integration's
default state to be `disabled`, and we have planned to remove it
completely in Ghost 6.0 for a while — but we haven't shared this
anywhere.
@gergelyorosz bumped into this today:
https://twitter.com/GergelyOrosz/status/1729778093777100973
This PR is to start communicating our intent to remove AMP in the next
major release of Ghost, by adding inline messaging to the integration
settings in Ghost Admin
fixes GRO-72
- added "default_email_address" and "support_email_address" to the
public settings
- when available, use these addresses in Portal. Otherwise, fallback to
current logic
no issue
When the from address of a newsletter is empty, and a custom sending
domain is setup the preview would display 'From: Sitename ()' instead of
'From: Sitename (default@address)'.
When a custom sending domain was setup, but a different from address was
saved, we'll also no longer display it in the input fields - as it will
also be ignored IRL.
refs GRO-76, GRO-90
- Reused `renderReplyToEmail` and `renderSenderEmail` from
`NewsletterDetailModal.tsx` like Simon suggested
- Changed Newsletter preview header in Newsletter settings to show
Reply-to address instead of the “To” mock placeholder
- When no custom sending domain is set, switched “Sender email address”
to disabled TextField for better visual rhythm
- Added a link to the help doc for (Pro) users without custom sending
domain set (the doc itself will still need to be updated though, but Sam
and the gang are already aware of this)
- When custom sending domain is set, added a hint about the default
value, which IMO is clearer than using a placeholder
fixes GRO-88
Instead of going to the previous page when visiting /#/portal, it will now go to the default page:
- Sign up if you are not signed in
- Account home if you are signed in
Previously, it had the same behaviour, with the difference that it would also go to the previous page if there was any.
no issues
- SortMenu component used to have only one global default direction
option, however, the sorting options needed individual default sorting
direction. e.g. desc for created data, or asc for name etc
- this adds an optional sorting direction option to sorting options, so
when they're defined, they'd override the global default sorting
direction
refs GRO-80
- added a new meta field "email_verified" to the /verification endpoint
for newsletters. This meta field contains which email has been verified,
"sender_email" or "sender_reply_to"
- updated copy in newsletter settings, based on which email has been
verified
no issues
- active/archived tabs are no longer hidden, they're always visible
regardless of if there's an offer or not
- same for the modal footer, it's always visible
- used a simple NoValueLabel component instead of custom no offers view
refs GRO-73
- fixed validation for reply-to address
- fixed rendering of default values for reply-to and sender-from fields
- added a temporary generic message for the verification confirmation,
so that it's compatible with both reply-to and from address changes. The
message will be improved in a follow-up commit (pending an API change).
fixes GRO-73
We need to avoid duplicating the complex logic for determining the
default email address and the support email address. So these are now
exposed as calculated settings.
refs. https://github.com/TryGhost/Product/issues/4169
- the detail page for the Admin X proto app was empty
- the asc/desc selector of the SortMenu component in the design system needed a bit of refinement
- page toolbar was not set
refs GRO-59
refs GRO-56
refs GRO-52
- When email is managed without a custom domain, do not allow the Sender
Email address to be changed, but allow Reply-to address to be changed to
any address the publisher can verify
- When email is managed with a custom domain, allow both Sender and
Reply-to addresses to be changed without verification, but not their
domain names
---------
Co-authored-by: Djordje Vlaisavljevic <dzvlais@gmail.com>
refs. https://github.com/TryGhost/Product/issues/4169
- some of the new components were not prepared for mobile sizes and dark
mode
- Storybook settings had to be updated to include mobile sizes that
reflect the actual system
