refs https://github.com/TryGhost/Team/issues/1665
- sodo search script only needs the admin url for fetching data from content api
- removes site url and updates the main url to use admin domain
refs https://github.com/TryGhost/Team/issues/1665
- The search script should be uniquiely identifiable in DOM. Previously element for portal scipt element and search element both had `data-ghost` attributes` for identification. Having `data-sodo-search` makes naming unique
no issue
- The sodoSearch needs to be injected into rendered HTML the same way portal scripts are.
- The feature is behind a `sodoSearch` alpha flag, so the scripts are injected conditionally
refs https://github.com/TryGhost/Team/issues/1664
- added `comments:url` config for a similar setup to Portal
- added `{{comments}}` helper that's behind the `comments` labs flag
- currently outputs a `<script>` tag that points to the comments script with API location+key data attributes
refs https://github.com/TryGhost/Team/issues/1650
Since we introduced calculated settings, we need to return all settings when editing a setting, because those calculated settings can change.
- When editing settings, return all the settings. Previously we didn't include the calculated settings (which caused issues with admin not having up to date values for those)
- Updated Stripe <head> script to be injected based on the calculated settings
Required for https://github.com/TryGhost/Admin/pull/2405
refs https://github.com/TryGhost/Toolbox/issues/332
- After removing the concept of a boolean "page: true" from the page/post resources frontend resource rendering didn't have enough information to pick the correct template
- Resolved this issue through passing of additional "context" to the template picker. Something nicer should be worked on in the future, as context pattern feels dirty here.
refs: https://github.com/TryGhost/Toolbox/issues/327
- lang / locale has had a lot of churn, but we decided this setting should always be locale
- session_secret is too generic as we have multiples of these
refs: https://github.com/TryGhost/Team/issues/1599
refs: f3d5d9cf6b
- this commit adds the concept of a frontend data service, intended for passing data to the frontend from the server in a clean way. This is the start of a new & improved pattern, to hopefully reduce coupling
- the newly added internal frontend key is then exposed through this pattern so that the frontend can make use of it
- the first use case is so that portal can use it to talk to the content API instead of having weird endpoints for portal
- this key will also be used by other internal scripts in future, it's public and therefore safe to expose, but it's meant for internal use only and therefore is not exposed in a generic way e.g. as a helper
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
- async/await makes the code easier to read
- also means we can get rid of usages of Promise, and some unnecessary usages of Bluebird
- this refactor is done for the 4 async helpers and the code that wraps async helpers so the whole pipeline is async/await and more understandable
- 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
- `.substr()` is deprecated so we replace it with .slice() which works similarly but isn't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
- This fits more closely, as this service is to so with rendering helpers and small parts
- Whereas we want to use "rendering" for things concerned with rendering pages
refs: https://github.com/TryGhost/Ghost/commit/11867ab43
- These checks live in the wrong place. They are mostly a frontend thing
- The only server place they were used was slack and that was fixed in 11867ab43
- Moving these to the frontend they fit neatly into the frontend data service
refs https://github.com/TryGhost/Team/issues/449
- Once we deprecate site.lang use in favor of site.locale this helper will need inspection for potentially breaking change. Left a note to come back to it once it's time
refs https://github.com/TryGhost/Team/issues/1004
Replaces {{products}} helper usage with updated {{tiers}} helper. Default output for {{tiers}} helper is the same as {{products}} helper.
refs https://github.com/TryGhost/Team/issues/1004
- adds new `{{tiers}}` helper behind `multipleProducts` flag
- `{{tiers}}` outputs a string with list of tiers 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 tiers attached to post column for data
refs https://github.com/TryGhost/Team/issues/1367
- The {{access}} property of a post always returned false for non-public content
- Added the member context to the get, next-post and prev-post helpers
- The get, next-post and prev-post helpers didn't add the member context to the internal API calls
- Added the members context to these calls
- Added tests that check if the member context is passed to the API calls
- Transformed next_post helper tests to async await syntax
- Transformed prev_post helper tests to async await syntax
refs https://github.com/TryGhost/Team/issues/1386
- The current match handler supports normal (in)equality operators, but no numeric comparisons (<, >, <=, >=)
- A use case for these new operators is to show the latest post in a separate way from other posts
Includes unit tests to check the new behaviour.
Run via `yarn test test/unit/frontend/helpers/match.test.js`
- I recently added a bunch of strict rules to our eslint plugin around returns: ca9af37866
- These mostly are issues that occur whilst writing code, that you spot and fix as you're developing, but they're annoying to notice/find and eslint can be used to flag them quickly
- There are of course, edge cases where you don't need to return from array fns, but this rule also suggests better patterns might be available
- For our excert helper and new assertEvent helper, I've updated the code to use simpler patterns that are easier to read, so as to avoid the warnings
- For our old API I've simply disabled the rule as we're about to delete this code
no issue
- the new eslint bump seems to flag this line up for using camelcase
- i'm not sure why this hasn't flagged before but it seems we want to
keep the naming because the function name has the same linting exemption
fixes https://github.com/TryGhost/Ghost/issues/13832
The `date` handlebars helper has only one option currently — `format`. It assumes the locale and timezone from the `options.data.site` object which is not always desired behavior.
The helper sometimes is used, for example, in custom RSS template where we always need the `en-US` locale, not the one that we have configured for the website globally. This change makes the two options configurable, and defaults to the `options.data.site` object values, if not specified in the helper (keeps the backwards compatibility with the current behavior).
refs https://github.com/TryGhost/Team/issues/1251
With sites that have a huge number of resources, using limit="all" can
cause OOM errors at the Node level. Administrators now have the ability
to cap limit="all" requests via config. This only affects the get helper
used in themes, not the API, this is by design as themes have less
visibility of issues.
no-issue
Using the async attribute means that the script is downloaded in
parallel with the parsing of the html into DOM, and then executed upon
completion. This means that the script cannot be sure that particular
parts of the DOM exist as it may not have finished parsing. This has
resulted in bugs with the new toggle card not working.
Switching our script to use the defer attribute means that the script is
still downloaded in parallel with parsing, but it is not executed until
parsing is complete. This means that the script can safely access the
DOM.
refs https://github.com/TryGhost/Team/issues/960
- Character like "%%" or "%80" would crash our current url escaping behavior. We consider they aren't valid URLs as the percentages haven't been properly escaped.
- Wired up the forntend to include and serve the minified css and js card assets if they exist
- This is a very naive implementation - ideally we wouldn't have to inject this in multiple places
- This allows us to add files to src/cards and have them included in themes
- The system is currently disabled due to an override in the theme config setting assets to false
refs https://github.com/TryGhost/Team/issues/1190
- The assets were broken in Admin when the frontend and admin urls were different
- Fixed the issue by changing the `asset` helper to output absolute URLs when the frontend/admin urls are differents
refs: https://github.com/TryGhost/Team/issues/759
- The match helper allows for basic equals and not equals comparisons,
Example:
{{match title "=" "Getting Started"}}
{{match slug "!=" "welcome"}}
- There's a lot more functionality we want to add here, so that it ends up being a replacement for {{#has}}
- However, this first iteration is already useful, especially in the context of custom theme settings
- Therefore we are adding it early, and will document it along with custom theme settings when that goes GA very soon
refs: https://github.com/TryGhost/Team/issues/759
- No matter what, a handlebars helper outputs a string. So if you return true, you'll always get 'true'.
- SafeStrings are handlebars's way of passing around a string whilst also maintaining a record of the original value e.g. new SafeString(true) results in {string: true}
- We need this for the match helper, so that we know when doing a comparison that we're meant to be comparing against a boolean true, not a string true
- Therefore, we need to putput SafeStrings, but also process them when passed in
The logic
- Figuring out the correct logic here has been a little tricky but essentially:
- {{match safestring}} with a single arg, will return true for any truthy value
- {{match safestring "=" true}} does a direct comparison with the original value of the safe string, so if it was a boolean true, the match will be true else false
- {{match (match something) "=" true}} will therefore work for any level of nesting
- this can result in slightly inconsistent results, but feels correct and documentable
This is documented extensively through the test cases
- The helper registration code is "framework" code and very specific
- At the moment the "theme engine" is full of lots of disparate theme related stuff
- I'm trying to make the frontend framework code clearer and also expand it to make it more useful
- The helper system now also exposes 3 methods allowing you to register a directory, a helper or an alias
- I've updated the codebase to use these both for our core helpers and for "apps"
- The original intention of the proxy was to collect up all the requires in our helpers into one place
- This has since been expanded and used in more places, in more ways
- In hindsight there are now multiple different types of requires in the proxy:
- One: true frontend rendering framework requires (stuff from deep inside theme-engine)
- Two: data manipulation/sdk stuff, belongs to the frontend, ways to process API data
- Three: actual core stuff from Ghost, that we wish wasn't here / needs to be passed in a controlled way
- This commit pulls out One into a new rendering service, so at least that stuff is managed independently
- This draws the lines clearly between what's internal to the frontend and what isn't
- It also highlights that the theme-engine needs to be divided up / refactored so that we don't have these deep requires
- 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
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-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/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.
