closes: https://github.com/TryGhost/Ghost/issues/10042
closes: https://github.com/TryGhost/Ghost/issues/14206
- the fact that pages are exposed as .page in dynamic routing has never played nicely
- this fix changes nothing in the tests - which shows this was never a covered case
- ideally I should add some tests, but for now this tiny change should prevent a lot of dynamic routing pain
- note, it doesn't remove .page, it just adds .post, so both work
refs https://github.com/TryGhost/Toolbox/issues/332
- With 'page' property being gone from page/post resources we need consistency across internal "preview API" too
- the handling is still hacky as we are exposing the "type" property to the preview pages, which is not exposed through Content API. this a long outstanding issue will have to be handled separately
refs https://github.com/TryGhost/Toolbox/issues/332
refs f5f1221e14
- Adding an `/edit/` post-fix to a static page URL broke when the `page: true` property support was dropped in the Content API
- The changeset adds tests covering the scenario for both page and post resources
closes: https://github.com/TryGhost/Toolbox/issues/324
refs: https://github.com/TryGhost/Ghost/issues/14446
- Currently, if url is configured to http but a request is marked secure, Ghost will handle upgrading all internal URLs to https so that there are no mixed content warnings
- From 5.0 that feature is going away, in favour of strictly honouring the configured URL
- Ghost will serve URLs exactly as configured and won't upgrade http to https anymore
- This use case was common when Ghost was first built, but in 2022 the web is mostly https.
- The code needed to support the feature creates a lot of additional complexity & maintenance overhead, so removing this gives us space to do more cool and useful stuff in 2022
refs https://github.com/TryGhost/Toolbox/issues/308
- we have a pattern of using plurals around Ghost but this was singular
- this shouldn't change any API functionality, it's just code
refactoring
- following on from removing api versioning logic from the frontend, it's possible to make more sense of what's happening
- this commit first introduces a proper jsdoc'd object that gets passed through the frontent load & reload flow
- that object contains the urlService and optionally our routeSettings processed from routes.yaml
- additionally, we were passing around a start boolean, which told the routerManager whether to just init, or init+start
- with this refactor, we always pass in the routeSettings when we want to do init+start, so we no longer need a boolean
- The refactor itself moves logic from the reload function in site.js and urlservice + routesettings fetching logic from routes.js
into the reloadFrontend function in bridge.js.
- This makes it clearer to see what happens when we call reloadFrontend.
- This commit also makes it clearer to see what is happening with the route settings, where they are needed and why
- Ideally we'd also clean up the weird dupliated logic and somewhat unnecessary routes.js file
refs: https://github.com/TryGhost/Toolbox/issues/228
- we are getting rid of the concept of having multiple api versions in a single ghost install
- we no longer need versioned routing configs
- we are getting rid of the concept of having multiple api versions in a single ghost install
- we no longer need to pass the apiVersion around using res.locals
- To simplify code that uses our frontend proxy the proxy now _only_ exposes canary
refs: https://github.com/TryGhost/Toolbox/issues/228
- we are getting rid of the concept of api versions from Ghost
- this means getting rid of them from the frontend as well, and from themes
refs https://github.com/TryGhost/Team/issues/1495
With multiple newsletters, members are allowed to manage their newsletter pref via email unsubscribe link with member uuid. Since Portal is now taking over handling unsubscribe for members, we don't need to keep the current `/unsubscribe` page as Portal can load the member's newsletter pref on site home page directly.
The redirect change is only enabled behind the `multipleNewslettersUI` flag as its in beta.
- Some of the helpers inside the routing service would be better suited to their own service
- These two helpers fetchData and entryLookup talk to the API to get data & so make a decent start for a data service
- The data service would be the single point of contact with the API for the frontend
- Doing this now cos I'm moving some files around ahead of deleting things for 5.0
refs https://github.com/TryGhost/Team/issues/1071
- `products` relation is needed on post/page to tackle custom tiers visibility, this change attaches `products` as default include for frontend controllers
refs: https://github.com/TryGhost/Ghost/issues/10434
refs: https://github.com/TryGhost/Ghost/pull/10449
refs: https://github.com/TryGhost/Ghost/pull/10559
- We originally had a weird structure returned for data keys in routes.yaml.
- To the best of my knowledge this was never desired or really used
- I'm removing it now simply because I'm trying to remove all references to v2/v3 in tests, and this had a comment saying it was deprecated in v3
- I could have changed the comment to be a proper @deprecated comment and leave this til we rewrite dynamic routing
- However it's weird and confusing and I believe entirely unused - so getting rid is way way better
- This is a minor bugbare, but it will affect some configuration I'm about to do for c8
- I've been wanting to do it for ages, middleware is plural all on it's own so it's an odd affectation in our codebase
- This also only exists in 2 places, everywhere else we use "middleware"
- Sadly it did result in a lot of churn as I did a full find and replace, but consistency is king!
refs 5a62253466
- The UrlService was relying on a "hidden" identifier field that was passed along with a router object. Now it's passed as an explicit parameter from the "frontend" to the backend's UrlService
refs https://github.com/TryGhost/Toolbox/issues/127
- Passing around whole instance of a frontend router was an overkill when there are only 3 static pieces of information that needed to be loaded. Extracting the router out makes the UrlGenerator way more readable, tests slimer, and the memory footpring of the process should be slightly lighter
- The toString overloading didn't make sense at the time of this refactor, maybe if there's a concrete usecase we could resurect it in a form of passing in a router's name or something.
refs https://github.com/TryGhost/Toolbox/issues/127
- This is an effor t to define a precise set of data needed for the UrlGenerator to function, which should help with decoupling it from the frontend routes
- This is almost the last piece to free us up from the massive "router" object that has been passed around
refs https://github.com/TryGhost/Toolbox/issues/127
- This is an effor t to define a precise set of data needed for the UrlGenerator to function, which should help with decoupling it from the frontend routes
refs https://github.com/TryGhost/Toolbox/issues/127
- This is an effor t to define a precise set of data needed for the UrlGenerator to function, which should help with decoupling it from the frontend routes
refs 74280cfbea
- We allow to send email-only posts when using v4 Admin API, but it's possible to configure a v3 Theme with a site instance which resulta in an unsupported behavior throwing a 500.
- With this fix a 404 will be returned when an email-only post is viewed through the public email-only post URL
refs https://linear.app/tryghost/issue/CORE-104/decouple-frontend-routing-events-from-urlserver-events
- The "bootstrap" didn't give enough credit to everything this module was doing - it's responsible for managing correct initialization and reinitialization of the frontend Routes as well as passing router creation information back to the frontend's URL service
- The refactor is done in two steps - the "bootstrap.js" will be renamed in the follow-up commit to have a clean history of how the file evolved
refs https://linear.app/tryghost/issue/CORE-104/decouple-frontend-routing-events-from-urlserver-events
- "routerCreated" call was causing a need to create a dependency on the frontend Router level which didn't fit nicely with the refactor of the bootstrap into a class, it's also makes way more sense having it as an independent parameter instead of a call on a module (makes testing way more readable too!)
refs https://linear.app/tryghost/issue/CORE-104/decouple-frontend-routing-events-from-urlserver-events
- The 'settings.timezone.edited' event triggers a roundtrip chain of calls in the frontend routing to the url services. It was all handled by event listeners and handler that clearly don't belong there.
- Extracted event realted listeners/handlers into methods and moved most of the logic to the "bootstrap" module, which soon is going to become a "RoutesManger"
- The result of this refactor - no more events going back and forth between frontend routing and the backend!
refs https://linear.app/tryghost/issue/CORE-103/decouple-internal-frontend-code-from-url-module
- By becoming a parameter in the routing bootstrap process URL is Service no longer a "require" inside the frontend controllers but rather becomes a part of the "internal API" of the bootstrapper. This is not the end form of it, rather a step closer to decouplint routing from the URL serivce.
- The bootstrap module needs a facelift to have cleaner distinction between init/start methods. This is left for another time
closes https://github.com/TryGhost/Team/issues/1125
refs 3c822e0457
- Email-only is not considered a general availability feature and can be used without special flags.
- It allows to publish a new post type "email only" that only goes out as an email newletter and is available through an undescoverable URL (does not appear anywhere publicly similarly to preview posts) on the site.
- i18n is an old pattern we are getting rid of in favour of tpl
- after removing i18n from helpers, there wasn't many usages of i18n left in the frontend, this removes whats left!
- this was done on a branch at the same time as Naz's commits removing i18n from the settings-related files
- hence some of these changes are minor amends to add additional messages/change names, rather than just straightup i18n->tpl
- it's a merge of both our refactors :)
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
refs https://github.com/TryGhost/Team/issues/953
- Emails posts should be not explorable by the rest of the frontend similarly to the draft or scheduled posts. Email posts should also keep the content gating, so that specific parts of content can still be gated based on the post's visibility setup
- A separate frontend router was chosen to implement this part of the system instead of a moutable express app due to increased complexity to introduce the latter approach.
- All "sent" email-only posts will be accessible through the `/email/:slug/` route
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/527
refs https://github.com/TryGhost/Ghost/issues/10790
- Frontent has to have as few as possible coupling points with the Ghost Server API. By design that point has been a "proxy.api" property that will become more and more constraint in the future based to limit the surface of frontend interaction with servers's API
- Removing `.../server/api` requires in favor of using a proxy decreases direct coupling
- 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
