refs https://github.com/TryGhost/Team/issues/849
With multiple products, we have re-enabled segmentation by product for posts behind alpha feature flag. This change handles the default content cta to show custom message if the post's access is restricted to specific products when behind the flag.
refs https://github.com/TryGhost/Team/issues/849
As part of work for segmented post access with multiple products, the custom filter for post access is stored in `visibility` field on posts but passed with `visibility_filter` property on API. This change -
- updates input serializer of posts to transform `visibility` and `visibility_filter` properties correctly
- updates output serializer for canary to transform and send `visibility_filter` attribute with filter value
- updates output serializer for v3 to ignore any custom filter on visibility and return `paid` instead as v3 didn't have a concept of custom filter
refs https://github.com/TryGhost/Team/issues/849
Custom post visibility (behind alpha flag) is added to the API using new `visibility_filter` attribute that stores the custom filter. This change -
- updates validator for visibility to check new `visibility_filter` property
- cleans usage of i18n in favor of tpl
refs https://github.com/TryGhost/Team/issues/849
With multiple products back behind alpha flag, we want to bring back segmented post access for members which allows site owners to set post access to specific products. This change -
- updates admin-api-schema to allow `visibility_filter` attribute to post/page response
- We have a lot of tests, so it can be hard to see if any are problematic
- We have a problem with some tests being too slow, this highlights these in particular
- Very slow tests that take seconds are not really unit tests, we should look for different ways to run these
- Also we should tailor our mocha settings more, so that we have more lenient settings for acceptance/regression tests but not for unit tests
- Note: You have to wait for all tests to run to see the output
refs https://github.com/TryGhost/Team/issues/727
- The version was forgotten to get a bump durin g 4.0 release. The API version used by update check should be the same as internal default.
- Because the current internal default is mistakenly set to v3 API it's still not optimal but will need a holistic solution in the future
closes https://github.com/TryGhost/Team/issues/781
refs 076ad99593
refs https://github.com/TryGhost/Ghost/commit/2b73d0f66
refs https://github.com/TryGhost/Ghost/commit/bab12ca3d
- With refs 076ad99593
landing in main there is no more 500 error stopping us from bumping the version
- Previous versions of gscan wasn't able to detect partial usage inside
of a helper, e.g.: "{{#if author}}{{> "missing_partial"}}{{/if}}". It's
important to be able to detect these on theme upload/validation stage to
avoid errors during the runtime.
- The updated version provides additional information about used and
unused partials and helpers.
- With this change users might start seeing a "fatal" error during an
upload/activation of a theme previously passing validation. Currently
active themes with partials used in the context will still allow for a
boot, but will log a 422 error pointing to missing partial.
refs https://github.com/TryGhost/Team/issues/781
refs 813d288eb2#
- The 500 error was introduced through a refed commit long time ago when (probably?) there were no other safeguards preventing from serving content through a theme with errors. Since than we have multiple safeguards when aploading/activating the theme with errors and the default handling when such error occurs is more graceful - a 400 with specific error details is shown
- We need this change to land before bumping gscan that introduces more suphisticated error detaction in theme templates. Otherwise, people upgrading to new version and having an error on an unused template or somewhere undetected previously woul end up with a bricked site showing a generic 500 - not a great experience!
refs: fbf0636936
- I renamed this pattern in a bunch of places, but missed a few, leaving the code messy and confusing
- This makes the naming consistent
no refs
- adds `price` data on subscription from related `stripe_price` on updating a member via frontend
- removes inconsistency between `GET` and `PUT` data for logged in member on a site
refs https://github.com/TryGhost/Team/issues/828
- Previous method had a bug where it didn't take into account cases when onlya single card with a segment filter has been used leaving the members not covered by that filter without an email
refs https://github.com/TryGhost/Team/issues/828
- Before sending out batches with members we need to partition all members based on the segment they belong to. Special segment "unsegmented" is used in case none of the segments used in the emal cards cover part of the members set (for example only free members card used when emailing all members)
refs https://github.com/TryGhost/Team/issues/845
refs 517d2abc5c
- updated router response formatting functions and `{{#get}}` helper response handling to make any `feature_image_caption` properties in the response a `SafeString` instance so triple-curlies are not needed when using the property in themes
- The main aim here is to end up with a simple and clear public API for the meta module
- Secondarily, we want to make it a bit clearer which bits don't really belong here so we can see what to do with them
- To achieve this, the main logic has been moved into get-meta (although there's still some logic here which needs moving further)
- The index.js now has a small clear public API, and the proxy, which is the only way this is consumed, is able to use the public API directly
- This function is quite different to the others, as it generates an excerpt from HTML (truncating)
- Most functions in the meta data folder just contain content negotiation logic, like if post then feature_image else cover_image type things
- This function is more like a library and shouldn't live in Ghost, it should probably be in @tryghost/helpers
- It's definitely something we'd love to rewrite to work better tooooo
refs https://github.com/TryGhost/Team/issues/839
It's now possible to set alt and caption for post feature images using `feature_image_alt` and `feature_image_caption` fields on a post resource.
- `feature_image_alt` - plain text, limited to 191 chars (alt text is not recommended to be longer than 125 chars, screen readers may cut the description off at that point)
- `feature_image_caption` - basic HTML, limited to 65535 chars
Alt and caption will be automatically used inside of newsletter content, for your website content make sure your theme is updated to use the v4 API and make use of the new properties.
---
- removed `featureImageMeta` labs flag
- we moved the meta folder out of data a really long time ago
- we also moved the sitemap out of data/xml into a service
- this moves the tests to roughly match
- getting rid of instances of new Error as we should always use @tryghost/errors
- Whilst here, got rid of i18n but discovered the messages were missing!
- This is my fault, they disappeared when I removed external apps and clearly removed too much: 8c1a0b8d0c (diff-0f5cc40aa8906a1be1bad2002a35361bbf9e766e46b3b29be10f4f479265426a)
- Therefore, I have restored these messages in the places where they were used, except amp_content, where I have written a new message, as the message that was there was not relevant
refs: 10d02e8343
refs: 83a30775bf
refs: 3355f627c4
refs: 0e9b950558
- In eslint-plugin-ghost 2.4.0 I moved some of the rules implmented in Ghost as they are global rules, including:
- no new Error() - use @tryghost/errors
- forcing index.js to be under 50 chars as a leading indicator for misuse of index files
- I also added new rules to check for tpl('literal string') and the deprecated ghost-ignition package
- Because the new Error and tpl rules are both implemented with no-restricted-syntax, the local rules overrode the global one
- Removing the rule here allows the global ones to work
- Have to think about how to do this long term
- This is part of the quest to separate the frontend and server & get rid of all the places where there are cross-requires
- At the moment the settings cache is one big shared cache used by the frontend and server liberally
- This change doesn't really solve the fundamental problems, as we still depend on events, and requires from inside frontend
- However it allows us to control the misuse slightly better by getting rid of restricted requires and turning on that eslint ruleset
- requiring lib/common/events makes the settings cache tightly coupled to the server
- moving this up to settings index means the cache itself can be moved to a shared component/moved out of Ghost
- the index then becomes the settings manager
- questionable whether the event listeners & updater part of this shouldn't be part of a manager, independent of the actual cache 🤔
refs https://github.com/TryGhost/Team/issues/828
- We need a way to recreate a filter that was used to create an email content for specific email_recipient. By saving member_segment value for each email_batch we can traverse back to the filter that was applied during email creation.
- shutdown removed listeners, which should really be done before adding them anyway!
- reset sets the cache back to an empty object, which was already done by init
- merge these into one reset function that fully resets the cache
- all instances of shutdown were called before an init call, and now called during init, therefore these can be removed
- acceptance utils had an instance of calling shutdown and reset together as part of stopping Ghost, reworked that to be clearer
refs https://github.com/TryGhost/Team/issues/828
- When sending email batches out they need to be created without mixing different member segments. This allows for easier reasoning about what data has been sent out to each specific email recipient
- Modified email batches to chunk based on segments defined in the HTML content of the post
refs https://github.com/TryGhost/Team/issues/828
- When detecting email segments and later creating a member filter out of this data we only care about unique segments otherwise we'd be creating multiple batches with the same segment filter
refs https://github.com/TryGhost/Team/issues/828
- This is experimental segment extraction logic, more to follow. Alllows to extract arrays of email segments used in the email's HTML content
refs https://github.com/TryGhost/Team/issues/827
- Ghost needs an ability to insert email-only content for defined segments of members - at the moment distinguishing only free&paid ones.
- The card with a "segment" payload should contain a valid NQL statement to target specific members
- At the moment the bootstrap.start method asks the settings service for its settings
- This couples the routing and settings services together - when maybe we want to use a different method to generate settings
- By passing the settings to the routing service at the right time, we open up possibilities for refactoring
