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
