docs: Convert rest of api links + added links where commands were referenced.

docs/source/api/welcome/api.md

@@ -1,7 +1,7 @@
 ---
 title: API
 comments: true
- 
+
 ---
 
 {% note info New to Cypress? %}
@@ -10,11 +10,11 @@ Read through our [Guides](https://on.cypress.io/guides/guides) first.
 
 # Sections
 
-- **[Commands:](https://on.cypress.io/api/and)** Drive your tests in the browser like a real user would. They let you perform actions like typing, clicking, xhr requests, and can also assert things like "my button should be disabled".
+- **{% url 'Commands:' and %}** Drive your tests in the browser like a real user would. They let you perform actions like typing, clicking, xhr requests, and can also assert things like "my button should be disabled".
 
-- **[Utilities:](https://on.cypress.io/api/_)** Access methods from other commonly used libraries.
+- **{% url 'Utilities:' _ %}** Access methods from other commonly used libraries.
 
-- **[Cypress API:](https://on.cypress.io/api/commands)** Configure the behavior of how Cypress works internally. You can do things like access Environment Variables, change configuration, create custom commands, and more.
+- **{% url 'Cypress API:' cypress-commands %}** Configure the behavior of how Cypress works internally. You can do things like access Environment Variables, change configuration, create custom commands, and more.
 
 # Organization
 

docs/source/faq/index.md

@@ -68,7 +68,7 @@ The desktop application can be installed in OSX and Linux. [Windows is not yet s
 
 Cypress would never be able to run on a native mobile app, but would be able to run in a web view. In that mode, you'd see the commands display in a browser while you would drive the mobile device separately. Down the road we'll likely have first class support for this, but today it is not a current priority.
 
-Currently you can control the [`.viewport()`](https://on.cypress.io/api/viewport) to test responsive, mobile views in a website or web application.
+Currently you can control the {% url `cy.viewport()` viewport %} to test responsive, mobile views in a website or web application.
 
 ## {% fa fa-question-circle green %} Do you support X language or X framework?
 
@@ -126,7 +126,7 @@ There is nothing currently built into Cypress to do this. Adding code coverage a
 
 No. In fact Cypress' architecture is very different from Selenium in a few critical ways:
 
-- Cypress runs in the context of the browser. With Cypress it's much easier to accurately test the browser, but harder to talk to the outside work. In Selenium it's the exact opposite. Although Cypress has a few commands that give you access to the outside world - like [.request()](http://on.cypress.io/api/request) and [.exec()](https://on.cypress.io/api/exec).
+- Cypress runs in the context of the browser. With Cypress it's much easier to accurately test the browser, but harder to talk to the outside work. In Selenium it's the exact opposite. Although Cypress has a few commands that give you access to the outside world - like {% url `cy.request()` request %} and {% url `cy.exec()` exec %}.
 
 ## {% fa fa-question-circle green %} Are there driver bindings in my language?
 
@@ -234,7 +234,7 @@ cy.get('#list>li').should('have.length', 20)
 
 ## {% fa fa-question-circle green %} How do I seed / reset my database?
 
-You can use either {% url `cy.request()` request %} or [`cy.exec`](https://on.cypress.io/api/exec) to talk to your backend to seed data.
+You can use either {% url `cy.request()` request %} or {% url `cy.exec()` exec %} to talk to your backend to seed data.
 
 You could also just stub XHR requests directly using {% url `cy.route()` route %} which avoids ever even needing to fuss with your database.
 

docs/source/guides-old/guides/finding-elements.md

@@ -32,7 +32,7 @@ You'll notice many of these commands match the same behavior as their [jQuery co
 
 ## Starting a Query
 
-In Cypress, you will almost always start a sequence of traversal commands with [`cy.get`](https://on.cypress.io/api/get). You can think of [`cy.get`](https://on.cypress.io/api/get) as the same as jQuery's `$` for getting DOM elements.
+In Cypress, you will almost always start a sequence of traversal commands with {% url `cy.get()` get %}. You can think of {% url `cy.get()` get %} as the same as jQuery's `$` for getting DOM elements.
 
 **The following examples are equivalent:**
 
@@ -103,7 +103,7 @@ cy.get("form").find("inpit").type("foo").parent(".row")
     // oops we have a typo here in our selector
 ```
 
-Cypress will continue to retry finding the `inpit` element for **4 seconds** and then time out since this element does not exist. The [`cy.type`](https://on.cypress.io/api/type) and [`cy.parent`](https://on.cypress.io/api/parent) commands are never issued because Cypress will give up after failing to find the `inpit` element.
+Cypress will continue to retry finding the `inpit` element for **4 seconds** and then time out since this element does not exist. The {% url `.type()` type %} and {% url `.parent()` parent %} commands are never issued because Cypress will give up after failing to find the `inpit` element.
 
 Another way to look at it is to imagine there being an implied `.should("exist")` after every DOM command.
 
@@ -281,4 +281,4 @@ cy.get("#loading").should("not.exist")
 ```javascript
 // retry until our radio is checked
 cy.get(":radio").should("be.checked")
-```
+```

docs/source/guides/advanced-cypress/web-security.md

@@ -153,7 +153,7 @@ cy.visit("http://localhost:8080")
 cy.get("a").should("have.attr", "href", "https://google.com") // no page load!
 ```
 
-Okay but let's say you're worried about `google.com` serving up the right HTML content. How would you test that? Easy! Just make a [`cy.request`](https://on.cypress.io/api/request) directly to it. [`cy.request`](https://on.cypress.io/api/request) is **NOT bound to CORS or same-origin policy**.
+Okay but let's say you're worried about `google.com` serving up the right HTML content. How would you test that? Easy! Just make a {% url `cy.request()` request %} directly to it. {% url `cy.request()` request %} is **NOT bound to CORS or same-origin policy**.
 
 ```javascript
 cy.visit("http://localhost:8080")
@@ -202,7 +202,7 @@ app.post("/submit", function(req, res) {
 
 A commone use case for this is `Single sign-on (SSO)`. In that situation you may `POST` to a different server and are redirected elsewhere (typically with the session token in the URL).
 
-If that's the case, don't worry - you can work around it with [`cy.request`](https://on.cypress.io/api/request). [`cy.request`](https://on.cypress.io/api/request) is special because it is **NOT bound to CORS or same-origin policy**.
+If that's the case, don't worry - you can work around it with {% url `cy.request()` request %}. {% url `cy.request()` request %} is special because it is **NOT bound to CORS or same-origin policy**.
 
 In fact we can likely bypass the initial visit altogether and just `POST` directly to your `SSO` server.
 
@@ -260,4 +260,4 @@ Still here? That's cool, let's disable web security!
 
 The browser will now display insecure content, you can now navigate to any superdomain without cross origin errors, and you can access cross origin iframes that are embedded in your application.
 
-One thing you may notice though is that Cypress still enforces visiting a single superdomain with [`cy.visit`](https://on.cypress.io/api/visit). This is an artificial limitation (and one that can be removed). You should [open an issue](https://github.com/cypress-io/cypress/issues/new) and tell us what you're trying to do!
+One thing you may notice though is that Cypress still enforces visiting a single superdomain with {% url `cy.visit()` visit %}. This is an artificial limitation (and one that can be removed). You should [open an issue](https://github.com/cypress-io/cypress/issues/new) and tell us what you're trying to do!

docs/source/guides/appendices/_changelog_older.md

@@ -10,7 +10,7 @@
 
 - Update links to match new [documentation hub](https://docs.cypress.io)
 - {% url `.debug()` debug %} has been zipped up - it no longer logs confusing debugging information and now logs information about the previously run command.
-- [`_`](https://on.cypress.io/api/cypress-underscore), [`$`](https://on.cypress.io/api/cypress-jquery), [`Promise`](https://on.cypress.io/api/cypress-promise), [`Blob`](https://on.cypress.io/api/cypress-blob), [`moment`](https://on.cypress.io/api/cypress-moment) utilities have been moved off of `cy` and are now attached to `Cypress`. This is much more consistent with how the `cy` and `Cypress` API's work. You can continue to use these objects off of `cy` but this has been deprecated and you will see a warning message.
+- {% url `Cypress._` _ %}, {% url `Cypress.$` $ %}, {% url `Cypress.Promise` promise %}, {% url `Cypress.Blob` blob %}, {% url `Cypress.moment` moment %} utilities have been moved off of `cy` and are now attached to `Cypress`. This is much more consistent with how the `cy` and `Cypress` API's work. You can continue to use these objects off of `cy` but this has been deprecated and you will see a warning message.
 
 # 0.13.8
 
@@ -101,7 +101,7 @@
 - Overhauled the entire subsystem dealing with an element's visibility state. Previously we were simply using jQuery's `.is(":visible")` selector which was ineffective at truly determining when an element is "visible". Our changes now differ significantly from jQuery, but they match what a real user would consider visible, and the rules are fairly easy to explain. In other words these rules should just "make sense".
 - An element is considered visible if it can be "interactive" with a user. In other words, if the user is able to click, type, drag, or otherwise physically interact with the element it is considered visible.
 - Because of the additional complexities of how Cypress considers an element `visible`, we now have added the **exact** reason why an element is not visible when throwing an error. This means you'll see errors detailing whether an element or its parents have `display: none`, `visibility: hidden`, or whether an element is considered hidden because its effective `width` or `height` is zero. Whatever the reason, Cypress will indicate why your element is considered hidden.
-- Exposed [`Cypress.Dom.isHidden`](https://on.cypress.io/api/dom) which holds the logic for determining an element's visibility. Modify this to change the rules.
+- Exposed {% url `Cypress.Dom.isHidden` dom %} which holds the logic for determining an element's visibility. Modify this to change the rules.
 - Upgraded {% url `.select()` select %} to automatically retry when the `<select>` is disabled, its matching `<option>` is disabled, or when Cypress cannot find a matching `<option>`. This more correctly aligns with the behavior of other actions like {% url `.click()` click %}, which automatically retry until the element is ready to receive the action.
 
 **Bugfixes:**
@@ -116,7 +116,7 @@
 - The updated hidden rules apply to all assertions like `should("be.hidden")`, and how Cypress indicates an element is hidden displays in the Command Log.
 - Updated many error messages to be more explanatory and precise.
 - Elements which are stringified during errors now indicate their text content (truncated to 10 characters) `<button>Save</button>` or whether they contain children elements by indicating an ellipsis `<div>...</div>`.
-- The [`Routes` instrument panel](https://on.cypress.io/api/routes) now displays the column: `Stubbed` instead of `Status`, which indicates whether a route is stubbing matching XHR's.
+- The {% url 'Routes instrument panel' route %} now displays the column: `Stubbed` instead of `Status`, which indicates whether a route is stubbing matching XHR's.
 
 # 0.13.2
 
@@ -220,7 +220,7 @@
 
 - There are now [Getting Started](https://on.cypress.io/guides/installing-and-running) docs including [configuration options](https://on.cypress.io/guides/configuration) for `cypress.json`
 - Cypress now silently restarts the server whenever it detects a change to `cypress.json` - meaning you no longer have to manually reboot the server for changes to be picked up.
-- There is a new [`Cypress.config`](https://on.cypress.io/api/config) interface - akin to [`Cypress.env`](https://on.cypress.io/api/env) which provides access to configuration values.
+- There is a new {% url `Cypress.config` config %} interface - akin to {% url `Cypress.env` env %} which provides access to configuration values.
 
 **Bugfixes:**
 
@@ -258,7 +258,7 @@
 
 **Features:**
 
-- There is a new [`Cypress.Cookies`](https://on.cypress.io/api/cookies) interface which enables you to `get`, `set`, and even `preserve` cookies throughout your test. Useful to preserve cookie-based sessions between your tests. [Documentation is written here](https://on.cypress.io/api/cookies).
+- There is a new {% url `Cypress.Cookies` cookies %} interface which enables you to `get`, `set`, and even `preserve` cookies throughout your test. Useful to preserve cookie-based sessions between your tests. {% url 'Documentation is written here' cookies %}.
 
 **Bugfixes:**
 
@@ -289,7 +289,7 @@
 **Features:**
 
 - There is now a `cy.cmd` and `cy.command` method which enables you to invoke commands by their string name. This is most useful when using *namespaced* custom commands. So `Cypress.addParentCommand("dashboard.setSlider", ...)` can be accessed by `cy.cmd("dashboard.setSlider", arg1, arg2)`. (Docs have not been written yet).
-- `Environment Variable` support has been added and can be accessed in your tests with [`Cypress.env`](https://on.cypress.io/api/env). The docs have been written [here](https://on.cypress.io/guides/environment-variables) and [here](https://on.cypress.io/api/env).
+- `Environment Variable` support has been added and can be accessed in your tests with {% url `Cypress.env` env %}. The docs have been written [here](https://on.cypress.io/guides/environment-variables) and {% url 'here' env %}.
 
 **Misc:**
 
@@ -301,7 +301,7 @@
 
 **Bugfixes:**
 
-- {% url `cy.route()` route %} will no longer throw that a response is needed when using [`cy.server({stub: false})`](https://on.cypress.io/api/server).
+- {% url `cy.route()` route %} will no longer throw that a response is needed when using {% url '`cy.server({stub: false})`' server %}.
 - Applying server defaults to `Cypress.Server.defaults({})` now {% url 'works as documented' cypress-server %}.
 - `onRequest` and `onResponse` can now be correctly set as permanent server defaults.
 - XHR `URL` is now decoded to make assertions easier. Fixes [#75](https://github.com/cypress-io/cypress/issues/75).
@@ -339,7 +339,7 @@ Deprecations:
 - You can now force other additional response headers to be sent on stubbed XHRs.
 - XHR's now snapshot twice - when the request is made and when the response is returned.
 - Removed sending `sinon` on every {% url `cy.visit()` visit %}.
-- The XHR object which is returned to you to via [`cy.wait("@xhrAlias")`](https://on.cypress.io/api/wait) is now more consistent with other return values such as {% url `cy.request()` request %}. It should be much easier to work with `request body`, `request headers`, `response body` and `response headers`.
+- The XHR object which is returned to you to via {% url `cy.wait()` wait %} is now more consistent with other return values such as {% url `cy.request()` request %}. It should be much easier to work with `request body`, `request headers`, `response body` and `response headers`.
 
 **Bugfixes:**
 
@@ -477,7 +477,7 @@ Almost there:
 **Bugfixes:**
 
 - Viewport is now properly restored to the default width / height after on subsequent runs. Previously it would retain the last viewport sized sed until there was a new viewport command.
-- [`cy.should('contain', '...')`](https://on.cypress.io/api/should) now correctly escapes quotes and single quotes.
+- {% url '`cy.should('contain', '...')`' should %} now correctly escapes quotes and single quotes.
 - Assertion messages are no longer truncated, and instead will scale down by reducing the `font-size` and `line-height` after they exceed 110 characters. So you'll now always see the full assertion message.
 - Fixed some scenarios where assertions would not be logged as a child command.
 - Assertions based around the `window` or `document` object no longer cause `chai` to bomb on formatting their object structures (due to yclic references) and instead now will show up as `<window>` and `<document>`.
@@ -494,7 +494,7 @@ Almost there:
 
 **Features:**
 
-- The `Linux` version of Cypress now works correctly for GUI Desktop versions (tested on Ubuntu Desktop). Previously it would only work eadlessly in server versions. The `tray` used in OSX does not work with the `Linux`, so in `Linux` we just use a standard window + menu.
+- The `Linux` version of Cypress now works correctly for GUI Desktop versions (tested on Ubuntu Desktop). Previously it would only work headlessly in server versions. The `tray` used in OSX does not work with the `Linux`, so in `Linux` we just use a standard window + menu.
 - Added Desktop Icon.
 
 **Bugfixes:**
@@ -573,11 +573,11 @@ Deprecations:
 
 **Features:**
 
-- Commands which precede assertions will now look downstream at those assertions and not resolve until their subject's state passes all ssertions. Previously this was **sort of** implemented using *Command Options* and the `eventually` flag, but now this is the default ehavior. *Command Options* only worked on DOM-based subjects, and now the new assertion verification works on everything else (including RL-based commands, etc). What this means is that Cypress can predict what you are requesting and automatically modifies its behavior until his state is reached. This prevents test brittleness / random test flake. Additionally this removes ever having to use [`cy.wait(Number)`](https://on.cypress.io/api/wait) or `cy.wait(Function)` (though this is still a valid command). As a side effect, you will now see commands + heir assertions in the spinning pending blue state. When assertions fail their associated command also fails at the same time. This visually epresents the coupling between these two concepts. Another side effect is that `timeout` options do not need to be provided on the succeeding ssertions, and can instead just be provided on the proceeding command. All of the coupled assertions will automatically be retried to the aximum `timeout` setting. Fixes [#43](https://github.com/cypress-io/cypress/issues/43).
-- Action commands will now insert an artificial delay after resolving to enable modern JavaScript frameworks time to *flush* their run loops. napshots are delayed until after the action, resulting in more accurate snapshots because JavaScript frameworks would not process these DOM vents until `N` milliseconds after they occurred. This has the unfortunate side effect of *decreasing* performance by about *5-10%* but the nd result is that it is much easier to debug and Cypress is less prone to flake caused by modern JavaScript frameworks. This change comes fter collecting many data points and this was one of the easiest changes that help reduce flake. For users that don't use the latest and reatest JavaScript frameworks, this action delay can be reduced through `cypress.json` which may speed up large test suites.
+- Commands which precede assertions will now look downstream at those assertions and not resolve until their subject's state passes all ssertions. Previously this was **sort of** implemented using *Command Options* and the `eventually` flag, but now this is the default ehavior. *Command Options* only worked on DOM-based subjects, and now the new assertion verification works on everything else (including RL-based commands, etc). What this means is that Cypress can predict what you are requesting and automatically modifies its behavior until his state is reached. This prevents test brittleness / random test flake. Additionally this removes ever having to use {% url `cy.wait(Number)` wait %} or `cy.wait(Function)` (though this is still a valid command). As a side effect, you will now see commands + heir assertions in the spinning pending blue state. When assertions fail their associated command also fails at the same time. This visually represents the coupling between these two concepts. Another side effect is that `timeout` options do not need to be provided on the succeeding assertions, and can instead just be provided on the proceeding command. All of the coupled assertions will automatically be retried to the maximum `timeout` setting. Fixes [#43](https://github.com/cypress-io/cypress/issues/43).
+- Action commands will now insert an artificial delay after resolving to enable modern JavaScript frameworks time to *flush* their run loops. snapshots are delayed until after the action, resulting in more accurate snapshots because JavaScript frameworks would not process these DOM vents until `N` milliseconds after they occurred. This has the unfortunate side effect of *decreasing* performance by about *5-10%* but the and result is that it is much easier to debug and Cypress is less prone to flake caused by modern JavaScript frameworks. This change comes after collecting many data points and this was one of the easiest changes that help reduce flake. For users that don't use the latest and greatest JavaScript frameworks, this action delay can be reduced through `cypress.json` which may speed up large test suites.
 - Aliasing custom commands now intelligently figures out where to apply the alias without being specified inside of the actual custom command.
-- The algorithm for replaying aliased commands is now much more accurate, handles stale element references better, and will not replay ommands which have a side effect (like action commands). The end result is Cypress will now almost always find the desired element by etermining the minimum number of re-queries and is not susceptible to stale element references. Additionally using assertions on aliased lements now works (where previously using a *Command Option* on an alias would just be ignored. This was crazy difficult to implement but hould be 100% solid. Fixes [#36](https://github.com/cypress-io/cypress/issues/36).
-- Assertions which actually produced 2 assertions (under the hood) such as `should('have.attr', 'href', '/users/1')` will now only log the 2nd ssertion, unless the first fails.
+- The algorithm for replaying aliased commands is now much more accurate, handles stale element references better, and will not replay commands which have a side effect (like action commands). The end result is Cypress will now almost always find the desired element by determining the minimum number of re-queries and is not susceptible to stale element references. Additionally using assertions on aliased elements now works (where previously using a *Command Option* on an alias would just be ignored. This was crazy difficult to implement but should be 100% solid. Fixes [#36](https://github.com/cypress-io/cypress/issues/36).
+- Assertions which actually produced 2 assertions (under the hood) such as `should('have.attr', 'href', '/users/1')` will now only log the 2nd assertion, unless the first fails.
 - Previously using `eventually.have.length` was impossible (and this would throw an error), but now this works as you'd expect with the default `should('have.length')`.
 
 **Bugfixes:**
@@ -593,7 +593,7 @@ Deprecations:
 - Cypress overrides chai's default inspection function for DOM elements meaning instead of seeing `{ Object (0, length, ...) }` you will now ee the nicely formatted Cypress DOM element like: `<button#primary.btn-large>`.
 - Cypress now overrides chai's `match` chainer and provides a specific error message when a non `regex` value is provided. Fixes [#58](../ssues/58).
 - Cypress now handles `length` and `exist` assertion chainers in a very specific way, providing a detailed message on failure, and utomatically slices out any stale element references.
-- The `contain` assertion chainer from `chai-jquery` has been extended to match the same selector logic as [`cy.contains()`](https://n.cypress.io/api/contains) - meaning it now checks the `value` of `input[type=submit]`.
+- The `contain` assertion chainer from `chai-jquery` has been extended to match the same selector logic as {% url `cy.contains()` contains %} - meaning it now checks the `value` of `input[type=submit]`.
 - Tweaked the label for displaying the number of elements a command resolved with (now displays 0 differently than > 1).
 - Removed the `eventually` flag in assertions as now this is the default behavior on normal assertions.
 - Deprecated all *Command Options*. You will see a very nice and simple error message explaining how to convert these to assertions.
@@ -756,7 +756,7 @@ Deprecations:
 
 **Features:**
 
-- {% url `.click()` click %}, {% url `.type()` type %}, {% url `.clear()` clear %}, [`.select()`](https://on.cypress.io/api/select), {% url `.check()` check %}, [`.uncheck()`](https://on.cypress.io/api/ncheck) now will wait for the subject to automatically become visible instead of throwing immediately if the element is not in a visible state.
+- {% url `.click()` click %}, {% url `.type()` type %}, {% url `.clear()` clear %}, {% url `.select()` select %}, {% url `.check()` check %}, {% url `.uncheck()` uncheck %} now will wait for the subject to automatically become visible instead of throwing immediately if the element is not in a visible state.
 
 **Misc:**
 
@@ -776,7 +776,7 @@ Deprecations:
 
 **Misc:**
 
-- {% url `cy.contains()` contains %} now throws when provided the command option: `length` because it will only ever return 1` element.
+- {% url `cy.contains()` contains %} now throws when provided the command option: `length` because it will only ever return 1 element.
 
 # 0.9.3
 
@@ -789,7 +789,7 @@ Deprecations:
 - The `url` will now automatically be restored when hovering over the Command Log to indicate the state of the URL at the time the command ran.
 - {% url `.click()` click %} now accepts an optional: `position` argument (`center`, `topLeft`, `topRight`, `bottomLeft`, `bottomRight`). Center is still the default.
 - {% url `.click()` click %} now accepts an optional `x` and `y` coordinate argument, which is relative to the top left corner of the element. Fixes [#50](https://github.com/cypress-io/cypress/issues/50).
-- [Click docs have been updated](https://on.cypress.io/api/click) to reflect these changes.
+- {% url 'Click docs have been updated' click %} to reflect these changes.
 
 **Bugfixes:**
 
@@ -842,7 +842,7 @@ Deprecations:
 
 **Summary:**
 
-- {% url `cy.viewport()` viewport %} is a new command which will resize the viewport to a specified width and height. There is ow a default `viewport` size of `1000x660`. See [viewport docs](https://on.cypress.io/api/viewport).
+- {% url `cy.viewport()` viewport %} is a new command which will resize the viewport to a specified width and height. There is ow a default `viewport` size of `1000x660`.
 
 **Features:**
 
@@ -932,7 +932,7 @@ Deprecations:
 
 **Misc:**
 
-- Attempting to {% url `.click()` click %} a select element will now throw an error. The error guides you to using the `.select()`](https://on.cypress.io/api/select) command, as that is the command you should use to change a `<select>` value.
+- Attempting to {% url `.click()` click %} a select element will now throw an error. The error guides you to using the {% url `.select()` select %} command, as that is the command you should use to change a `<select>` value.
 - {% url `cy.route()` route %} responses are now validated. If responses are `null` or `undefined` Cypress will throw a very specific error message.
 - Cypress will now display `cypress.json` parse errors when attempting to boot a project when there is a syntax error in `cypress.json`.
 
@@ -1043,7 +1043,7 @@ Deprecations:
 
 **Misc:**
 
-- {% url `.type()` type %}, {% url `.clear()` clear %}, {% url `.check()` check %}, `.uncheck()`](https://on.cypress.io/api/uncheck) now all take `{force: true}` options to force the click to happen and skip additional clickable checks.
+- {% url `.type()` type %}, {% url `.clear()` clear %}, {% url `.check()` check %}, {% url `.uncheck()` uncheck %} now all take `{force: true}` options to force the click to happen and skip additional clickable checks.
 - Now when you click the giant yellow failure messages if the error is a `CypressError` instead of logging nothing it will now find the command associated to that error and display the same message as if you clicked the failed command.
 
 # 0.6.11
@@ -1142,7 +1142,7 @@ Deprecations:
 **Features:**
 
 - When Cypress detects a regular HTTP page loading event (where we're leaving the current page and requesting a new one) it will now insert a `loading` command which indicates to the user Cypress has stopped running commands until the new page loads.
-- If for some reason this new page errors Cypress will display the initial 500 error messages just like [`cy.visit()`](https://on.cypress.io/api/cisit).
+- If for some reason this new page errors Cypress will display the initial 500 error messages just like {% url `cy.visit()` visit %}.
 - Cypress now waits `20s` (which matches {% url `cy.visit()` visit %}) for the new page to load instead of `4s` previously.
 
 **Bugfixes:**
@@ -1311,7 +1311,7 @@ Deprecations:
 
 - {% url `cy.server()` server %} now accepts a `delay` option which will delay all responses to requests (including 404) based on the value in ms
 - {% url `cy.server()` server %} now accepts a `respond` option which can turn off automatic responding to requests.
-- {% url `cy.route()` route %} now accepts a `delay` option which overrides the delay option set in [`cy.server()`](https://n.cypress.io/api/server) to just matched requests.
+- {% url `cy.route()` route %} now accepts a `delay` option which overrides the delay option set in {% url `cy.server()` server %} to just matched requests.
 - {% url `cy.route()` route %} now accepts a `respond` option which will turn off automatic responding to just matched requests.
 - Fixes [#14](https://github.com/cypress-io/cypress/issues/14).
 - {% url `cy.wait()` wait %} now accepts an alias property called `request`. Example: `cy.wait('@getUsers.request')` which ill resolve once the XHR is initially requested, before it is responded to.  This allows you to test things when a request is in flight.

docs/source/guides/appendices/available-assertions.md

@@ -114,7 +114,7 @@ Cypress bundles the popular [Chai](#Chai) assertion library, as well as helpful
 | contain( *text* ) | `expect($('#content')).to.contain('text')` |
 | descendents( *selector* ) | `expect($('#content')).to.have.descendants('div')` |
 
-You will commonly use these chainers after using DOM commands like: [`cy.get`](https://on.cypress.io/api/get), [`cy.contains`](https://on.cypress.io/api/contains), etc.
+You will commonly use these chainers after using DOM commands like: {% url `cy.get()` get %}, {% url `cy.contains()` contains %}, etc.
 
 # Chai-Sinon
 

docs/source/guides/appendices/bundled-tools.md

@@ -29,7 +29,7 @@ Additionally, Mocha gives us excellent [`async` support](https://mochajs.org/#as
 
 [Chai docs](http://chaijs.com/)
 
-While Mocha provides us a framework to structure our tests, Chai gives us the ability to easily write assertions. Chai gives us readable assertions with excellent error messages. Cypress extends this, fixes several common pitfalls, and wraps Chai's DSL using [subjects](https://on.cypress.io/guides/making-assertions) and the [cy.should](https://on.cypress.io/api/should) command.
+While Mocha provides us a framework to structure our tests, Chai gives us the ability to easily write assertions. Chai gives us readable assertions with excellent error messages. Cypress extends this, fixes several common pitfalls, and wraps Chai's DSL using [subjects](https://on.cypress.io/guides/making-assertions) and the {% url `.should()` should %} command.
 
 {% note info Extending chai to use assertion plugins %}
 [Check out our example recipe to see how to extend chai yourself](https://github.com/cypress-io/cypress-example-recipes/blob/master/cypress/integration/extending_chai_assertion_plugins_spec.js)
@@ -45,7 +45,7 @@ When writing integration tests, you will likely work a lot with the DOM. Cypress
 
 [Sinon docs](http://sinonjs.org/)
 
-When writing unit tests, or even in integration-like tests, you often need to ability to [stub](http://sinonjs.org/docs/#stubs) and [spy](http://sinonjs.org/docs/#spies) methods. Cypress includes two methods, [`cy.stub`](https://on.cypress.io/api/stub) and [`cy.spy`](https://on.cypress.io/api/spy) that return Sinon stubs and spies, respectively.
+When writing unit tests, or even in integration-like tests, you often need to ability to [stub](http://sinonjs.org/docs/#stubs) and [spy](http://sinonjs.org/docs/#spies) methods. Cypress includes two methods, {% url `cy.stub()` stub %} and {% url `cy.spy()` spy %} that return Sinon stubs and spies, respectively.
 
 {% note info Stubbing Dependencies when Unit Testing %}
 [Check out our example recipe for stubbing dependencies in unit tests](https://github.com/cypress-io/cypress-example-recipes/blob/master/cypress/integration/unit_test_stubbing_dependencies_spec.js)
@@ -67,9 +67,9 @@ Sinon-as-Promised gives you the ability to stub methods that return Promises. To
 
 Cypress also bundles the following tools on the `Cypress` object. These can be used anywhere inside of your tests.
 
-- [Cypress._](https://on.cypress.io/api/cypress-underscore) (Underscore)
-- [Cypress.$](https://on.cypress.io/api/cypress-jquery) (jQuery)
-- [Cypress.minimatch](https://on.cypress.io/api/cypress-minimatch) (minimatch.js)
-- [Cypress.moment](https://on.cypress.io/api/cypress-moment) (moment.js)
-- [Cypress.Blob](https://on.cypress.io/api/cypress-blob) (blob utils)
-- [Cypress.Promise](https://on.cypress.io/api/cypress-promise) (Bluebird)
+- {% url `Cypress._` _ %} (Underscore)
+- {% url `Cypress.$` $ %} (jQuery)
+- {% url `Cypress.minimatch` minimatch %} (minimatch.js)
+- {% url `Cypress.moment` moment %} (moment.js)
+- {% url `Cypress.Blob` blob %} (blob utils)
+- {% url `Cypress.Promise` promise %} (Bluebird)

docs/source/guides/appendices/changelog.md

@@ -43,7 +43,7 @@ comments: false
 - Fixed file watching when changing the `integrationFolder` to something other than the default value. Fixes [#438](https://github.com/cypress-io/cypress/issues/438).
 - {% url `.select()` select %} now works on options that have the same value. Fixes [#441](https://github.com/cypress-io/cypress/issues/441).
 - Cypress no longer crashes when you click links in the on-boarding screen called "To help you get started...". Fixes [#227](https://github.com/cypress-io/cypress/issues/227).
-- The `example_spec.js` file that gets seeded on a new project no longer fails on [`cy.readFile()`](https://on.cypress.io/api/readFile). Fixes [#414](https://github.com/cypress-io/cypress/issues/414).
+- The `example_spec.js` file that gets seeded on a new project no longer fails on {% url `cy.readFile()` readfile %}. Fixes [#414](https://github.com/cypress-io/cypress/issues/414).
 
 **Misc:**
 
@@ -640,8 +640,8 @@ comments: false
 
 **Features:**
 
-- [`Cypress.Cookies.debug()`](https://on.cypress.io/api/cookies#section-debug-usage) now works again. Additionally it provides much more feedback than it used to.
-- [`Cypress.Cookies.debug(true, {verbose: false})`](https://on.cypress.io/api/cookies#section-turn-off-verbose-debugging-output) option has been added to remove verbose cookie object logging.
+- {% url `Cypress.Cookies.debug()` cookies#Debug %} now works again. Additionally it provides much more feedback than it used to.
+- {% url '`Cypress.Cookies.debug(true, {verbose: false})`' cookies#Debug %} option has been added to remove verbose cookie object logging.
 
 **Bugfixes:**
 
@@ -671,12 +671,12 @@ comments: false
 **Breaking Changes:**
 
 - Running tests in Cypress now requires either Chrome, Chromium, or Canary to be installed on your OS environment. We intend to expand support for more browsers in the future, but for now, only these 3 are supported.
-- Removed support for [`Cypress.Cookies.get`](https://on.cypress.io/api/cookies), [`Cypress.Cookies.set`](https://on.cypress.io/api/cookies) and [`Cypress.Cookies.remove`](https://on.cypress.io/api/cookies).
+- Removed support for `Cypress.Cookies.get`, `Cypress.Cookies.set` and `Cypress.Cookies.remove`.
 - Changed return of {% url `cy.getCookies()` getcookies %} to return an array of cookies, each with properties include name, value, etc.
 - Changed return of {% url `cy.clearCookies()` clearcookies %} to return null (previously was returning Cookie that was cleared).
-- [`Cypress.Cookies.debug`](https://on.cypress.io/api/cookies) has been temporarily disabled and will be re-enabled later.
+- {% url `Cypress.Cookies.debug()` cookies#Debug %} has been temporarily disabled and will be re-enabled later.
 - Browsers are spawned in a Cypress specific profile so that we can maintain a clean state apart of your regular browsing usage. You will notice that your extensions are no longer installed. This is on purpose. 3rd party extensions can often get in the way of Cypress and cause failures. However, developer specific extensions for Angular, Ember, and React do not cause any issues but you'll want to reinstall them. You only have to install them once and they will persist.
-- The `whitelist` callback function of [`Cypress.Cookies.defaults`](https://on.cypress.io/api/cookies#section-defaults-usage) now receives a `cookie object` instead of just the `cookies name` as a string.
+- The `whitelist` callback function of {% url `Cypress.Cookies.defaults()` cookies#Defaults %} now receives a `cookie object` instead of just the `cookies name` as a string.
 
 **Features:**
 
@@ -798,7 +798,7 @@ comments: false
 **Bugfixes:**
 
 - When an integration test file is unable to run and the `integrationFolder` is not the default path, the UI error now properly prints the integration test file's path by stripping off `integration` in the path. Fixes [#117](https://github.com/cypress-io/cypress/issues/117).
-- [Cypress.Dom.isHidden()](https://on.cypress.io/api/dom#section-is-hidden-usage) will now throw error when it isn't passed a DOM element.
+- {% url `Cypress.Dom.isHidden()` dom#Is-Hidden %} will now throw error when it isn't passed a DOM element.
 
 **Misc:**
 
@@ -928,7 +928,7 @@ More Info:
 - Added fs polling support to fix issues where Cypress would not detect file changes.
 - Tests should reload inside of Cypress faster when they are changed.
 - Better error messages when a command times out waiting for a promise to resolve. Fixes [#108](https://github.com/cypress-io/cypress/issues/108).
-- [`cy.viewport('ipad-2')`](https://on.cypress.io/api/viewport) now displays by default in portrait. Landscape orientation is now properly landscape. Fixes [#100](https://github.com/cypress-io/cypress/issues/100).
+- {% url `cy.viewport('ipad-2')` viewport %} now displays by default in portrait. Landscape orientation is now properly landscape. Fixes [#100](https://github.com/cypress-io/cypress/issues/100).
 - {% url `.click()` click %} will now properly click within an element's bounding box when a `position` option is passed and the calculated coordinates are a fraction. This previously forced the click to happen outside of the element. Fixes [#99](https://github.com/cypress-io/cypress/issues/99).
 - `clientX` and `clientY` event properties are now correctly calculated for elements when the page is scrolled. Fixes [#98](https://github.com/cypress-io/cypress/issues/98).
 - {% url `.check()` check %} and {% url `.uncheck()` uncheck %} now correctly filter down the subject when a value is passed as an option. Fixes [#94](https://github.com/cypress-io/cypress/issues/94).

docs/source/guides/appendices/configuration.md

@@ -36,7 +36,7 @@ Option | Default | Description
 `execTimeout` | `60000` | Time, in milliseconds, to wait for a system command to finish executing during a {% url `cy.exec()` exec %} command
 `pageLoadTimeout` | `60000` | Time, in milliseconds, to wait until {% url `cy.visit()` visit %}, {% url `cy.go()` go %}, {% url `cy.reload()` reload %} commands or a page load times out
 `requestTimeout` | `5000` | Time, in milliseconds, to wait for an XHR request to go out in a {% url `cy.wait()` wait %} command
-`responseTimeout` | `30000` | Time, in milliseconds, to wait until a response in a {% url `cy.request()` request %}, {% url `cy.wait()` wait %}, {% url `cy.fixture()` fixture %}, {% url `cy.getCookie()` getcookie %}, {% url `cy.getCookies()` getcookies %}, {% url `cy.setCookie()` setcookie %}, {% url `cy.clearCookie()` clearcookie %}, [`cy.clearCookies`()](https://on.cypress.io/api/clearcookies), and {% url `cy.screenshot()` screenshot %} commands
+`responseTimeout` | `30000` | Time, in milliseconds, to wait until a response in a {% url `cy.request()` request %}, {% url `cy.wait()` wait %}, {% url `cy.fixture()` fixture %}, {% url `cy.getCookie()` getcookie %}, {% url `cy.getCookies()` getcookies %}, {% url `cy.setCookie()` setcookie %}, {% url `cy.clearCookie()` clearcookie %}, {% url `cy.clearCookies()` clearcookies %}, and {% url `cy.screenshot()` screenshot %} commands
 
 ## Folders
 
@@ -136,7 +136,7 @@ You can [read more about Environment Variables](https://on.cypress.io/environmen
 
 ## `Cypress.config()`
 
-You can also override configuration values within your test using [`Cypress.config()`](https://on.cypress.io/api/config).
+You can also override configuration values within your test using {% url `Cypress.config()` config %}.
 Any value you change will be permanently changed for the remainder of your tests.
 
 ```javascript

docs/source/guides/appendices/known-issues.md

@@ -12,7 +12,7 @@ Some commands have not been implemented in Cypress. Some commands will be implem
 
 **Workaround**
 
-Oftentimes you can use [`cy.invoke`](https://on.cypress.io/api/invoke) or [`cy.wrap`](https://on.cypress.io/api/wrap) to trigger the event or execute the action in the DOM.
+Oftentimes you can use {% url `.invoke()` invoke %} or {% url `cy.wrap()` wrap %} to trigger the event or execute the action in the DOM.
 
 **Example of right clicking on an element using jQuery**
 ```javascript
@@ -41,7 +41,7 @@ Sometimes an element has specific logic on hover. Maybe the element doesn't even
 
 **Workaround**
 
-Oftentimes you can use [`cy.invoke`](https://on.cypress.io/api/invoke) or [`cy.wrap`](https://on.cypress.io/api/wrap) to show the element before you perform the action.
+Oftentimes you can use {% url `.invoke()` invoke %} or {% url `cy.wrap()` wrap %} to show the element before you perform the action.
 
 **Example of showing an element in order to perform action**
 ```javascript

docs/source/guides/core-concepts/aliases-variables-in-an-async-world.md

@@ -56,7 +56,7 @@ Of course, this is *not good*. It's clunky and difficult to figure out what is g
 **Aliasing is incredibly powerful but very simple to use:**
 
 * Create an alias with the {% url `.as()` as %} command.
-* Reference an alias with the [`cy.get`](https://on.cypress.io/api/get) or [`cy.wait`](https://on.cypress.io/api/wait) command.
+* Reference an alias with the {% url `cy.get()` get %} or {% url `cy.wait()` wait %} command.
 
 Every time you reference an alias, it should be prefixed with `@`. You can think of this character as "a" for alias or you can think of an alias as a pointer (like how variables point to memory).
 
@@ -69,7 +69,7 @@ One use case for aliasing is referencing a DOM Element:
 cy.get("table").find("tr").as("rows")
 ```
 
-Internally, Cypress has made a reference to the `<tr>` collection returned as the alias "rows". To reference these same "rows" later, you can use the [`cy.get`](https://on.cypress.io/api/get) command.
+Internally, Cypress has made a reference to the `<tr>` collection returned as the alias "rows". To reference these same "rows" later, you can use the {% url `cy.get()` get %} command.
 
 ```javascript
 // Cypress returns the reference to the <tr>'s
@@ -78,13 +78,13 @@ Internally, Cypress has made a reference to the `<tr>` collection returned as th
 cy.get("@rows").first().click()
 ```
 
-Because we've used the `@` character in [`cy.get`](https://on.cypress.io/api/get), instead of querying the DOM for elements, [`cy.get`](https://on.cypress.io/api/get) looks for an existing alias called `rows` and returns the reference (if it finds it).
+Because we've used the `@` character in {% url `cy.get()` get %}, instead of querying the DOM for elements, {% url `cy.get()` get %} looks for an existing alias called `rows` and returns the reference (if it finds it).
 
 ## When alias references no longer exist in the DOM
 
 Cypress automatically decides when it should reference existing elements or re-query for new elements.
 
-In many single-page JavaScript applications, the DOM re-renders parts of the application constantly. If you alias DOM elements that have been removed from the DOM by the time you call [`cy.get`](https://on.cypress.io/api/get) with the alias, Cypress automatically re-queries the DOM to find these elements again.
+In many single-page JavaScript applications, the DOM re-renders parts of the application constantly. If you alias DOM elements that have been removed from the DOM by the time you call {% url `cy.get()` get %} with the alias, Cypress automatically re-queries the DOM to find these elements again.
 
 ```html
 <ul id="todos">
@@ -116,12 +116,12 @@ When we reference `@firstTodo`, Cypress checks to see if all of the elements it
 In our case it would re-issue the commands: `cy.get("#todos li").first()`. Everything just works because the new `<li>` is found.
 
 {% note warning  %}
-*Usually*, replaying previous commands will return what you expect, but not always. Cypress' calculations are complicated and we may improve this algorithm at a later time. It is recommended to not alias DOM elements very far down a chain of commands - **alias elements as soon as possible with as few commands as possible**. When in doubt, you can *always* issue a regular `cy.get` to query for the elements again.
+*Usually*, replaying previous commands will return what you expect, but not always. Cypress' calculations are complicated and we may improve this algorithm at a later time. It is recommended to not alias DOM elements very far down a chain of commands - **alias elements as soon as possible with as few commands as possible**. When in doubt, you can *always* issue a regular {% url `cy.get()` get %} to query for the elements again.
 {% endnote %}
 
 # Aliasing Routes
 
-Another use case for aliasing is with routes. Using aliases with [`cy.route`](https://on.cypress.io/api/route) makes dealing with AJAX requests much easier.
+Another use case for aliasing is with routes. Using aliases with {% url `cy.route()` route %} makes dealing with AJAX requests much easier.
 
 ![alias-commands](/img/guides/cypress-basics/aliases-variables-in-an-async-world/aliasing-routes.jpg)
 
@@ -147,7 +147,7 @@ $("form").submit(function(){
 })
 ```
 
-You can tell Cypress to wait until it sees a request that matches your aliased route using the [`cy.wait`](https://on.cypress.io/api/wait) command.
+You can tell Cypress to wait until it sees a request that matches your aliased route using the {% url `cy.wait()` wait %} command.
 
 ```javascript
 cy

docs/source/guides/core-concepts/cypress-in-a-nutshell.md

@@ -146,14 +146,14 @@ Cypress wraps all DOM queries with robust retry-and-timeout logic that better su
 {% endnote %}
 
 {% note info %}
-In Cypress, when you want to interact with a DOM element directly, call `.then()` and pass a function to it that will receive the element. When you need to skip the retry-and-timeout functionality entirely and perform a traditional, synchronous query, you can still use `Cypress.$()`.
+In Cypress, when you want to interact with a DOM element directly, call {% url `.then()` then %} and pass a function to it that will receive the element. When you need to skip the retry-and-timeout functionality entirely and perform a traditional, synchronous query, you can still use {% url `Cypress.$` $ %}.
 
-For more, check out the API docs for [`.then()`](http://on.cypress.io/api/then) and [`Cypress.$()`](http://on.cypress.io/api/utilities/$.html).
+For more, check out the API docs for {% url `.then()` then %} and {% url `Cypress.$` $ %}.
 {% endnote %}
 
 ## Finding Elements by Their Contents
 
-Another way to locate things -- a more human way -- is to look them up by their contents, by what the user sees on the page. For this, there's the handy `cy.contains()`, for example:
+Another way to locate things -- a more human way -- is to look them up by their contents, by what the user sees on the page. For this, there's the handy {% url `cy.contains()` contains %}, for example:
 
 ```js
 // Finds an element in the document containing the text "New Post"
@@ -200,21 +200,20 @@ It's very important to understand the mechanism Cypress uses to chain commands t
 
 ## Interacting With Elements
 
-As we saw in the initial example, Cypress makes it easy to click on and type into elements on the page by adding `.click()` and `.type()` commands to a `cy.get()` or `.contains()` command. This is a great example of chaining in action. Let's see it again:
+As we saw in the initial example, Cypress makes it easy to click on and type into elements on the page by adding {% url `.click()` click %} and {% url `.type()` type %} commands to a {% url `cy.get()` get %} or {% url `cy.contains()` contains %} command. This is a great example of chaining in action. Let's see it again:
 
 ```js
 cy.get('textarea.post-body')
   .type("This is an excellent post.")
 ```
 
-We're chaining the `.type()` onto the `cy.get()`, applying it to the "subject" of the `cy.get()` command, which will be a DOM element if it is found.
+We're chaining the {% url `.type()` type %} onto the {% url `cy.get()` get %}, applying it to the "subject" of the {% url `cy.get()` get %} command, which will be a DOM element if it is found.
 
-`.type()` and `.click()` are just 2 interaction commands Cypress exposes for you, but there are many more! For instance:
-- `.blur()`/`.focus()`
-- `.check()`/`.uncheck()`
-- `.select()`
-- `.hover()`
-- `.dblclick()`
+{% url `.type()` type %} and {% url `.click()` click %} are just 2 interaction commands Cypress exposes for you, but there are many more! For instance:
+- {% url `.blur()` blur %}/{% url `.focus()` focus %}
+- {% url `.check()` check %}/{% url `.uncheck()` uncheck %}
+- {% url `.select()` select %}
+- {% url `.dblclick()` dblclick %}
 
 {% note success Core Concept %}
 Cypress exposes common user interactions as commands, making it simple to encapsulate the behaviors you're looking to create.
@@ -237,13 +236,13 @@ We'll learn more about assertions later in this guide.
 
 ## Subjects
 
-A new Cypress chain always starts with `cy.[something]`, where the `something` establishes what other methods can be called next (chained). Some methods yield no subject and thus cannot be chained, such as `cy.clearCookies()` or `cy.screenshot()`. Some methods, such as `cy.get()` or `cy.contains()`, yield a jQuery-wrapped DOM element as a subject, allowing further methods to be chained onto them like `.click()` or even `.contains()` again.
+A new Cypress chain always starts with `cy.[something]`, where the `something` establishes what other methods can be called next (chained). Some methods yield no subject and thus cannot be chained, such as {% url `cy.clearCookies()` clearcookies %} or {% url `cy.screenshot()` screenshot %}. Some methods, such as {% url `cy.get()` get %} or {% url `cy.contains()` contains %}, yield a jQuery-wrapped DOM element as a subject, allowing further methods to be chained onto them like {% url `.click()` click %} or even {% url `cy.contains()` contains %} again.
 
 {% note info %}
 **Some commands can be chained:**
-- ...only from `cy`, meaning they don't operate on a subject (`cy.clearCookies()`)
-- ...only from commands yielding particular kinds of subjects (`.type()`)
-- ...from `cy` *or* from a subject-yielding chain (`.contains()`)
+- ...only from `cy`, meaning they don't operate on a subject ({% url `cy.clearCookies()` clearcookies %})
+- ...only from commands yielding particular kinds of subjects ({% url `.type()` type %})
+- ...from `cy` *or* from a subject-yielding chain ({% url `cy.contains()` contains %})
 
 
 **Some commands yield:**
@@ -268,11 +267,11 @@ Cypress commands do not return their subjects, they yield them. Remember: Cypres
 
 {% endnote %}
 
-### Using `.then` To Act On A Subject
+### Using {% url `.then()` then %} To Act On A Subject
 
-Want to jump into the command flow and get your hands on the subject directly? No problem, simply add a `.then(function(subject) { })` to your command chain. When the previous command resolves, it will call your custom function with the yielded subject as the first argument.
+Want to jump into the command flow and get your hands on the subject directly? No problem, simply add a {% url '`.then(function(subject) { })`' type %} to your command chain. When the previous command resolves, it will call your custom function with the yielded subject as the first argument.
 
-If you wish to continue chaining commands to your `.then()`, you'll need to specify the subject you want to yield to those commands, which you can achieve by a simple return value. (Cypress will yield that to the next command for you.)
+If you wish to continue chaining commands to your {% url `.then()` then %}, you'll need to specify the subject you want to yield to those commands, which you can achieve by a simple return value. (Cypress will yield that to the next command for you.)
 
 Let's look at an example:
 
@@ -433,7 +432,7 @@ cy.get("form")
 Without a single explicit assertion, there are dozens of ways this test can fail! Here's a few:
 
 - the initial visit url could respond with something other than success
-- any of the `cy.get()` Commands could fail to find their elements
+- any of the {% url `cy.get()` get %} Commands could fail to find their elements
 - form submission could result in a non-success HTTP code
 - the in-page JS (the application under test) could throw an error
 
@@ -456,17 +455,17 @@ Cypress wraps Chai, Chai-jQuery, and Chai-Sinon to provide the built-in assertio
 
 There are two ways to write assertions in Cypress:
 
-1. **Implicit Subjects:** Using [`cy.should`](https://on.cypress.io/api/should) or {% url `.and()` and %}
-2. **Explicit Subjects:** Using `expect`
+1. **Implicit Subjects:** Using {% url `.should()` should %} or {% url `.and()` and %}
+2. **Explicit Subjects:** Using `expect`.
 
 {% note info Assertion Libraries %}
 Cypress bundles [popular assertion libraries](/guides/appendices/available-assertions.html) for you, and exposes synchronous and asynchronous assertion interfaces. In Cypress, you're always a few keystrokes away from an expressive test.
 
 {% endnote %}
 
-## Implicit Subjects with [`cy.should`](https://on.cypress.io/api/should) or {% url `.and()` and %}
+## Implicit Subjects with {% url `.should()` should %} or {% url `.and()` and %}
 
-Using [`cy.should`](https://on.cypress.io/api/should) or {% url `.and()` and %} commands is the preferred way of making assertions in Cypress. These are typical Cypress commands, which means they apply to the current subject in the command chain.
+Using {% url `.should()` should %} or {% url `.and()` and %} commands is the preferred way of making assertions in Cypress. These are typical Cypress commands, which means they apply to the current subject in the command chain.
 
 ```javascript
 // the implicit subject here is the first <tr>
@@ -474,7 +473,7 @@ Using [`cy.should`](https://on.cypress.io/api/should) or {% url `.and()` and %}
 cy.get("tbody tr:first").should("have.class", "active")
 ```
 
-You can chain multiple assertions together using {% url `.and()` and %}, which is just another name for `.should()` that makes things more readable:
+You can chain multiple assertions together using {% url `.and()` and %}, which is just another name for {% url `.should()` should %} that makes things more readable:
 
 ```js
 cy.get("#header a")
@@ -519,7 +518,7 @@ Explicit assertions are great when you want to:
 - perform custom logic prior to making the assertion
 - make multiple assertions against the same subject
 
-The usual caveats apply if you want to do work against the subject: you'll need to do it asynchronously! The `.should()` command allows us to pass a function that will be yielded the subject. This works just like `.then()`, except Cypress will apply its retry-until-timeout magic to the function passed to `.should()`.
+The usual caveats apply if you want to do work against the subject: you'll need to do it asynchronously! The {% url `.should()` should %} command allows us to pass a function that will be yielded the subject. This works just like {% url `.then()` then %}, except Cypress will apply its retry-until-timeout magic to the function passed to {% url `.should()` should %}.
 
 ```javascript
 cy
@@ -547,6 +546,6 @@ cy
 ```
 
 {% note danger Make sure `.should()` is safe %}
-When using a function passed to `.should()`, be sure that the entire function can be executed multiple times without issue. Cypress applies its retry logic to these functions: so long as there's a failure, it will repeatedly try again until the timeout is reached.
+When using a function passed to {% url `.should()` should %}, be sure that the entire function can be executed multiple times without issue. Cypress applies its retry logic to these functions: so long as there's a failure, it will repeatedly try again until the timeout is reached.
 
 {% endnote %}

docs/source/guides/core-concepts/dealing-with-the-network.md

@@ -102,10 +102,10 @@ Cypress makes it easy to stub a response and control the `body`, `status`, `head
 1. Start a {% url `cy.server()` server %}
 2. Provide a {% url `cy.route()` route %}
 
-These two commands work together to control the behavior of your responses within the command's options. [`cy.server`](https://on.cypress.io/api/server) enables stubbing, while [`cy.route`](https://on.cypress.io/api/route) provides a routing table so Cypress understands which response should go with which request.
+These two commands work together to control the behavior of your responses within the command's options. {% url `cy.server()` server %} enables stubbing, while {% url `cy.route()` route %} provides a routing table so Cypress understands which response should go with which request.
 
 {% note info %}
-See [`cy.server()` options](https://on.cypress.io/api/server#section-options) and [`cy.route()` options](https://on.cypress.io/api/route#section-options) for instructions on how to stub responses.
+See {% url '`cy.server()` options' server#Options %} and {% url '`cy.route()` options' route#Options %} for instructions on how to stub responses.
 {% endnote %}
 
 # Requests
@@ -129,7 +129,7 @@ cy.route({
 })
 ```
 
-When you start a `cy.server()` and define `cy.route()` commands, Cypress displays this under "Routes" in the Command Log.
+When you start a {% url `cy.server()` server %} and define {% url `cy.route()` route %} commands, Cypress displays this under "Routes" in the Command Log.
 
 {% img /img/guides/cypress-basics/dealing-with-the-network/server-routing-table.png Routing Table %}
 

docs/source/guides/core-concepts/stubs-spies-clocks.md

@@ -15,7 +15,7 @@ comments: true
 
 # Capabilities
 
-Cypress comes built in with the ability to [`stub`](https://on.cypress.io/api/stub), [`spy`](https://on.cypress.io/api/spy) or modify your applications [`clock`](https://on.cypress.io/api/clock) - such as controlling `Date`, `setTimeout`, and `setInterval`.
+Cypress comes built in with the ability to {% url `cy.stub()` stub %}, {% url `cy.spy()` spy %} or modify your applications {% url `cy.clock()` clock %} - such as controlling `Date`, `setTimeout`, and `setInterval`.
 
 These commands are useful when writing both **unit tests** and **integration tests**.
 
@@ -25,8 +25,8 @@ Cypress automatically bundles and wraps these libraries:
 
 | Name | What it does |
 | --- | ---- |
-| [`sinon`](http://sinonjs.org) | provides the [`stub`](https://on.cypress.io/api/stub) and [`spy`](https://on.cypress.io/api/spy) API's |
-| [`lolex`](https://github.com/sinonjs/lolex) | provides the [`clock`](https://on.cypress.io/api/clock) and [`tick`](https://on.cypress.io/api/tick) API's |
+| [`sinon`](http://sinonjs.org) | provides the {% url `cy.stub()` stub %} and {% url `cy.spy()` spy %} API's |
+| [`lolex`](https://github.com/sinonjs/lolex) | provides the {% url `cy.clock()` clock %} and {% url `cy.tick()` tick %} API's |
 | [`sinon-as-promised`](https://github.com/bendrucker/sinon-as-promised) | makes it easy to stub `Promise` returning functions |
 | [`sinon-chai`](https://github.com/domenic/sinon-chai) | adds `chai` assertions for stubs and spies |
 
@@ -77,7 +77,7 @@ You generally stub a function when it has side effects you are trying to control
 - You're using `oauth` and want to stub login methods.
 
 {% note info cy.stub() %}
-[Read more about how to use cy.stub](https://on.cypress.io/api/stub)
+{% url 'Read more about how to use `cy.stub()`' stub %}
 {% endnote %}
 
 ## Spies
@@ -91,14 +91,14 @@ cy.spy(obj, "method")
 ```
 
 {% note info cy.spy() %}
-[Read more about how to use cy.spy](https://on.cypress.io/api/spy)
+{% url 'Read more about how to use `cy.spy()`' spy %}
 {% endnote %}
 
 ## Clock
 
 There are situations when it is useful to control your applications `date` and `time` in order to force its behavior or avoid slow tests.
 
-[`cy.clock`](https://on.cypress.io/api/clock) gives you the ability to control:
+{% url `cy.clock()` clock %} gives you the ability to control:
 
 - `Date`
 - `setTimeout`
@@ -109,7 +109,7 @@ There are situations when it is useful to control your applications `date` and `
 - You're polling something in your application with `setInterval` and want to control that.
 - You have **throttled** or **debounced** functions which you want to control.
 
-Once you've enabled [`cy.clock`](https://on.cypress.io/api/clock) you can then control time by **ticking** it ahead by milliseconds.
+Once you've enabled {% url `cy.clock()` clock %} you can then control time by **ticking** it ahead by milliseconds.
 
 ```javascript
 cy.clock()
@@ -118,7 +118,7 @@ cy.get("#search").type("foobarbaz")
 cy.tick(1000)
 ```
 
-[`cy.clock`](https://on.cypress.io/api/clock) is special in that it can be called **prior** to visiting your application, and we will automatically bind it to the application on the next [`cy.visit`](https://on.cypress.io/api/visit). We bind **before** any timers from your application can be invoked. This works identically to [`cy.server`](https://on.cypress.io/api/server) + [`cy.route`](https://on.cypress.io/api/route).
+{% url `cy.clock()` clock %} is special in that it can be called **prior** to visiting your application, and we will automatically bind it to the application on the next {% url `cy.visit()` visit %}. We bind **before** any timers from your application can be invoked. This works identically to {% url `cy.server()` server %} + {% url `cy.route()` route %}.
 
 ## Assertions
 
@@ -194,7 +194,7 @@ We visually indicate when:
 - A `spy` is called
 - A `clock` is ticked
 
-When you use aliasing with the [`.as(alias)`](https://on.cypress.io/api/as) command, we also coorelate those aliases with the calls. This works identically to aliasing a [`cy.route`](https://on.cypress.io/api/route).
+When you use aliasing with the {% url `.as()` as %} command, we also correlate those aliases with the calls. This works identically to aliasing a {% url `cy.route()` route %}.
 
 When stubs are created by calling the method `.withArgs(...)` we also visually link these together.
 

docs/source/guides/core-concepts/taking-screenshots-and-recording-videos.md

@@ -16,7 +16,7 @@ comments: true
 
 Cypress comes with the ability to take screenshots, whether you are running in a real, headed browser (such as Chrome) or when you are running headlessly, possibly in CI.
 
-To take a manual screenshot just use the [`cy.screenshot`](https://on.cypress.io/api/screenshot) command.
+To take a manual screenshot just use the {% url `cy.screenshot()` screenshot %} command.
 
 Additionally, Cypress will automatically capture screenshots when a failure happens but only during a headless run.
 

docs/source/guides/integrating-cypress/environment-variables.md

@@ -35,7 +35,7 @@ There are 4 different ways to set environment variables. Each has a slightly dif
 
 Don't feel obligated to pick just one method. It is common to use one strategy for local development but another when running in [CI](https://on.cypress.io/continuous-integration).
 
-When your tests are running, you can use the [`Cypress.env()`](https://on.cypress.io/api/env) function to access the values of your environment variables.
+When your tests are running, you can use the {% url `Cypress.env` env %} function to access the values of your environment variables.
 
 ## Option #1: `cypress.json`
 

docs/source/incomplete/5-References/Deprecations.md

@@ -19,13 +19,13 @@ cy
   .route(...)
 ```
 
-You no longer have to do this. Whether a [cy.route](https://on.cypress.io/api/route) is stubbed or not is simply based on whether or not you specified a response in [cy.route](https://on.cypress.io/api/route).
+You no longer have to do this. Whether a {% url `cy.route()` route %} is stubbed or not is simply based on whether or not you specified a response in {% url `cy.route()` route %}.
 
 ***
 
 # Passing `cy.route({stub: false})` is now deprecated
 
-In previous versions of Cypress, [cy.route](https://on.cypress.io/api/route) would require a `response` unless you specified `stub: false` in its options.
+In previous versions of Cypress, {% url `cy.route()` route %} would require a `response` unless you specified `stub: false` in its options.
 
 You used to have to write this:
 
@@ -35,7 +35,7 @@ cy
   .route({url: /posts/, stub: false})
 ```
 
-This is now deprecated because Cypress automatically stubs [cy.route](https://on.cypress.io/api/route) based on whether or not it has a `response` property.
+This is now deprecated because Cypress automatically stubs {% url `cy.route()` route %} based on whether or not it has a `response` property.
 
 ```javascript
 cy