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
fixes https://github.com/TryGhost/Team/issues/1652
fixes https://github.com/TryGhost/Ghost/issues/13319
**Image formatting**
Added support for changing the format of images via the `handle-image-sizes` middleware (e.g. format SVG to png, jpeg, webp)
This change was required:
- Not all browsers support SVG favicons, so we need to convert them to PNGs
- We can't fit image resizing and formatting in the `serve-favicon` middleware: we need to store the resized image to avoid resizing on every request. This system was already present in the `handle-image-sizes` middleware.
To format an uploaded image:
- Original URL: https://localhost/blog/content/images/2022/05/giphy.gif
- To resize: https://localhost/blog/content/images/size/w256h256/2022/05/giphy.gif (already supported)
- To resize and format to webp: https://localhost/blog/content/images/size/w256h256/format/webp/2022/05/giphy.gif
- Animations are preserved when converting Gifs to Webp and in reverse, and also when only resizing (https://github.com/TryGhost/Ghost/issues/13319)
**Favicons**
- Custom favicons are no longer served via `/favicon.png` or `/favicon.ico` (only for default favicon), but use their full path
- Added support for uploading more image extensions in Ghost as a favicon: .jpg, .jpeg, .gif, .webp and .svg are now supported (already supported .png and .ico).
- File extensions other than jpg/jpeg, png, or ico will always get transformed to the image/png format to guarantee browser support (webp and svg images are not yet supported as favicons by all browsers).
For all image formats, other than .ico files:
- Allowed to upload images larger than 1000px in width and height, they will get cropped to 256x256px.
- Allowed uploading favicons that are not square. They will get cropped automatically.
- Allowed to upload larger files, up to 20MB (will get served at a lower file size after being resized)
For .svg files:
- The minimum size of 60x60px is no longer required.
For .ico files:
- The file size limit is increased to 200kb (coming from 100kb)
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/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
refs: https://github.com/TryGhost/Toolbox/issues/229
- we are getting rid of the concept of having multiple api versions in a single ghost install
- removed all the code for multiple api versions & left canary wired up, but without the version in the URL
- TODO: reorganise the folders so there's no canary folder when we're closer to shipping
we need to minimise the pain of merging changes across from main for now
- 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 TryGhost/Team#1566
- Mocking a labs flag (regardless of enabled/disabled) currently has a side effect of setting any other flag to undefined.
- This meant in a test where we set a flag e.g. members-importer where we set multipleProducts, multipleNewsletters is always disabled
- This fix preserves the default state of all labs flags that are not mocked so that labs behaves how we expect
- Removed usage of GA flags in tests
- Removed tests that had GA flags disabled
Co-authored-by: Simon Backx <simon@ghost.org>
- 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/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`
refs: https://github.com/TryGhost/Toolbox/issues/168
- All of our unversioned tests should be running against canary already
- These tests are erroneously running on the wrong version
We're going to be dropping the idea of having multiple versions of the API in each Ghost version.
Because this has not achieved the goal of making it easier to make breaking changes, but it has
created an ordinate amount of technical debt and maintenance overhead.
As we know this is going away in the next major, there is no benefit to us constantly running tests
that check if those versions still work, especially given how long they take.
Instead we're starting work to ensure that all of our test work on canary, and that canary has
excellent test coverage so that we can be sure that our one API version works really well and that
any changes, no matter how subtle are deliberate, tracked and understood.
refs: https://github.com/TryGhost/Toolbox/issues/168
- These are all places where we reference an API version like v2 or v3 but it's not actually
used or relevant.
- The aim is to get rid of all mentions of these old versions to make it clearer that we're only running tests on canary
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.
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.
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
- this is a small part of a bit of cleanup of our test files
- the goal is to make the existing tests clearer with a view to making it easier to write more tests
- this makes the test structure follow the codebase structure more closely
- eventually we will colocate the frontend tests with the frontend code
