no-issue
The @tryghost/members-api module is being updated to export a BREAD
service which will be used to move the logic from the controller into.
This service is currently designed to returns objects rather than
models, as it has to do manipulation of the returned data at the object
level. This update to the serializer will allow a seamless transition to
the use of the BREAD service and allow us to pull out the logic from the
controller sooner!
refs https://github.com/TryGhost/Team/issues/946
This adds the initial bulk actions endpoint used for the members
filtering feature. The idea is to eventually move bulk destroy into this
endpoint to and provide a consistent interface for applying bulk actions
to members.
The @tryghost/members-api package has been bumped to include the new
bulkEdit method.
The sinon.restore in tests was moved to an afterEach so that stubs did
not effect other tests.
no issue
- Logic with slightly more complex structure belongs to the service. Extracting it there also show's how little of an API the oembed service should actually expose
refs https://github.com/TryGhost/Team/issues/990
- Relying on uuid instead of slug makes the posts less discoverable and partially soves discoverability through overriden robots.txt files
- Unquestionably, at some point we need to rework the API code so that we have less stuff everywhere
- However, the max-lines index.js rule exists as a proxy to find index.js files which are not exposing Public API, but rather contain logic
- These 6 cases are all valid index.js files as the expose the Public API of the module
- Therefore, I've added an override and an override notice explaining.
refs https://github.com/TryGhost/Team/issues/899
- The internal API is needed to be able to fetch email-only posts through email router. The concept is similar to Preview API with a difference that only posts with `sent` status are accessible and there is content-gating present.
refs https://github.com/TryGhost/Team/issues/953
- We need to track email-only posts that have been sent out. New status was chosen as a way to differenciate such posts.
- Introducing a new "email post" type, conceptually like "page", was considered. Because there is no clear roadmap for "email post" becoming a bigger part of the product yet and a lot of uncertainty around this concept, overhead needed to introduce a new type was just too much to do at this moment. It's still a possibility in the future
no-issue
This moves the logic out of the controller and into the members-api
member repository. Removing complexity from the controllers and
out into services is desirable to reduce code in the Ghost codebase
and move logic into modules which can be tested easier.
refs https://github.com/TryGhost/Team/issues/948
- The frontend route `/email/:uuid` is aliased to the preview as a temporary solution. It fulfills the premise of the email-only post anyway - not being accessible publicly and only shared through email.
- The tests for the new route are missing as adding them was way more problematic than I envisoned. They are in the works and will be added as a follow up commit next.
refs https://github.com/TryGhost/Team/issues/949
- Initializing PostsService with almost identical parameters is burdensome, having a single factory method in create instances is far more maintainable
refs https://github.com/TryGhost/Team/issues/949
- The post model handling related to newsletter sending and email recipient filter logic were duplicating across v3/v4(canary) APIs and it made sense to extract it into a posts service.
- This will allow for a central place to handle about to land logic for email_only newsletter handling.
refs https://github.com/TryGhost/Team/issues/949
- The code is exactly the same in six (!) places. It's beyond unmaintainable to add another line to any of these place, which will be needed for `email_only` handling.
- The newly created posts service is a temporary, slightly better solution that complies with codebase's best practice of extracting new services using class with DI pattern
refs https://github.com/TryGhost/Team/issues/949
refs e64274bb45
- This refactor is needed to bring the code in line with the rest of pages API controllers
- Next step will extract shared code patterns into a separate module
refs https://github.com/TryGhost/Team/issues/949
refs e64274bb45
- This refactor is needed to bring the code in line with the rest of pages API controllers
- Next step will extract shared code patterns into a separate module
refs https://github.com/TryGhost/Team/issues/949
- This refactor is needed to bring the code in line with the rest of post API controllers
- Next step will extract shared code patterns into a separate module
https://github.com/TryGhost/Team/issues/893
- The assignment is not that obvious and might be confusing without wider context, which is why it warrants to have a clarifying comment. This became apparent during code review
refs https://github.com/TryGhost/Team/issues/927
- the `email-cta` card can be segmented so only free or paid members can see the content, it should be possible for authors to preview what that will look like in either case
refs https://github.com/TryGhost/Team/issues/912
- Exposing a single method out of the service makes the API surface smaller - more readable.
- Additionlally having a wrapping method in service will be helpful for other triggers that are going to be executed in later iterations
no issue
- i18n is deprecated in favour of `tpl`
- normalized method syntax so `add` matches the rest of the controller's methods (fixed a complexity warning but was not the primary intention)
- This isn't really a "service" - it's a set of utilities for working with labs flags
- It's also required all over the place, and doesn't require anything that isn't shared
- Therefore, it should live in shared
- This isn't really a "service" - it's a set of utilities for working with labs flags
- It's also required all over the place, and doesn't require anything that isn't shared
- Therefore, it should live in shared
issue https://github.com/TryGhost/Team/issues/859
- Added invalidation to PUT /authentication/setup
- Added invalidation to POST /db
- Added invalidation to DELETE /db
- Added invalidation to GET /slugs/:type/:name
- Removed invalidation from PUT /users/:id/token
- This is a precursor to trying to split apart into:
- model events + webhooks system which makes sense
- frontend events which should be independent or removed
- maybe some concept of a settings manager that we can use in various places to bind logic 🤔
- other usages of events that should be refactored to not use events
refs https://github.com/TryGhost/Team/issues/856
- The default internal version of the API is expected to be the latest one available which is v4/canary at the moment.
- There will be more information posted in the referenced issue later around how to approach the "default version", for now it's just a change to make a small step into a right direction.
refs: https://github.com/TryGhost/Team/issues/831
- This ultimately fixes the index.js file
- It also makes it super clear what methods in the themeService are used by the API, and which are part of the service loading logic
- It also moves the activate and init function into a single file in a way that highlights they are very similar
- They are also very similar to what happens in storage.setFromZip but that code is mixed up with storage code at the moment
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/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
- 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
- The main goal here is getting this settings related code out of the routing service as it really doesn't belong there
- This settings file is used purely by the API to get and set files - its not really anything to do with actual routing
- This file calls out to the bridge to do a reload, which helps decouple slightly
- More refactoring is needed to get rid of the urlService dependency
- Note this file is really similar to the redirects one, it would be good to merge them
- 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
fixes https://github.com/TryGhost/Team/issues/818
- validation on query parameters should be wrapped in `options` within
`validation`
- this is missing from the theme install API endpoint so we don't force
the parameters to be passed in
- Ghost throws a 500 if `ref` is not supplied because following code
assumes we've checked the existence
- this commit wraps the two query parameter validation statements in
an `options` object to ensure they exist - Ghost returns a 422 if
missing
refs d9ddc2db6a
refs https://github.com/TryGhost/Team/issues/754
- The tests were written with falsy assumptions and validation added in refed commit have uncovered it!
- A secondary issue touched here is additional JSON object serialization that is used in the "input serializer" -d9ddc2db6a/core/server/api/v2/utils/serializers/input/settings.js (L107-L110)
- The additional stringification should not be there at all. It covers for a mistaken internal use of Settings API where raw objects are passed around instead of serialized JSON Objects (see commets left with this changeset for details)
refs https://github.com/TryGhost/Team/issues/754
refs a7dec233ba
- Additional validation protects from problems like the ones in refed commit from even getting through to the database.
- At the moment only used notificatons and couple more settings to ensure they are arrays when passed into the API. This is to avoid making big change in settings straight away - this is a problematic area which needs cautious approach.
- Ideally in the future the list of settings to check the "array" type (and other types) should be automatically generated based on the default-settings.json (or whatever way we define settings in the db a that moment)
- There's an ugly code-tripplication going on in this change. This is a separate topic that will be addressed once we work on API cleanup.
