[docs] Fix various syntax and rendering errors

docs/docset.yml

@@ -15,6 +15,8 @@ toc:
   - toc: release-notes
   - toc: extend
 subs:
+  version: "9.0.0"
+  branch: "9.0"
   ecloud:   "Elastic Cloud"
   ech:   "Elastic Cloud Hosted"
   ess:   "Elasticsearch Service"

docs/extend/development-documentation.md

@@ -10,7 +10,7 @@ Docs should be written during development and accompany PRs when relevant. There
 
 ## End user documentation [_end_user_documentation]
 
-Documentation about user facing features should be written in [asciidoc](http://asciidoc.org/) at [[https://github.com/elastic/kibana/tree/main/docs](https://github.com/elastic/kibana//tree/master/docs)(https://github.com/elastic/kibana/tree/main/docs)]
+Documentation about user facing features should be written in [asciidoc](http://asciidoc.org/) at [https://github.com/elastic/kibana/tree/main/docs](https://github.com/elastic/kibana/tree/main/docs).
 
 To build the docs, you must clone the [elastic/docs](https://github.com/elastic/docs) repo as a sibling of your {{kib}} repo. Follow the instructions in that project’s README for getting the docs tooling set up.
 
@@ -31,4 +31,4 @@ REST APIs should be documented using the following recommended formats:
 
 ## General developer documentation and guidelines [_general_developer_documentation_and_guidelines]
 
-General developer guildlines and documentation, like this right here, should be written in [asciidoc](http://asciidoc.org/) at [[https://github.com/elastic/kibana/tree/main/docs/developer](https://github.com/elastic/kibana//tree/master/docs/developer)(https://github.com/elastic/kibana/tree/main/docs/developer)]
+General developer guildlines and documentation, like this right here, should be written in [asciidoc](http://asciidoc.org/) at [https://github.com/elastic/kibana/tree/main/docs/extend](https://github.com/elastic/kibana/tree/main/docs/extend).

docs/extend/development-security.md

@@ -21,10 +21,10 @@ Role-based access control (RBAC) in {{kib}} relies upon the [application privile
 
 When {{kib}} first starts up, it executes the following `POST` request against {{es}}. This synchronizes the definition of the privileges with various `actions` which are later used to authorize a user:
 
-```js
+```js subs=true
 POST /_security/privilege
 Content-Type: application/json
-Authorization: Basic {kib} changeme
+Authorization: Basic {{kib}} changeme
 
 {
    "kibana-.kibana":{
@@ -256,7 +256,7 @@ public setup(core, { features }) {
     },
     privilegesTooltip: i18n.translate('xpack.features.devToolsPrivilegesTooltip', {
      defaultMessage:
-       'User should also be granted the appropriate {es} cluster and index privileges',
+       'User should also be granted the appropriate Elasticsearch cluster and index privileges',
    }),
   });
 }

docs/extend/development-tests.md

@@ -75,7 +75,20 @@ We use functional tests to make sure the {{kib}} UI works as expected. It replac
 
 #### Running functional tests [_running_functional_tests]
 
-The `FunctionalTestRunner` (FTR) is very bare bones and gets most of its functionality from its config file. The {{kib}} repo contains many FTR config files which use slightly different configurations for the {{kib}} server or {{es}}, have different test files, and potentially other config differences. FTR config files are organised in manifest files, based on testing area and type of distribution: serverless: - ftr_base_serverless_configs.yml - ftr_oblt_serverless_configs.yml - ftr_security_serverless_configs.yml - ftr_search_serverless_configs.yml stateful: - ftr_platform_stateful_configs.yml - ftr_oblt_stateful_configs.yml - ftr_security_stateful_configs.yml - ftr_search_stateful_configs.yml If you’re writing a plugin outside the {{kib}} repo, you will have your own config file. See [Functional Tests for Plugins outside the {{kib}} repo](/extend/external-plugin-functional-tests.md) for more info.
+The `FunctionalTestRunner` (FTR) is very bare bones and gets most of its functionality from its config file. The {{kib}} repo contains many FTR config files which use slightly different configurations for the {{kib}} server or {{es}}, have different test files, and potentially other config differences. FTR config files are organised in manifest files, based on testing area and type of distribution:
+
+- serverless:
+  - `ftr_base_serverless_configs.yml`
+  - `ftr_oblt_serverless_configs.yml`
+  - `ftr_security_serverless_configs.yml`
+  - `ftr_search_serverless_configs.yml`
+- stateful:
+  - `ftr_platform_stateful_configs.yml`
+  - `ftr_oblt_stateful_configs.yml`
+  - `ftr_security_stateful_configs.yml`
+  - `ftr_search_stateful_configs.yml`
+
+If you’re writing a plugin outside the {{kib}} repo, you will have your own config file. See [Functional Tests for Plugins outside the {{kib}} repo](/extend/external-plugin-functional-tests.md) for more info.
 
 There are three ways to run the tests depending on your goals:
 
@@ -292,7 +305,7 @@ export default function ({ getService, getPageObject }) {
   describe('My Test Suite', () => {
 
     // most suites start with a before hook that navigates to a specific
-    // app/page and restores some archives into {es} with esArchiver
+    // app/page and restores some archives into Elasticsearch with esArchiver
     before(async () => {
       await Promise.all([
         // start by clearing Saved Objects from the .kibana index
@@ -305,7 +318,7 @@ export default function ({ getService, getPageObject }) {
     });
 
     // right after the before() hook definition, add the teardown steps
-    // that will tidy up {es} for other test suites
+    // that will tidy up Elasticsearch for other test suites
     after(async () => {
       // we clear Kibana Saved Objects but not the makelogs
       // archive because we don't make any changes to it, and subsequent
@@ -586,7 +599,12 @@ log.debug(‘done clicking menu’);
 
 #### MacOS testing performance tip [_macos_testing_performance_tip]
 
-macOS users on a machine with a discrete graphics card may see significant speedups (up to 2x) when running tests by changing your terminal emulator’s GPU settings. In iTerm2: * Open Preferences (Command + ,) * In the General tab, under the "Magic" section, ensure "GPU rendering" is checked * Open "Advanced GPU Settings…​" * Uncheck the "Prefer integrated to discrete GPU" option * Restart iTerm
+macOS users on a machine with a discrete graphics card may see significant speedups (up to 2x) when running tests by changing your terminal emulator’s GPU settings. In iTerm2:
+* Open Preferences (Command + ,)
+* In the General tab, under the "Magic" section, ensure "GPU rendering" is checked
+* Open "Advanced GPU Settings…​"
+* Uncheck the "Prefer integrated to discrete GPU" option
+* Restart iTerm
 
 
 ### Flaky Test Runner [_flaky_test_runner]

docs/extend/external-plugin-functional-tests.md

@@ -14,7 +14,7 @@ Every project or plugin should have its own `FunctionalTestRunner` config file.
 
 To get started copy and paste this example to `src/platform/test/functional/config.js`:
 
-```js
+```js subs=true
 import { resolve } from 'path';
 import { REPO_ROOT } from '@kbn/utils';
 
@@ -25,7 +25,7 @@ import { MyAppPageProvider } from './services/my_app_page';
 // that returns an object with the projects config values
 export default async function ({ readConfigFile }) {
 
-  // read the {kib} config file so that we can utilize some of
+  // read the Kibana config file so that we can utilize some of
   // its services and PageObjects
   const kibanaConfig = await readConfigFile(resolve(REPO_ROOT, 'src/platform/test/functional/config.base.js'));
 
@@ -44,7 +44,7 @@ export default async function ({ readConfigFile }) {
     },
 
     // just like services, PageObjects are defined as a map of
-    // names to Providers. Merge in {kib}'s or pick specific ones
+    // names to Providers. Merge in Kibana's or pick specific ones
     pageObjects: {
       management: kibanaConfig.get('pageObjects.management'),
       myApp: MyAppPageProvider,
@@ -53,7 +53,7 @@ export default async function ({ readConfigFile }) {
     // the apps section defines the urls that
     // `PageObjects.common.navigateTo(appKey)` will use.
     // Merge urls for your plugin with the urls defined in
-    // {kib}'s config in order to use this helper
+    // Kibana's config in order to use this helper
     apps: {
       ...kibanaConfig.get('apps'),
       myApp: {
@@ -68,7 +68,7 @@ export default async function ({ readConfigFile }) {
 
     // more settings, like timeouts, mochaOpts, etc are
     // defined in the config schema.
-    // See {kibana-blob}packages/kbn-test/src/functional_test_runner/lib/config/schema.ts
+    // https://github.com/elastic/kibana/blob/{{branch}}/src/platform/packages/shared/kbn-test/src/functional_test_runner/lib/config/schema.ts
   };
 }
 ```

docs/extend/external-plugin-localization.md

@@ -27,7 +27,7 @@ You must add a `translations` directory at the root of your plugin. This directo
 To simplify the localization process, {{kib}} provides tools for the following functions:
 
 * Verify all translations have translatable strings and extract default messages from templates
-* Verify translation files and integrate them into {kib}
+* Verify translation files and integrate them into {{kib}}
 
 To use {{kib}} i18n tooling, create a `.i18nrc.json` file with the following configs:
 

docs/extend/interpreting-ci-failures.md

@@ -36,7 +36,7 @@ The logs in Pipeline Steps contain `Info` level logging. To debug Functional UI
 
 Looking at the failure, we first look at the Error and stack trace. In the example below, this test failed to find an element within the timeout; `Error: retry.try timeout: TimeoutError: Waiting for element to be located By(css selector, [data-test-subj="createSpace"])`
 
-We know the test file from the stack trace was on line 50 of `test/accessibility/apps/spaces.ts` (this test and the stack trace context is kibana/x-pack/ so the file is {{kib-repo}}blob/master/x-pack/test/accessibility/apps/group1/spaces.ts#L50). The function to click on the element was called from a page object method in `test/functional/page_objects/space_selector_page.ts` {{kib-repo}}blob/master/x-pack/test/functional/page_objects/space_selector_page.ts#L58
+We know the test file from the stack trace was on line 50 of `test/accessibility/apps/spaces.ts` (this test and the stack trace context is kibana/x-pack/ so the file is [`x-pack/test/accessibility/apps/group1/spaces.ts`](https://github.com/elastic/kibana/blob/master/x-pack/test/accessibility/apps/group1/spaces.ts#L50). The function to click on the element was called from a page object method in [`test/functional/page_objects/space_selector_page.ts`](https://github.com/elastic/kibana/blob/master/x-pack/test/functional/page_objects/space_selector_page.ts#L58).
 
 ```
 [00:03:36]             │ debg --- retry.try error: Waiting for element to be located By(css selector, [data-test-subj="createSpace"])

docs/extend/plugin-list.md

@@ -24,12 +24,12 @@ mapped_pages:
 | [contentManagement](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/content_management/README.md) | The content management plugin provides functionality to manage content in Kibana. |
 | [controls](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/controls/README.mdx) | The Controls plugin contains Embeddables which can be used to add user-friendly interactivity to apps. |
 | [customIntegrations](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/custom_integrations/README.md) | Register add-data cards |
-| [dashboard](kibana-dashboard-plugin.md) | - Registers the dashboard application. - Adds a dashboard embeddable that can be used in other applications. |
+| [dashboard](kibana-dashboard-plugin.md) | - Registers the dashboard application.<br>- Adds a dashboard embeddable that can be used in other applications. |
 | [data](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/data/README.mdx) | The data plugin provides common data access services, such as search and query, for solutions and application developers. |
 | [dataViewEditor](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/data_view_editor/README.md) | Create data views from within Kibana apps. |
 | [dataViewFieldEditor](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/data_view_field_editor/README.md) | The reusable field editor across Kibana! |
 | [dataViewManagement](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/data_view_management) | WARNING: Missing or empty README. |
-| [dataViews](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/data_views/README.mdx) | The data views API provides a consistent method of structuring and formatting documents and field lists across the various Kibana apps. It's typically used in conjunction with <DocLink id="kibDevTutorialDataSearchAndSessions" section="high-level-search" text="SearchSource" /> for composing queries. |
+| [dataViews](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/data_views/README.mdx) | The data views API provides a consistent method of structuring and formatting documents and field lists across the various Kibana apps. It's typically used in conjunction with `SearchSource` for composing queries. |
 | [devTools](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/dev_tools/README.md) | The ui/registry/dev_tools is removed in favor of the devTools plugin which exposes a register method in the setup contract. Registering app works mostly the same as registering apps in core.application.register. Routing will be handled by the id of the dev tool - your dev tool will be mounted when the URL matches /app/dev_tools#/<YOUR ID>. This API doesn't support angular, for registering angular dev tools, bootstrap a local module on mount into the given HTML element. |
 | [discover](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/discover/README.md) | Contains the Discover application and the saved search embeddable. |
 | [discoverShared](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/discover_shared/README.md) | A stateful layer to register shared features and provide an access point to discover without a direct dependency. |
@@ -79,7 +79,7 @@ mapped_pages:
 | [telemetry](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/telemetry/README.md) | Telemetry allows Kibana features to have usage tracked in the wild. The general term "telemetry" refers to multiple things: |
 | [telemetryCollectionManager](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/telemetry_collection_manager/README.md) | Telemetry's collection manager to go through all the telemetry sources when fetching it before reporting. |
 | [telemetryManagementSection](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/telemetry_management_section/README.md) | This plugin adds the Advanced Settings section for the Usage and Security Data collection (aka Telemetry). |
-| [uiActions](uiactions-plugin.md) | UI Actions plugins provides API to manage *triggers* and *actions*.  *Trigger* is an abstract description of user's intent to perform an action (like user clicking on a value inside chart). It allows us to do runtime binding between code from different plugins. For, example one such trigger is when somebody applies filters on dashboard; another one is when somebody opens a Dashboard panel context menu.  *Actions* are pieces of code that execute in response to a trigger. For example, to the dashboard filtering trigger multiple actions can be attached. Once a user filters on the dashboard all possible actions are displayed to the user in a popup menu and the user has to chose one.  In general this plugin provides:  - Creating custom functionality (actions). - Creating custom user interaction events (triggers). - Attaching and detaching actions to triggers. - Emitting trigger events. - Executing actions attached to a given trigger. - Exposing a context menu for the user to choose the appropriate action when there are multiple actions attached to a single trigger. |
+| [uiActions](uiactions-plugin.md) | UI Actions plugins provides API to manage *triggers* and *actions*.  *Trigger* is an abstract description of user's intent to perform an action (like user clicking on a value inside chart). It allows us to do runtime binding between code from different plugins. For, example one such trigger is when somebody applies filters on dashboard; another one is when somebody opens a Dashboard panel context menu.  *Actions* are pieces of code that execute in response to a trigger. For example, to the dashboard filtering trigger multiple actions can be attached. Once a user filters on the dashboard all possible actions are displayed to the user in a popup menu and the user has to chose one.<br>In general this plugin provides:<br>- Creating custom functionality (actions).<br>- Creating custom user interaction events (triggers).<br>- Attaching and detaching actions to triggers.<br>- Emitting trigger events.<br>- Executing actions attached to a given trigger.<br>- Exposing a context menu for the user to choose the appropriate action when there are multiple actions attached to a single trigger. |
 | [uiActionsEnhanced](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/ui_actions_enhanced/README.md) | Registers commercially licensed generic actions like per panel time range and contains some code that supports drilldown work. |
 | [unifiedDocViewer](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/unified_doc_viewer/README.md) | This plugin contains services reliant on the plugin lifecycle for the unified doc viewer component (see @kbn/unified-doc-viewer). |
 | [unifiedSearch](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/unified_search/README.md) | Contains all the components of Kibana's unified search experience. Specifically: |

docs/extend/sample-data.md

@@ -10,7 +10,7 @@ There are a couple ways to easily get data ingested into {{es}}.
 
 ## Sample data packages available for one click installation [_sample_data_packages_available_for_one_click_installation]
 
-The easiest is to install one or more of our available sample data packages. If you have no data, you should be prompted to install when running {{kib}} for the first time. You can also access and install the sample data packages by going to the **Integrations*** page and selecting ***Sample data**.
+The easiest is to install one or more of our available sample data packages. If you have no data, you should be prompted to install when running {{kib}} for the first time. You can also access and install the sample data packages by going to the **Integrations** page and selecting **Sample data**.
 
 
 ## makelogs script [_makelogs_script]
@@ -28,4 +28,4 @@ Make sure to execute `node scripts/makelogs` **after** {{es}} is up and running!
 
 ## CSV upload [_csv_upload]
 
-You can also use the CSV uploader provided on the **Upload file*** page available in the list of ***Integrations***. Navigate to ***Add data*** > ***Upload file** to upload your data from a file.
+You can also use the CSV uploader provided on the **Upload file** page available in the list of **Integrations**. Navigate to **Add data** > **Upload file** to upload your data from a file.