- The frontend proxy is meant to be a way to pass critical internal pieces of Ghost core into the frontend
- These fundamental @tryghost packages are shared and can be required directly, hence there's no need to pass them via the proxy
- Reducing the surface area of the proxy reduces the proxies API
- This makes it easier to see what's left in terms of decoupling the frontend, and what will always need to be passed (e.g. api)
Note on @tryghost/social-urls:
- this is a small utility that helps create URLs for social profiles, it's a util for working with data on the frontend aka part of the sdk
- I think there should be many of these small helpers and we'll probably want to bundle them for the frontend at some point
- for now, I'm leaving these as part of the proxy, as need to figure out where they belong
- 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://linear.app/tryghost/issue/CORE-35/refactor-route-and-redirect-settings
- The only allowed route settings name is 'routes.yaml', which removes a need to parameterize the function as the location is permanent anyway
- Simplifying the function in any possible way before extracting the common bits into an external lib
refs https://linear.app/tryghost/issue/CORE-35/refactor-route-and-redirect-settings
- Frontend is not meant to know about the underlying source of the "routes" configuration, so any reads/edits/validations are being moved into a backend service. This should also simplify the coupling of the backend with the frontend where the latter will get a JSON blob with all needed configuration during the boot
- Nother problem the "get" method had was hiding an underlying function it was doing - reading the file from the filesystem SYNCRONOUSLY. It might be a thing we need to do during the "web" app initialization, but there's no clear need to do this in a sync fassion during the bootup for example. Also having a more explicit name should help :)
refs https://linear.app/tryghost/issue/CORE-35/refactor-route-and-redirect-settings
refs c1c9bf0866
- Actions logic related to file system operations (like ensuring files exist) should be done on the backend. Now the route settings initialization logic lives on the backend it makes sense to keep the file closer to the source.
- The move is the opposite to the one refed in the commit with a
difference that the file now lives in "route-settings"
refs https://linear.app/tryghost/issue/CORE-35/refactor-route-and-redirect-settings
- 'knowSettings' was based on a "configurable" array of settings that might be configured in Ghost. The multitude never happened! The only setting the frontend takes care of is routes.yaml file (redirects is also kind of a setting but is a separate concept for now).
- Having just one type of file to deal with allows to simplify implementation significantly, which helps before a big refactor
refs https://linear.app/tryghost/issue/CORE-35/refactor-route-and-redirect-settings
- This is a micro-step towards getting rid of multiple "knownSettings" concept. Since the introduction of an array of knowSettings there was never-ever a need to handle anything but a single `routes.yaml` file. Getting rid of this concept first to have a simpler module. Next step would be getting rid of filesystem reads/writes in the "frontend"
refs https://github.com/TryGhost/Team/issues/1070
- added `@tryghost/custom-theme-settings-service` as a dependency
- `core/server/services/custom-theme-settings` creates an instance of the new service passing in the model used for storing the setting keys/values and a cache instance
- requiring `core/shared/services/custom-theme-settings-cache` creates a cache instance, it has no dependencies so can be required anywhere and the first require will initialize the shared instance
- updated the theme activation bridge to trigger the theme settings service to sync the newly activated theme settings and populate the cache
- updated theme validation to pass `labs` through as an option so that we get custom theme settings back as part of the checked theme as that's what is passed to the custom theme settings service
refs https://github.com/TryGhost/Team/issues/1063
Member activity is a labs alpha feature which aims at capturing member events for site owner if switched on. The event metadata captures the site page/post where the event originates from, and the post/page id is included as content of new ghost analytics meta tag. The meta tag is only aded on the site if member activity is switched on from labs.
closes: CORE-34
refs: https://github.com/TryGhost/Team/issues/1044
- this is a super basic fix, it adds a max nodes concept and limits the node in each sub-sitemap to 50k by default
- this will prevent the error in google console
- a better fix is in progress, but we want to at least solve the errors ASAP
closes: CORE-33
Two bugs:
- lodash isEmpty and handlebars util isEmpty are not the same
- I literally had the truthy and falsy cases the wrong way around 🙈
Notes:
- I have, for now, copied the isEmpty util from handlebars. It's so small it doesn't seem worth trying to require the util right now, although in future it'd be nice if that was easier to do
- Adding the management for the conditional being a SafeString allows the match helper to be a subexpression of itself, I can see this pattern being useful later in combo with the any and all helpers
refs https://github.com/TryGhost/Team/issues/1004
- adds new `{{products}}` helper behind `multipleProducts` flag
- `{{products}}` outputs a string with list of products that have access to specific post when used in a post context in theme
- outputs empty string when used out of a post context and without access to `visibility` property
- uses all available posts for a site via the global products data
- updates {{content}} helper cta to use this new helper to show list of tiers with access to post
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/907
The logic to populate the `@price` data and the `@products` data both
rely on the same product data, but were each making their own request to
the API. This refactor removes the request from the legacy `@price`
data, which should cut the database queries in half.
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 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
- 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: 076ad99593
- as of 076ad99593 we no longer use the error property of the active theme anywhere
- cleaning up and removing this usage reduces the code pathways and makes the init fn a bit clearer
refs https://github.com/TryGhost/Team/issues/856
- This syntax gives easier understanding of modules dependencies and improves searchability. For exampke, I was looking for all "api" uses exposed by the server proxy and didn't have a clear picture into which modules used it.
- The change was made during a short-lived try to limit the use of "api" in the server proxy :) I thought it would be helpful when bumping the defult server API exposed internally. Next time!
- The router bootstrap is no longer allowed to fetch it's own settings, but rather is passed them
- This moves the call to the site routes.js file, which isn't much better but it's a start
- The goal is to always pass these in from the boot process, or from the bridge reloader
- Reduced the number of levels in our debug naming in the frontend
- Unified components like "themes" and "routing" under one name
- Should help to make debug slightly more useful again
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/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
