[pull] master from mattermost:master

docs/develop/contribute/more-info/server/plugins.md

@@ -17,9 +17,9 @@ Plugins are generally made of at least two parts: a manifest and a server binary
 
 The manifest tells Mattermost what the plugin is and provides a set of metadata used by the server to install and run the plugin. Please see the [manifest reference](/developers/integrate/plugins/manifest-reference) for more information. Manifests may be defined in JSON or YAML.
 
-The server binary is a compiled Go program that extends the [MattermostPlugin](https://godoc.org/github.com/mattermost/mattermost/server/public/plugin#MattermostPlugin) struct of the [plugin](https://godoc.org/github.com/mattermost/mattermost/server/public/plugin) package. When enabled, the plugin's server binary is started as a process by the Mattermost server. Plugin developers then have access to interact with the Mattermost server over RPC through the plugin [API](/developers/integrate/reference/server/server-reference#API) and [Hooks](/developers/integrate/reference/server/server-reference#Hooks). The server-side of plugins is built using the [go-plugin](https://github.com/hashicorp/go-plugin) library from Hashicorp. More information is available in the [server side of the plugin author documentation](/developers/integrate/plugins/components/server).
+The server binary is a compiled Go program that extends the [MattermostPlugin](https://godoc.org/github.com/mattermost/mattermost/server/public/plugin#MattermostPlugin) struct of the [plugin](https://godoc.org/github.com/mattermost/mattermost/server/public/plugin) package. When enabled, the plugin's server binary is started as a process by the Mattermost server. Plugin developers then have access to interact with the Mattermost server over RPC through the plugin [API](/developers/integrate/reference/server#API) and [Hooks](/developers/integrate/reference/server#Hooks). The server-side of plugins is built using the [go-plugin](https://github.com/hashicorp/go-plugin) library from Hashicorp. More information is available in the [server side of the plugin author documentation](/developers/integrate/plugins/components/server).
 
-The JavaScript bundle is a webpack-built collection of JavaScript code that will be run on the Mattermost web/desktop apps. When a plugin is enabled, the client is notified and it makes a request to add the JS bundle to the document. The plugin's client code then registers itself and its components with the Mattermost client through the client's [plugin registry](/developers/integrate/reference/webapp/webapp-reference#registry). The registry contains many methods for registering different components and callbacks. These are all stored as part of the app's [plugin reducer](https://github.com/mattermost/mattermost/blob/master/webapp/channels/src/reducers/plugins/index.ts). The [Pluggable](https://github.com/mattermost/mattermost/tree/master/webapp/channels/src/plugins/pluggable) component is then inserted into various places in the app, allowing plugins to insert components into these locations in the UI. In some special cases, the Pluggable component is not used and we instead implement the plugs manually. More information is available in the [webapp side of the plugin author documentation](/developers/integrate/plugins/components/webapp).
+The JavaScript bundle is a webpack-built collection of JavaScript code that will be run on the Mattermost web/desktop apps. When a plugin is enabled, the client is notified and it makes a request to add the JS bundle to the document. The plugin's client code then registers itself and its components with the Mattermost client through the client's [plugin registry](/developers/integrate/reference/webapp#registry). The registry contains many methods for registering different components and callbacks. These are all stored as part of the app's [plugin reducer](https://github.com/mattermost/mattermost/blob/master/webapp/channels/src/reducers/plugins/index.ts). The [Pluggable](https://github.com/mattermost/mattermost/tree/master/webapp/channels/src/plugins/pluggable) component is then inserted into various places in the app, allowing plugins to insert components into these locations in the UI. In some special cases, the Pluggable component is not used and we instead implement the plugs manually. More information is available in the [webapp side of the plugin author documentation](/developers/integrate/plugins/components/webapp).
 
 All these different components of a plugin are compressed into a .tar.gz bundle. Installing a plugin is the process of uploading this bundle to the Mattermost server (via the UI, REST API or CLI). The server then unpacks the bundle, performs some validation and extracts it into the configured directory for storing installed plugins. Installed plugins are not yet running. To start a plugin it must be enabled (again via the UI, REST API or CLI). Once it is enabled, the server will then start the server process and prepare the web app bundle for serving to the client. Plugin settings, configuration and enabled/disabled status are managed by the Mattermost `config.json` using a [PluginSettings](https://godoc.org/github.com/mattermost/mattermost/server/public/model#PluginSettings) struct.
 

docs/develop/integrate/getting-started/index.md

@@ -24,7 +24,7 @@ Plugins are the most comprehensive way to add new features and customization, bu
 
 
 <Note title="Tip">
-See the [Mattermost Server SDK Reference](/developers/integrate/reference/server/server-reference) and [Mattermost Client UI SDK Reference](/developers/integrate/reference/webapp/webapp-reference) documentation for details on available server API endpoints and client methods.
+See the [Mattermost Server SDK Reference](/developers/integrate/reference/server) and [Mattermost Client UI SDK Reference](/developers/integrate/reference/webapp) documentation for details on available server API endpoints and client methods.
 </Note>
 
 

docs/develop/integrate/plugins/best-practices.md

@@ -9,7 +9,7 @@ See here for [server-specific best practices for plugins](/developers/integrate/
 
 Once a plugin is installed, Administrators have access to the plugin's configuration page in the __System Console > Plugins__ section. The configurable settings must first be defined in the plugin's manifest [setting schema](/developers/integrate/plugins/manifest-reference#settings_schema). The web app supports several basic pre-defined settings type, e.g. `bool` and `dropdown`, for which the corresponding UI components are provided in order to complete configuration in the System Console.
 
-These settings are stored within the server configuration under [`Plugins`] indexed by plugin ids. The plugin's server code can access their current configuration calling the [`getConfig`](/developers/integrate/reference/server/server-reference#API.GetConfig) API call and can also make changes as needed with [`saveConfig`](/developers/integrate/reference/server/server-reference#API.SaveConfig).
+These settings are stored within the server configuration under [`Plugins`] indexed by plugin ids. The plugin's server code can access their current configuration calling the [`getConfig`](/developers/integrate/reference/server#API.GetConfig) API call and can also make changes as needed with [`saveConfig`](/developers/integrate/reference/server#API.SaveConfig).
 
 ## How can a plugin define its own setting type?
 
@@ -29,7 +29,7 @@ A plugin could define its own type of setting with a corresponding custom user i
     }
     ```
 
-2. In the plugin's web app code, define a custom component to manage the plugin's custom setting and register it in the web app with [`registerAdminConsoleCustomSetting`](/developers/integrate/reference/webapp/webapp-reference#registerAdminConsoleCustomSetting). This component will be instantiated in the System Console with the following `props` passed in:
+2. In the plugin's web app code, define a custom component to manage the plugin's custom setting and register it in the web app with [`registerAdminConsoleCustomSetting`](/developers/integrate/reference/webapp#registerAdminConsoleCustomSetting). This component will be instantiated in the System Console with the following `props` passed in:
 
     - `id`: The setting `key` as defined in the plugin manifest within `settings_schema.settings`.
     - `label`: The text for the component label based on the setting's `displayName` defined in the manifest. 
@@ -132,7 +132,7 @@ Old servers won't do anything with new, unrecognized fields, but also won't brea
 
 ## How to expose performance metrics for a plugin?
 
-From Mattermost v9.4, a [`ServeMetrics`](/developers/integrate/reference/server/server-reference#API.ServeMetrics) hook can be used to expose performance metrics in the [open metrics format](https://openmetrics.io/) under the common HTTP listener controlled by the [`MetricsSettings.ListenAddress`](https://docs.mattermost.com/configure/environment-configuration-settings.html#listen-address-for-performance) config setting.
+From Mattermost v9.4, a [`ServeMetrics`](/developers/integrate/reference/server#API.ServeMetrics) hook can be used to expose performance metrics in the [open metrics format](https://openmetrics.io/) under the common HTTP listener controlled by the [`MetricsSettings.ListenAddress`](https://docs.mattermost.com/configure/environment-configuration-settings.html#listen-address-for-performance) config setting.
 
 Data returned by the hook's implementation through the given `http.ResponseWriter` object will be served through the `http://SITE_URL:8067/plugins/PLUGIN_ID/metrics` URL.
 

docs/develop/integrate/plugins/components/server/best-practices.md

@@ -9,7 +9,7 @@ Add all static files under a file directory named `public` within the plugin dir
 
 ## How do plugins make sure http requests are authentic?
 
-Plugins can implement the [`ServeHTTP`](/developers/integrate/reference/server/server-reference#Hooks.ServeHTTP) to listen to http requests. This can be used to receive post action requests when [Interactive Messages Buttons and Menus](https://docs.mattermost.com/developer/interactive-messages.html) are triggered by users.
+Plugins can implement the [`ServeHTTP`](/developers/integrate/reference/server#Hooks.ServeHTTP) to listen to http requests. This can be used to receive post action requests when [Interactive Messages Buttons and Menus](https://docs.mattermost.com/developer/interactive-messages.html) are triggered by users.
 
 When plugins act as an HTTP server, they serve requests from Mattermost clients (which are authenticated in a Mattermost sense), but may also serve HTTP requests from external services like webhooks. These requests from external services might use the Authorization header to authorize themselves against the plugin.
 

docs/develop/integrate/plugins/components/server/ha.md

@@ -9,7 +9,7 @@ It is important that all plugins consider HA environments when being built.
 
 Plugins are started as subprocesses of the main Mattermost process on each app server. This means a Mattermost deployment that has three app servers will have three separate copies of the same plugin running. Each running copy of the plugin will be isolated from one another on different servers. Therefore, to run properly in HA the plugin's server-side code must be stateless.
 
-To be stateless, the plugin must not retain any information or status in memory that may be needed across multiple events (e.g. HTTP requests or in other hooks). This data should instead be stored in a place that all running copies of the plugin have access to. For example, the [key-value store](/developers/integrate/reference/server/server-reference#API.KVSet) the plugin API provides.
+To be stateless, the plugin must not retain any information or status in memory that may be needed across multiple events (e.g. HTTP requests or in other hooks). This data should instead be stored in a place that all running copies of the plugin have access to. For example, the [key-value store](/developers/integrate/reference/server#API.KVSet) the plugin API provides.
 
 To better explain the problem with having a plugin store data in-memory, consider this case:
 

docs/develop/integrate/plugins/components/server/hello-world.md

@@ -37,7 +37,7 @@ cd $GOPATH/src/my-plugin
 
 Create a file named `plugin.go` with the following contents:
 
-\{/* TODO: unconverted Hugo shortcode \{\{<plugingoexamplecode name="_helloWorld">\}\} (sources/mattermost-developer-documentation/site/content/integrate/plugins/components/server/hello-world.md) */\}
+<PluginGoExample name="_helloWorld" />
 
 This plugin will register an HTTP handler that will respond with "Hello, world!" when requested.
 

docs/develop/integrate/plugins/components/server/index.md

@@ -7,21 +7,21 @@ Server plugins are subprocesses invoked by the server that communicate with Matt
 
 Looking for a quick start? [See our "Hello, world!" tutorial](/developers/integrate/plugins/components/server/hello-world).
 
-Want the Server SDK reference doc? [Find it here](/developers/integrate/reference/server/server-reference).
+Want the Server SDK reference doc? [Find it here](/developers/integrate/reference/server).
 
 ## Features
 
 #### RPC API
 
-Use the [RPC API](/developers/integrate/reference/server/server-reference#API) to execute create, read, update and delete (CRUD) operations on server data models.
+Use the [RPC API](/developers/integrate/reference/server#API) to execute create, read, update and delete (CRUD) operations on server data models.
 
 For example, your plugin can consume events from a third-party webhook and create corresponding posts in Mattermost, without having to host your code outside Mattermost.
 
 #### Hooks
 
-Register for [hooks](/developers/integrate/reference/server/server-reference#Hooks) and get alerted when certain events occur.
+Register for [hooks](/developers/integrate/reference/server#Hooks) and get alerted when certain events occur.
 
-For example, consume the [OnConfigurationChange](/developers/integrate/reference/server/server-reference#Hooks.OnConfigurationChange) hook to respond to server configuration changes, or the [MessageHasBeenPosted](/developers/integrate/reference/server/server-reference#Hooks.MessageHasBeenPosted) hook to respond to posts.
+For example, consume the [OnConfigurationChange](/developers/integrate/reference/server#Hooks.OnConfigurationChange) hook to respond to server configuration changes, or the [MessageHasBeenPosted](/developers/integrate/reference/server#Hooks.MessageHasBeenPosted) hook to respond to posts.
 
 #### REST API
 
@@ -33,7 +33,7 @@ Plugins with both a web app and server component can leverage this REST API to e
 
 When starting a plugin, the server consults the [plugin's manifest](/developers/integrate/plugins/manifest-reference) to determine if a server component was included. If found, the server launches a new process using the executable included with the plugin.
 
-The server will trigger the [OnActivate](/developers/integrate/reference/server/server-reference#Hooks.OnActivate) hook if the plugin is successfully started, allowing you to perform startup events. If the plugin is disabled, the server will trigger the [OnDeactivate](/developers/integrate/reference/server/server-reference#Hooks.OnDeactivate) hook. While running, the server plugin can consume hook events, make API calls, launch threads or subprocesses of its own, interact with third-party services or do anything else a regular program can do.
+The server will trigger the [OnActivate](/developers/integrate/reference/server#Hooks.OnActivate) hook if the plugin is successfully started, allowing you to perform startup events. If the plugin is disabled, the server will trigger the [OnDeactivate](/developers/integrate/reference/server#Hooks.OnDeactivate) hook. While running, the server plugin can consume hook events, make API calls, launch threads or subprocesses of its own, interact with third-party services or do anything else a regular program can do.
 
 ## High availability
 

docs/develop/integrate/plugins/components/webapp/actions.md

@@ -169,7 +169,7 @@ Get the client options to make requests to the server. Use this to create your o
 
 Reducers in Redux are pure functions that describe how the data in the store changes after any given action. Reducers will always produce the same resulting state for a given state and action. You can register a custom reducer for your plugin against the Redux store with the `registerReducer` function.
 
-### [registerReducer(reducer)](/developers/integrate/reference/webapp/webapp-reference#registerReducer)
+### [registerReducer(reducer)](/developers/integrate/reference/webapp#registerReducer)
 
 Registers a reducer against the Redux store. It will be accessible in Redux state under `state['plugins-<yourpluginid>']`. It generally accepts a reducer and returns undefined.
 
@@ -275,7 +275,7 @@ The container is doing two things. First, it's grabbing the current (logged in)
 
 Now we can use `this.props.patchUser()` to update a user. The example component we made uses it to patch the current user's first name.
 
-To use our component in our plugin we would then use the registry in the initialization function of the plugin to register the component somewhere in the Mattermost UI. That is beyond the scope of this guide, but you can [read more about that here](/developers/integrate/reference/webapp/webapp-reference).
+To use our component in our plugin we would then use the registry in the initialization function of the plugin to register the component somewhere in the Mattermost UI. That is beyond the scope of this guide, but you can [read more about that here](/developers/integrate/reference/webapp).
 
 ## Available actions