fix broken pages & bump algolia components

Author: Logan Graham

docs/api-testing/on-prem/how-to/generating-fake-test-data.md

@@ -22,7 +22,7 @@ Does your API or test require random full names, valid/invalid ids, or various t
 
 There are a couple of ways you can generate this data:
 
-- You can directly reference the method within your variable, API call, or anywhere in the test where you can type in the following syntax: "${F.zipCode()}"
+- You can directly reference the method within your variable, API call, or anywhere in the test where you can type in the following syntax: "$\{F.zipCode()}"
   For example:
 
   <img src={useBaseUrl('img/api-fortress/2019/07/Screen-Shot-2019-07-19-at-11.33.10-AM.png')} alt="screenshot" />

docs/api-testing/on-prem/io-components.md

@@ -42,7 +42,7 @@ _**Parameters:**_
 | Mode     | 'json','xml', 'html','text' | Yes          |
 | Params   | String                      | No           |
 
-**Url:** the url of the resource you want to test. It could be the full url of the resource or a string with variables using the $. (i.e. 'https://domain/resourcename' or 'https://${domain}${endpoint}')
+**Url:** the url of the resource you want to test. It could be the full url of the resource or a string with variables using the $. (i.e. 'https://domain/resourcename' or 'https://$\{domain}$\{endpoint}')
 
 **Variable**: the name of the variable that contains the response. It will be the name you will refer during the test.
 

docs/api-testing/on-prem/quick-start/introduction-to-integration-testing.md

@@ -41,7 +41,7 @@ We do this so we don’t have to manually invoke or set a variable every time it
 
 <img src={useBaseUrl('img/api-fortress/2018/04/Screen-Shot-2018-04-12-at-12.31.27-PM.png')} alt="Set Variable"/>
 
-Now, call the variable `“access_token”` and assign the value to ${payload.Token}. The response body from the original post call was saved to a variable called “payload.” The key to access the token is named `“Token”`, so you may find it by calling `“payloadToken”`. Be sure to wrap this all in `${}` so that API Fortress knows to interpret what’s between the brackets instead of using it literally.
+Now, call the variable `“access_token”` and assign the value to $\{payload.Token}. The response body from the original post call was saved to a variable called “payload.” The key to access the token is named `“Token”`, so you may find it by calling `“payloadToken”`. Be sure to wrap this all in `${}` so that API Fortress knows to interpret what’s between the brackets instead of using it literally.
 
 ## Making Follow-up Calls
 

docs/api-testing/use-cases/integration-test.md

@@ -32,7 +32,7 @@ To create an integration test to check the interaction between the endpoints:
 2. (Optionally) Add an assert-is component to verify that `productsPayload` is an array.
 
 :::tip
-You can use the Comment component and print the whole payload response inside your test report by writing ${productsPayload}
+You can use the Comment component and print the whole payload response inside your test report by writing $\{productsPayload}
 :::
 
 3. Add an `each` component and reference the `productsPayload` object.

docs/error-reporting/project-setup/source-code.md

@@ -37,12 +37,12 @@ Use the "Add a Github repository" button to begin configuring a repository.
 
 - Connection Information: Backtrace Source Control can integrate with GIT based systems. You must provide a Name, URL (HTTP or SSH based), and Authentication method (None, User Name / Password, SSH Key).
   - NOTE - You may need to work with your source control system to get the proper URL and credentials to provide access to your SCM.
-- Revisions: GIT systems take snapshots of the source code at different times and manage those as Revisions. You can specify the ordered list of Revisions to try when searching for matching source code. Acceptable revision types include branch names, tags, as well as short and long SHA-1 hashes. You can specify an attribute to be dynamically included in the revision string by using {attribute} template syntax.
+- Revisions: GIT systems take snapshots of the source code at different times and manage those as Revisions. You can specify the ordered list of Revisions to try when searching for matching source code. Acceptable revision types include branch names, tags, as well as short and long SHA-1 hashes. You can specify an attribute to be dynamically included in the revision string by using \{attribute} template syntax.
 
-By default, we'll check the main branch, but we expect you will want to specify more granular branches to be checked first. For example, a common pattern is to have 'release/{application}/{version}' as a standard way to tag releases. Other examples:
+By default, we'll check the main branch, but we expect you will want to specify more granular branches to be checked first. For example, a common pattern is to have 'release/\{application}/\{version}' as a standard way to tag releases. Other examples:
 
-- release/{version}
-- {commit}
+- release/\{version}
+- \{commit}
 - 729e0d9a
 - master
 - main
@@ -58,11 +58,11 @@ Use the "Add a Perforce Depot" button to begin configuring a repository.
 - Connection Information: Backtrace Source Control can integrate with Perforce systems using the p4 command line utility. You must provide a Name, Host and Port, User Name and Password.
 - Source Code Depot Paths: You will need to specify a list of depot paths to try, in order, when searching for matching source code.
 
-You can specify an attribute to be dynamically included in the path by using {attribute} template syntax.
-For example, you might choose to first search "//depot/releases/{version}/" followed by "//depot/develop/". If the version attribute is set to '1.15' on the error that you are inspecting, then it will be used to create a search path of "//depot/releases/1.15/".
+You can specify an attribute to be dynamically included in the path by using \{attribute} template syntax.
+For example, you might choose to first search "//depot/releases/\{version}/" followed by "//depot/develop/". If the version attribute is set to '1.15' on the error that you are inspecting, then it will be used to create a search path of "//depot/releases/1.15/".
 Some examples:
 
-- //depot/project/release/{version}
+- //depot/project/release/\{version}
 - //depot/project/main/
 - //depot/project/develop/
 

docs/error-reporting/web-console/releases.md

@@ -24,7 +24,7 @@ You can see the user adoption of the versions, the error-free application launch
 
 ### Set the Version Attribute
 
-You will want to ensure the Release Comparison View's concept of a "Release" is represented by the attribute most relevant to you. Use the pencil icon next to the "Comparing by {attribute}" text at the top of the view to set this as desired.
+You will want to ensure the Release Comparison View's concept of a "Release" is represented by the attribute most relevant to you. Use the pencil icon next to the "Comparing by \{attribute}" text at the top of the view to set this as desired.
 
 <img src={useBaseUrl('img/error-reporting/console-views/edit-version-attribute.png')} alt="Shows how to set the version attribute for the Releases view." />
 

docs/error-reporting/whats-new.md

@@ -101,7 +101,7 @@ Tunable heuristic-based analysis spots new API signatures or changes further up
 
 ## Case Insensitive Filtering (2020-08-24)
 
-By default, all filter operators are case sensitive. If you want to filter using case insensitivity, enter a regex or inverse regex within /{text}/i to invoke case insensitive search.
+By default, all filter operators are case sensitive. If you want to filter using case insensitivity, enter a regex or inverse regex within /\{text}/i to invoke case insensitive search.
 For example, if you want to search for "banana" or "Banana" or "BaNaNa", you can enter "/banana/i" and each search term will be included in the results.
 
 ## Aggregation Filters (2020-07-28)