You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@solr.apache.org by ct...@apache.org on 2021/11/24 22:42:03 UTC
[solr] 03/03: Fix page refs in configuration-guide module & move 'pure nav' pages aside
This is an automated email from the ASF dual-hosted git repository.
ctargett pushed a commit to branch jira/solr-15556-antora
in repository https://gitbox.apache.org/repos/asf/solr.git
commit 5f2dbd735297a503ffa28e587645a4e8eae924a1
Author: Cassandra Targett <ct...@apache.org>
AuthorDate: Wed Nov 24 16:41:24 2021 -0600
Fix page refs in configuration-guide module & move 'pure nav' pages aside
---
.../modules/configuration-guide/config-nav.adoc | 70 ++++++++++----------
.../configuration-guide/pages/config-api.adoc | 16 ++---
.../configuration-guide/pages/config-sets.adoc | 10 +--
.../configuration-guide/pages/configsets-api.adoc | 4 +-
.../pages/configuration-files.adoc | 12 ++--
.../pages/configuring-solr-xml.adoc | 8 +--
.../pages/configuring-solrconfig-xml.adoc | 31 ++++-----
.../configuration-guide/pages/core-discovery.adoc | 6 +-
.../configuration-guide/pages/coreadmin-api.adoc | 18 +++---
.../pages/implicit-requesthandlers.adoc | 36 +++++------
.../pages/index-location-format.adoc | 4 +-
.../pages/index-segments-merging.adoc | 12 ++--
.../configuration-guide/pages/initparams.adoc | 2 +-
.../modules/configuration-guide/pages/libs.adoc | 4 +-
.../pages/managed-resources.adoc | 12 ++--
.../configuration-guide/pages/package-manager.adoc | 10 +--
.../pages/property-substitution.adoc | 8 +--
.../configuration-guide/pages/realtime-get.adoc | 4 +-
.../pages/request-parameters-api.adoc | 4 +-
.../pages/requestdispatcher.adoc | 4 +-
.../pages/requesthandlers-searchcomponents.adoc | 74 +++++++++++-----------
.../pages/resource-loading.adoc | 8 +--
.../configuration-guide/pages/schema-factory.adoc | 12 ++--
.../pages/script-update-processor.adoc | 2 +-
.../configuration-guide/pages/solr-plugins.adoc | 12 ++--
.../pages/update-request-processors.adoc | 14 ++--
.../old-pages}/configuration-apis.adoc | 0
.../old-pages}/configuration-guide.adoc | 0
28 files changed, 198 insertions(+), 199 deletions(-)
diff --git a/solr/solr-ref-guide/modules/configuration-guide/config-nav.adoc b/solr/solr-ref-guide/modules/configuration-guide/config-nav.adoc
index 6121d5c..0c6f41b 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/config-nav.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/config-nav.adoc
@@ -1,39 +1,39 @@
.Configuration Guide
-* xref:configuration-guide.adoc[]
-** xref:configuration-files.adoc[]
-** xref:property-substitution.adoc[]
-** xref:core-discovery.adoc[]
-** xref:configuring-solr-xml.adoc[]
-** xref:configuring-solrconfig-xml.adoc[]
-*** xref:index-location-format.adoc[]
-*** xref:index-segments-merging.adoc[]
-*** xref:schema-factory.adoc[]
-*** xref:commits-transaction-logs.adoc[]
-*** xref:caches-warming.adoc[]
-*** xref:requesthandlers-searchcomponents.adoc[]
-*** xref:implicit-requesthandlers.adoc[]
-*** xref:realtime-get.adoc[]
-*** xref:initparams.adoc[]
-*** xref:requestdispatcher.adoc[]
-*** xref:update-request-processors.adoc[]
-*** xref:script-update-processor.adoc[]
-*** xref:codec-factory.adoc[]
+* xref:configuration-files.adoc[]
+* xref:property-substitution.adoc[]
+* xref:core-discovery.adoc[]
+* xref:configuring-solr-xml.adoc[]
-** xref:configuration-apis.adoc[]
-*** xref:config-api.adoc[]
-*** xref:request-parameters-api.adoc[]
-*** xref:managed-resources.adoc[]
-*** xref:collections-api.adoc[]
-*** xref:configsets-api.adoc[]
-*** xref:coreadmin-api.adoc[]
-*** xref:v2-api.adoc[]
+* xref:configuring-solrconfig-xml.adoc[]
+** xref:index-location-format.adoc[]
+** xref:index-segments-merging.adoc[]
+** xref:schema-factory.adoc[]
+** xref:commits-transaction-logs.adoc[]
+** xref:caches-warming.adoc[]
+** xref:requesthandlers-searchcomponents.adoc[]
+** xref:implicit-requesthandlers.adoc[]
+** xref:realtime-get.adoc[]
+** xref:initparams.adoc[]
+** xref:requestdispatcher.adoc[]
+** xref:update-request-processors.adoc[]
+** xref:script-update-processor.adoc[]
+** xref:codec-factory.adoc[]
-** xref:config-sets.adoc[]
-** xref:resource-loading.adoc[]
-** xref:solr-plugins.adoc[]
-*** xref:libs.adoc[]
-*** xref:package-manager.adoc[]
-**** xref:package-manager-internals.adoc[]
-*** xref:cluster-plugins.adoc[]
-*** xref:replica-placement-plugins.adoc[]
+* Configuration APIs
+** xref:config-api.adoc[]
+** xref:request-parameters-api.adoc[]
+** xref:managed-resources.adoc[]
+** xref:collections-api.adoc[]
+** xref:configsets-api.adoc[]
+** xref:coreadmin-api.adoc[]
+** xref:v2-api.adoc[]
+
+* xref:config-sets.adoc[]
+* xref:resource-loading.adoc[]
+* xref:solr-plugins.adoc[]
+** xref:libs.adoc[]
+** xref:package-manager.adoc[]
+*** xref:package-manager-internals.adoc[]
+** xref:cluster-plugins.adoc[]
+** xref:replica-placement-plugins.adoc[]
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc
index cf5e812..c9e2f90 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/config-api.adoc
@@ -33,7 +33,7 @@ All Config API endpoints are collection-specific, meaning this API can inspect o
Use GET to retrieve and POST for executing commands.
* `_collection_/config/overlay`: retrieve the details in the `configoverlay.json` only, removing any options defined in `solrconfig.xml` directly or implicitly through defaults.
* `_collection_/config/params`: create parameter sets that can override or take the place of parameters defined in `solrconfig.xml`.
-See <<request-parameters-api.adoc#,Request Parameters API>> for more information about this endpoint.
+See xref:request-parameters-api.adoc[] for more information about this endpoint.
== Retrieving the Config
@@ -92,7 +92,7 @@ http://localhost:8983/api/collections/techproducts/config/requestHandler
====
--
-The output will be details of each request handler defined in `solrconfig.xml`, <<implicit-requesthandlers.adoc#,defined implicitly>> by Solr, and defined with this Config API stored in `configoverlay.json`.
+The output will be details of each request handler defined in `solrconfig.xml`, xref:implicit-requesthandlers.adoc[defined implicitly] by Solr, and defined with this Config API stored in `configoverlay.json`.
To see the configuration for implicit request handlers, add `expandParams=true` to the request.
See the documentation for implicit request handlers linked above for examples using this command.
@@ -169,7 +169,7 @@ The names of these properties are derived from their XML paths as found in `solr
*Update Handler Settings*
-See <<commits-transaction-logs.adoc#,Commits and Transaction Logs>> for defaults and acceptable values for these settings.
+See xref:commits-transaction-logs.adoc[] for defaults and acceptable values for these settings.
* `updateHandler.autoCommit.maxDocs`
* `updateHandler.autoCommit.maxTime`
@@ -180,7 +180,7 @@ See <<commits-transaction-logs.adoc#,Commits and Transaction Logs>> for defaults
*Query Settings*
-See <<caches-warming.adoc#,Caches and Query Warming>> for defaults and acceptable values for these settings.
+See xref:caches-warming.adoc[] for defaults and acceptable values for these settings.
_Caches and Cache Sizes_
@@ -217,14 +217,14 @@ _Query Sizing and Warming_
_Query Circuit Breakers_
-See <<circuit-breakers.adoc#,Circuit Breakers in Solr>> for more details
+See xref:deployment-guide:circuit-breakers.adoc[] for more details
* `query.useCircuitBreakers`
* `query.memoryCircuitBreakerThresholdPct`
*RequestDispatcher Settings*
-See <<requestdispatcher.adoc#,RequestDispatcher>> for defaults and acceptable values for these settings.
+See xref:requestdispatcher.adoc[] for defaults and acceptable values for these settings.
* `requestDispatcher.handleSelect`
* `requestDispatcher.requestParsers.enableRemoteStreaming`
@@ -587,7 +587,7 @@ If the property has already been set, this command will overwrite the previous s
The structure of the request is similar to the structure of requests using other commands, in the format of `"command":{"variable_name": "property_value"}`.
You can add more than one variable at a time if necessary.
-For more information about user-defined properties, see the section <<property-substitution.adoc#user-defined-properties-in-core-properties,User defined properties in core.properties>>.
+For more information about user-defined properties, see the section xref:property-substitution.adoc#user-defined-properties-in-core-properties[User defined properties in core.properties].
See also the section <<Creating and Updating User-Defined Properties>> below for examples of how to use this type of command.
@@ -888,7 +888,7 @@ Every write operation performed through the API would 'touch' the directory and
Every core would check if the schema file, `solrconfig.xml`, or `configoverlay.json` has been modified by comparing the `znode` versions.
If any have been modified, the core is reloaded.
-If `params.json` is modified, the params object is just updated without a core reload (see <<request-parameters-api.adoc#,Request Parameters API>> for more information about `params.json`).
+If `params.json` is modified, the params object is just updated without a core reload (see xref:request-parameters-api.adoc[] for more information about `params.json`).
=== Empty Command
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc
index ea736f9..782aeab 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/config-sets.adoc
@@ -16,7 +16,7 @@
// specific language governing permissions and limitations
// under the License.
-Configsets are a set of configuration files used in a Solr installation: `solrconfig.xml`, the schema, and then <<resource-loading.adoc#,resources>> like language files, `synonyms.txt`, and others.
+Configsets are a set of configuration files used in a Solr installation: `solrconfig.xml`, the schema, and xref:resource-loading.adoc[resources] like language files, `synonyms.txt`, and others.
Such configuration, _configsets_, can be named and then referenced by collections or cores, allowing you to share them to avoid duplication.
@@ -50,7 +50,7 @@ The structure should look something like this:
----
The default base directory is `$SOLR_HOME/configsets`.
-This path can be configured with the `configSetBaseDir` parameter in `solr.xml` (see <<configuring-solr-xml.adoc#,Format of solr.xml>> for details).
+This path can be configured with the `configSetBaseDir` parameter in `solr.xml` (see xref:configuring-solr-xml.adoc[] for details).
To create a new core using a configset, pass `configSet` as one of the core properties.
For example, if you do this via the CoreAdmin API:
@@ -93,10 +93,10 @@ This and a couple of example configsets remain on the file system but Solr does
When you create a collection in SolrCloud, you can specify a named configset.
If you don't, then the `_default` will be copied and given a unique name for use by the new collection.
-A configset can be uploaded to ZooKeeper either via the <<configsets-api.adoc#,Configsets API>> or more directly via <<solr-control-script-reference.adoc#upload-a-configuration-set,`bin/solr zk upconfig`>>.
+A configset can be uploaded to ZooKeeper either via the xref:configsets-api.adoc[] or more directly via xref:deployment-guide:solr-control-script-reference.adoc#upload-a-configuration-set[`bin/solr zk upconfig`].
The Configsets API has some other operations as well, and likewise, so does the CLI.
-To upload a file to a configset already stored on ZooKeeper, you can use <<solr-control-script-reference.adoc#copy-between-local-files-and-zookeeper-znodes,`bin/solr zk cp`>>.
+To upload a file to a configset already stored on ZooKeeper, you can use xref:deployment-guide:solr-control-script-reference.adoc#copy-between-local-files-and-zookeeper-znodes[`bin/solr zk cp`].
CAUTION: By default, ZooKeeper's file size limit is 1MB.
-If your files are larger than this, you'll need to either <<zookeeper-ensemble.adoc#increasing-the-file-size-limit,increase the ZooKeeper file size limit>> or store them <<libs.adoc#lib-directives-in-solrconfig,on the filesystem>>.
+If your files are larger than this, you'll need to either xref:deployment-guide:zookeeper-ensemble.adoc#increasing-the-file-size-limit[increase the ZooKeeper file size limit] or store them xref:libs.adoc#lib-directives-in-solrconfig[on the filesystem] of every node in a cluster.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configsets-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/configsets-api.adoc
index 87421a4..6b8d78b 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/configsets-api.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/configsets-api.adoc
@@ -25,13 +25,13 @@ Using the same concept, you can create your own configsets and make them availab
This API provides a way to upload configuration files to ZooKeeper and share the same set of configuration files between two or more collections.
-Once a configset has been uploaded to ZooKeeper, use the configset name when creating the collection with the <<collections-api.adoc#,Collections API>> and the collection will use your configuration files.
+Once a configset has been uploaded to ZooKeeper, use the configset name when creating the collection with the xref:collections-api.adoc[] and the collection will use your configuration files.
Configsets do not have to be shared between collections if they are uploaded with this API, but this API makes it easier to do so if you wish.
An alternative to uploading your configsets in advance would be to put the configuration files into a directory under `server/solr/configsets` and using the directory name as the `-d` parameter when using `bin/solr create` to create a collection.
NOTE: This API can only be used with Solr running in SolrCloud mode.
-If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section <<config-sets.adoc#,Configsets>>.
+If you are not running Solr in SolrCloud mode but would still like to use shared configurations, please see the section xref:config-sets.adoc[].
The API works by passing commands to the `configs` endpoint.
The path to the endpoint varies depending on the API being used: the v1 API uses `solr/admin/configs`, while the v2 API uses `api/cluster/configs`.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc
index 1d1f2bc..45aeef3 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-files.adoc
@@ -69,18 +69,18 @@ You may see other files, but the main ones you need to know are discussed below.
Inside Solr's Home, you'll find these files:
* `solr.xml` specifies configuration options for your Solr server instance.
-For more information on `solr.xml` see <<configuring-solr-xml.adoc#,Configuring solr.xml>>.
+For more information on `solr.xml` see xref:configuring-solr-xml.adoc[].
* Per Solr Core:
** `core.properties` defines specific properties for each core such as its name, the collection the core belongs to, the location of the schema, and other parameters.
-For more details on `core.properties`, see the section <<core-discovery.adoc#,Core Discovery>>.
+For more details on `core.properties`, see the section xref:core-discovery.adoc[].
** `solrconfig.xml` controls high-level behavior.
You can, for example, specify an alternate location for the data directory.
-For more information on `solrconfig.xml`, see <<configuring-solrconfig-xml.adoc#,Configuring solrconfig.xml>>.
+For more information on `solrconfig.xml`, see xref:configuring-solrconfig-xml.adoc[].
** `managed-schema.xml` or `schema.xml` describes the documents you will ask Solr to index.
The schema defines a document as a collection of fields.
You can define both the field types and the fields themselves.
Field type definitions are powerful and include information about how Solr processes incoming field values and query values.
-For more information on Solr schemas, see <<solr-schema.adoc#,Solr Schema>>.
+For more information on Solr schemas, see xref:indexing-guide:solr-schema.adoc[].
** `data/` contains index files.
Note that the SolrCloud example does not include a `conf` directory for each Solr Core (so there is no `solrconfig.xml` or schema file).
@@ -96,12 +96,12 @@ The Files screen in the Admin UI lets you browse & view configuration files (suc
.The Files Screen
image::configuration-files/files-screen.png[Files screen,height=400]
-If you are using <<cluster-types.adoc#solrcloud-mode,SolrCloud>>, the files displayed are the configuration files for this collection stored in ZooKeeper.
+If you are using xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud], the files displayed are the configuration files for this collection stored in ZooKeeper.
In user-managed clusters or single-node installations, all files in the `conf` directory are displayed.
The configuration files shown may or may not be used by the collection as use of the file depends on how they are referenced in either `solrconfig.xml` or your schema.
Configuration files cannot be edited with this screen, so a text editor of some kind must be used.
-This screen is related to the <<schema-browser-screen.adoc#,Schema Browser Screen>>, in that they both can display information from the schema.
+This screen is related to the xref:indexing-guide:schema-browser-screen.adoc[], in that they both can display information from the schema.
However, the Schema Browser provides a way to drill into the analysis chain and displays linkages between field types, fields, and dynamic field rules.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configuring-solr-xml.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/configuring-solr-xml.adoc
index 306d834..f31f66a 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/configuring-solr-xml.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/configuring-solr-xml.adoc
@@ -19,7 +19,7 @@
The `solr.xml` file defines some global configuration options that apply to all or many cores.
This section will describe the default `solr.xml` file included with Solr and how to modify it for your needs.
-For details on how to configure `core.properties`, see the section <<core-discovery.adoc#,Core Discovery>>.
+For details on how to configure `core.properties`, see the section xref:core-discovery.adoc[].
== Defining solr.xml
@@ -239,7 +239,7 @@ This global limit provides a safety constraint on the total number of clauses al
This limit is enforced at multiple points in Lucene, both to prevent primitive query objects (mainly `BooleanQuery`) from being constructed with an excessive number of clauses in a way that may exhaust the JVM heap, but also to ensure that no composite query (made up of multiple primitive queries) can be executed with an excessive _total_ number of nested clauses in a way that may cause a search thread to use excessive CPU.
+
In default configurations this property uses the value of the `solr.max.booleanClauses` system property if specified.
-This is the same system property used in the `_default` configset for the <<caches-warming.adoc#maxbooleanclauses-element,`<maxBooleanClauses>` element of `solrconfig.xml`>> making it easy for Solr administrators to increase both values (in all collections) without needing to search through and update all of their configs.
+This is the same system property used in the `_default` configset for the xref:caches-warming.adoc#maxbooleanclauses-element[`<maxBooleanClauses>` element of `solrconfig.xml`] making it easy for Solr administrators to increase both values (in all collections) without needing to search through and update all of their configs.
+
[source,xml]
----
@@ -358,7 +358,7 @@ When a different machine takes over serving that core things will be much easier
|Optional |Default: none
|===
+
-Optional parameters that can be specified if you are using <<zookeeper-access-control.adoc#,ZooKeeper Access Control>>.
+Optional parameters that can be specified if you are using xref:deployment-guide:zookeeper-access-control.adoc[].
`distributedClusterStateUpdates`::
+
@@ -544,7 +544,7 @@ The `<metrics>` element in `solr.xml` allows you to customize the metrics report
You can define system properties that should not be returned, or define custom suppliers and reporters.
In a default `solr.xml` you will not see any `<metrics>` configuration.
-If you would like to customize the metrics for your installation, see the section <<metrics-reporting.adoc#metrics-configuration,Metrics Configuration>>.
+If you would like to customize the metrics for your installation, see the section xref:deployment-guide:metrics-reporting.adoc#metrics-configuration[Metrics Configuration].
== Substituting JVM System Properties in solr.xml
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configuring-solrconfig-xml.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/configuring-solrconfig-xml.adoc
index c91f031..3680b92 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/configuring-solrconfig-xml.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/configuring-solrconfig-xml.adoc
@@ -31,7 +31,7 @@
The `solrconfig.xml` file is the configuration file with the most parameters affecting Solr itself.
-While configuring Solr, you'll work with `solrconfig.xml` often, either directly or via the <<config-api.adoc#,Config API>> to create "configuration overlays" (`configoverlay.json`) to override the values in `solrconfig.xml`.
+While configuring Solr, you'll work with `solrconfig.xml` often, either directly or via the xref:config-api.adoc[] to create "configuration overlays" (`configoverlay.json`) to override the values in `solrconfig.xml`.
In `solrconfig.xml`, you configure important features such as:
@@ -49,26 +49,27 @@ The `solrconfig.xml` file is located in the `conf/` directory for each collectio
Several well-commented example files can be found in the `server/solr/configsets/` directories demonstrating best practices for many different types of installations.
Some `solrconfig.xml` aspects are documented in other sections.
-See <<libs.adoc#lib-directives-in-solrconfig,lib directives in SolrConfig>>, which can be used for both Plugins and Resources.
+See xref:libs.adoc#lib-directives-in-solrconfig[lib directives in SolrConfig], which can be used for both Plugins and Resources.
****
// This tags the below list so it can be used in the parent page section list
// tag::solrconfig-sections[]
[cols="1,1",frame=none,grid=none,stripes=none]
|===
-| <<index-location-format.adoc#,Index Location and Format>>: Where and how Solr's indexes are stored.
-| <<index-segments-merging.adoc#,Index Segments and Merging>>: Lucene index writers, including segment management, merges, and locks.
-| <<schema-factory.adoc#,Schema Factory>>: Schema file formats.
-| <<commits-transaction-logs.adoc#,Commits and Transaction Logs>>: Update requests and commit settings.
-| <<caches-warming.adoc#,Caches and Query Warming>>: Caches, query warming, and query listeners.
-| <<requesthandlers-searchcomponents.adoc#,Request Handlers and Search Components>>: Request processors and handlers for search features.
-| <<implicit-requesthandlers.adoc#,Implicit Request Handlers>>: Request end-points automatically provided by Solr.
-| <<realtime-get.adoc#,RealTime Get>>: Get the latest version of a document without opening a searcher.
-| <<initparams.adoc#,InitParams>>: Default parameters for request handlers.
-| <<requestdispatcher.adoc#,RequestDispatcher>>: Advanced request parsing and HTTP cache headers.
-| <<update-request-processors.adoc#,Update Request Processors>>: Plugins for update requests.
-| <<script-update-processor.adoc#,Script Update Processor>>: Java scripting engines during document updates.
-| <<codec-factory.adoc#,Codec Factory>>: Lucene codecs when writing data to disk.
+| xref:index-location-format.adoc[]: Where and how Solr's indexes are stored.
+| xref:index-segments-merging.adoc[]: Lucene index writers, including segment management, merges, and locks.
+| xref:schema-factory.adoc[]: Schema file formats.
+| xref:commits-transaction-logs.adoc[]: Update requests and commit settings.
+| xref:caches-warming.adoc[]: Caches, query warming, and query listeners.
+| xref:requesthandlers-searchcomponents.adoc[]: Request processors and handlers for search features.
+| xref:implicit-requesthandlers.adoc[]: Request end-points automatically provided by Solr.
+| xref:realtime-get.adoc[]: Get the latest version of a document without opening a searcher.
+| xref:initparams.adoc[]: Default parameters for request handlers.
+| xref:requestdispatcher.adoc[]: Advanced request parsing and HTTP cache headers.
+| xref:update-request-processors.adoc[]: Plugins for update requests.
+| xref:script-update-processor.adoc[]: Java scripting engines during document updates.
+| xref:codec-factory.adoc[]: Lucene codecs when writing data to disk.
+|
|===
//end::solrconfig-sections[]
****
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/core-discovery.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/core-discovery.adoc
index 9a01dbb..3dab912 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/core-discovery.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/core-discovery.adoc
@@ -117,7 +117,7 @@ The configuration file name for a given core.
+
The schema file name for a given core.
The default is `schema.xml` but please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use.
-See <<schema-factory.adoc#,Schema Factory Definition in SolrConfig>> for more details.
+See xref:schema-factory.adoc[] for more details.
`dataDir`::
+
@@ -135,7 +135,7 @@ The core's data directory (where indexes are stored) as either an absolute pathn
|Optional |Default: none
|===
+
-The name of a defined configset, if desired, to use to configure the core (see the section <<config-sets.adoc#,Configsets>> for more details).
+The name of a defined configset, if desired, to use to configure the core (see the section xref:config-sets.adoc[] for more details).
`properties`::
+
@@ -216,4 +216,4 @@ The name of the collection this core is part of (SolrCloud only).
Future parameter for SolrCloud or a way for users to mark nodes for their own use.
Additional user-defined properties may be specified for use as variables.
-For more information on how to define local properties, see the section <<property-substitution.adoc#,Property Substitution in `solrconfig.xml`>>.
+For more information on how to define local properties, see the section xref:property-substitution.adoc[].
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc
index 60dec26..cd33ea9 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/coreadmin-api.adoc
@@ -17,11 +17,11 @@
// specific language governing permissions and limitations
// under the License.
-The Core Admin API is primarily used under the covers by the <<collections-api.adoc#,Collections API>> when running a <<cluster-types.adoc#solrcloud-mode,SolrCloud>> cluster.
+The Core Admin API is primarily used under the covers by the xref:collections-api.adoc[] when running a xref:deployment-guide:cluster-types.adoc#solrcloud-mode[SolrCloud] cluster.
SolrCloud users should not typically use the CoreAdmin API directly, but the API may be useful for users of user-managed clusters or single-node installations for core maintenance operations.
-The CoreAdmin API is implemented by the CoreAdminHandler, which is a special purpose <<requesthandlers-searchcomponents.adoc#,request handler>> that is used to manage Solr cores.
+The CoreAdmin API is implemented by the CoreAdminHandler, which is a special purpose xref:requesthandlers-searchcomponents.adoc[request handler] that is used to manage Solr cores.
Unlike other request handlers, the CoreAdminHandler is not attached to a single core.
Instead, there is a single instance of the CoreAdminHandler in each Solr node that manages all the cores running in that node and is accessible at the `/solr/admin/cores` path.
@@ -160,9 +160,9 @@ When you are running SolrCloud and create a new core for a collection, the confi
Each collection is linked to a `configName`, which is stored in ZooKeeper.
This satisfies the configuration requirement.
That said, if you're running SolrCloud, you should *NOT* use the CoreAdmin API at all.
-Instead, use the <<collections-api.adoc#,Collections API>>.
+Instead, use the xref:collections-api.adoc[].
-With a user-managed cluster, if you have <<config-sets.adoc#,Configsets>> defined, you can use the `configSet` parameter as documented below.
+With a user-managed cluster, if you have xref:config-sets.adoc[] defined, you can use the `configSet` parameter as documented below.
If there are no configsets, then the `instanceDir` specified in the CREATE call must already exist, and it must contain a `conf` directory which in turn must contain `solrconfig.xml`, your schema (usually named either `managed-schema.xml` or `schema.xml`), and any files referenced by those configs.
The config and schema filenames can be specified with the `config` and `schema` parameters, but these are expert options.
@@ -218,7 +218,7 @@ Name of the config file (i.e., `solrconfig.xml`) relative to `instanceDir`.
+
Name of the schema file to use for the core.
Please note that if you are using a "managed schema" (the default behavior) then any value for this property which does not match the effective `managedSchemaResourceName` will be read once, backed up, and converted for managed schema use.
-See <<schema-factory.adoc#,Schema Factory Definition in SolrConfig>> for details.
+See xref:schema-factory.adoc[] for details.
`dataDir`::
+
@@ -238,7 +238,7 @@ If absolute value is used, it must be inside `SOLR_HOME`, `SOLR_DATA_HOME` or on
|===
+
Name of the configset to use for this core.
-For more information, see the section <<config-sets.adoc#,Configsets>>.
+For more information, see the section xref:config-sets.adoc[].
`collection`::
+
@@ -253,7 +253,7 @@ The default is the name of the core.
Use `collection.configName=_config-name_` to point to the configuration for a new collection.
+
WARNING: While it's possible to create a core for a non-existent collection, this approach is not supported and not recommended.
-Always create a collection using the <<collections-api.adoc#,Collections API>> before creating a core directly for it.
+Always create a collection using the xref:collections-api.adoc[] before creating a core directly for it.
`shard`::
+
@@ -273,7 +273,7 @@ This should only be required in special circumstances; normally you want to be a
|===
+
Sets the core property _name_ to _value_.
-See the section on defining <<core-discovery.adoc#defining-core-properties-files,core.properties file contents>>.
+See the section on defining xref:core-discovery.adoc#defining-core-properties-files[core.properties file contents].
`async`::
+
@@ -672,7 +672,7 @@ Please note that using a single hash range equal to a route key's hash range is
The `targetCore` must already exist and must have a compatible schema with the `core` index.
A commit is automatically called on the `core` index before it is split.
-This command is used as part of SolrCloud's <<shard-management.adoc#splitshard,SPLITSHARD>> command but it can be used for cores in user-managed clusters as well.
+This command is used as part of SolrCloud's xref:deployment-guide:shard-management.adoc#splitshard[SPLITSHARD] command but it can be used for cores in user-managed clusters as well.
When used against a core in a user-managed cluster without `split.key` parameter, this action will split the source index and distribute its documents alternately so that each split piece contains an equal number of documents.
If the `split.key` parameter is specified then only documents having the same route key will be split from the source index.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/implicit-requesthandlers.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/implicit-requesthandlers.adoc
index b9b0c38..d291270 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/implicit-requesthandlers.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/implicit-requesthandlers.adoc
@@ -64,7 +64,7 @@ v2: `api/node/logging` |{solr-javadocs}/core/org/apache/solr/handler/admin/Loggi
Luke:: Expose the internal Lucene index.
This handler must have a collection name in the path to the endpoint.
+
-*Documentation*: <<luke-request-handler.adoc#,Luke Request Handler>>
+*Documentation*: xref:indexing-guide:luke-request-handler.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -75,7 +75,7 @@ This handler must have a collection name in the path to the endpoint.
MBeans:: Provide info about all registered {solr-javadocs}/core/org/apache/solr/core/SolrInfoBean.html[SolrInfoMBeans].
This handler must have a collection name in the path to the endpoint.
+
-*Documentation*: <<mbean-request-handler.adoc#,MBean Request Handler>>
+*Documentation*: xref:deployment-guide:mbean-request-handler.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -86,7 +86,7 @@ This handler must have a collection name in the path to the endpoint.
Ping:: Health check.
This handler must have a collection name in the path to the endpoint.
+
-*Documentation*: <<ping.adoc#,Ping>>
+*Documentation*: xref:deployment-guide:ping.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -157,7 +157,7 @@ Document Analysis:: Return a breakdown of the analysis process of the given docu
|===
Field Analysis:: Return index- and query-time analysis over the given field(s)/field type(s).
-This handler drives the <<analysis-screen.adoc#,Analysis screen>> in Solr's Admin UI.
+This handler drives the xref:indexing-guide:analysis-screen.adoc[] in Solr's Admin UI.
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -170,7 +170,7 @@ This handler drives the <<analysis-screen.adoc#,Analysis screen>> in Solr's Admi
[horizontal]
Config API:: Retrieve and modify Solr configuration.
+
-*Documentation*: <<config-api.adoc#,Config API>>
+*Documentation*: xref:config-api.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -199,7 +199,7 @@ This handler must have a core name in the path to the endpoint.
Schema API:: Retrieve and modify the Solr schema.
+
-*Documentation*: <<schema-api.adoc#,Schema API>>
+*Documentation*: xref:indexing-guide:schema-api.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -214,7 +214,7 @@ v2: `api/collections/<collection>/schema`, `api/cores/<core>/schema` |{solr-java
[horizontal]
Export:: Export full sorted result sets.
+
-*Documentation*: <<exporting-result-sets.adoc#,Exporting Result Sets>>
+*Documentation*: xref:query-guide:exporting-result-sets.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -224,7 +224,7 @@ Export:: Export full sorted result sets.
RealTimeGet:: Low-latency retrieval of the latest version of a document.
+
-*Documentation*: <<realtime-get.adoc#,RealTime Get>>
+*Documentation*: xref:realtime-get.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -234,7 +234,7 @@ RealTimeGet:: Low-latency retrieval of the latest version of a document.
Graph Traversal:: Return http://graphml.graphdrawing.org/[GraphML] formatted output from a `gatherNodes` streaming expression.
+
-*Documentation*: <<graph-traversal.adoc#,Graph Traversal>>
+*Documentation*: xref:query-guide:graph-traversal.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -244,7 +244,7 @@ Graph Traversal:: Return http://graphml.graphdrawing.org/[GraphML] formatted out
SQL:: SQL query support.
+
-*Documentation*: <<sql-query.adoc#sql-request-handler,SQL Request Handler>>
+*Documentation*: xref:query-guide:sql-query.adoc#sql-request-handler[SQL Request Handler]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -254,7 +254,7 @@ SQL:: SQL query support.
Streaming Expressions:: Distributed stream processing.
+
-*Documentation*: <<streaming-expressions.adoc#streaming-requests-and-responses,Streaming Requests and Responses>>
+*Documentation*: xref:query-guide:streaming-expressions.adoc#streaming-requests-and-responses[Streaming Requests and Responses]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -264,7 +264,7 @@ Streaming Expressions:: Distributed stream processing.
Terms:: Return a field's indexed terms and the number of documents containing each term.
+
-*Documentation*: <<terms-component.adoc#using-the-terms-component-in-a-request-handler,Using the Terms Component in a Request Handler>>
+*Documentation*: xref:query-guide:terms-component.adoc#using-the-terms-component-in-a-request-handler[Using the Terms Component in a Request Handler]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -277,7 +277,7 @@ Terms:: Return a field's indexed terms and the number of documents containing ea
[horizontal]
Update:: Add, delete and update indexed documents formatted as SolrXML, CSV, SolrJSON or javabin.
+
-*Documentation*: <<indexing-with-update-handlers.adoc#,Indexing with Update Handlers>>
+*Documentation*: xref:indexing-guide:indexing-with-update-handlers.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -287,7 +287,7 @@ Update:: Add, delete and update indexed documents formatted as SolrXML, CSV, Sol
CSV Updates:: Add and update CSV-formatted documents.
+
-*Documentation*: <<indexing-with-update-handlers.adoc#csv-update-convenience-paths,CSV Update Convenience Paths>>
+*Documentation*: xref:indexing-guide:indexing-with-update-handlers.adoc#csv-update-convenience-paths[CSV Update Convenience Paths]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -297,7 +297,7 @@ CSV Updates:: Add and update CSV-formatted documents.
JSON Updates:: Add, delete and update SolrJSON-formatted documents.
+
-*Documentation*: <<indexing-with-update-handlers.adoc#json-update-convenience-paths,JSON Update Convenience Paths>>
+*Documentation*: xref:indexing-guide:indexing-with-update-handlers.adoc#json-update-convenience-paths[JSON Update Convenience Paths]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -307,7 +307,7 @@ JSON Updates:: Add, delete and update SolrJSON-formatted documents.
Custom JSON Updates:: Add and update custom JSON-formatted documents.
+
-*Documentation*: <<transforming-and-indexing-custom-json.adoc#,Transforming and Indexing Custom JSON>>
+*Documentation*: xref:indexing-guide:transforming-and-indexing-custom-json.adoc[]
+
[cols="3*.",frame=none,grid=cols,options="header"]
|===
@@ -317,7 +317,7 @@ Custom JSON Updates:: Add and update custom JSON-formatted documents.
== How to View Implicit Handler Paramsets
-You can see configuration for all request handlers, including the implicit request handlers, via the <<config-api.adoc#,Config API>>.
+You can see configuration for all request handlers, including the implicit request handlers, via the xref:config-api.adoc[].
To include the expanded paramset in the response, as well as the effective parameters from merging the paramset parameters with the built-in parameters, use the `expandParams` request parameter.
@@ -382,6 +382,6 @@ The response will look similar to:
== How to Edit Implicit Handler Paramsets
-Because implicit request handlers are not present in `solrconfig.xml`, configuration of their associated `default`, `invariant` and `appends` parameters may be edited via the <<request-parameters-api.adoc#, Request Parameters API>> using the paramset listed in the above table.
+Because implicit request handlers are not present in `solrconfig.xml`, configuration of their associated `default`, `invariant` and `appends` parameters may be edited via the xref:request-parameters-api.adoc[] using the paramset listed in the above table.
However, other parameters, including SearchHandler components, may not be modified.
The invariants and appends specified in the implicit configuration cannot be overridden.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/index-location-format.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/index-location-format.adoc
index 7e0d6cd..652f198 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/index-location-format.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/index-location-format.adoc
@@ -32,7 +32,7 @@ For example:
The `${solr.core.name}` substitution will cause the name of the current core to be substituted, which results in each core's data being kept in a separate subdirectory.
-If you are using <<user-managed-index-replication#,user-managed replication>> to replicate the Solr index, then the `<dataDir>` directory should correspond to the index directory used in the replication configuration.
+If you are using xref:deployment-guide:user-managed-index-replication.adoc[] to replicate the Solr index, then the `<dataDir>` directory should correspond to the index directory used in the replication configuration.
NOTE: If the environment variable `SOLR_DATA_HOME` is defined, or if `solr.data.home` is configured for your DirectoryFactory, or if `solr.xml` contains an
element `<solrDataHome>` then the location of data directory will be `<SOLR_DATA_HOME>/<instance_name>/data`.
@@ -61,5 +61,5 @@ Use this DirectoryFactory to store your index in RAM.
[NOTE]
====
If you are using Hadoop and would like to store your indexes in HDFS, you should use the {solr-javadocs}/core/org/apache/solr/core/HdfsDirectoryFactory.html[`solr.HdfsDirectoryFactory`] instead of either of the above implementations.
-For more details, see the section <<solr-on-hdfs.adoc#,Solr on HDFS>>.
+For more details, see the section xref:deployment-guide:solr-on-hdfs.adoc[].
====
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/index-segments-merging.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/index-segments-merging.adoc
index 839400f..9bf7cb4 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/index-segments-merging.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/index-segments-merging.adoc
@@ -179,7 +179,7 @@ If the configuration options for the built-in merge policies do not fully suit y
----
The example above shows Solr's {solr-javadocs}/core/org/apache/solr/index/SortingMergePolicyFactory.html[`SortingMergePolicyFactory`] being configured to sort documents in merged segments by `"timestamp desc"`, and wrapped around a `TieredMergePolicyFactory` configured to use the values `maxMergeAtOnce=10` and `segmentsPerTier=10` via the `inner` prefix defined by `SortingMergePolicyFactory` 's `wrapped.prefix` option.
-For more information on using `SortingMergePolicyFactory`, see <<common-query-parameters.adoc#segmentterminateearly-parameter,the segmentTerminateEarly parameter>>.
+For more information on using `SortingMergePolicyFactory`, see xref:query-guide:common-query-parameters.adoc#segmentterminateearly-parameter[the segmentTerminateEarly parameter].
=== mergeScheduler
@@ -189,7 +189,7 @@ The alternative, `SerialMergeScheduler`, does not perform merges with separate t
The `ConcurrentMergeScheduler` has the following configurable attributes.
The defaults for these attributes are dynamically set based on whether the underlying disk drive is rotational disk or not.
-Refer to the <<taking-solr-to-production.adoc#dynamic-defaults-for-concurrentmergescheduler, Dynamic defaults for ConcurrentMergeScheduler>> section for more details.
+Refer to xref:deployment-guide:taking-solr-to-production.adoc#dynamic-defaults-for-concurrentmergescheduler[Dynamic Defaults for ConcurrentMergeScheduler] for more details.
`maxMergeCount`::
+
@@ -239,7 +239,7 @@ By default throttling is enabled and the CMS will limit I/O throughput when merg
=== mergedSegmentWarmer
-When using Solr for <<solrcloud-distributed-requests.adoc#near-real-time-nrt-use-cases,Near Real Time Use Cases>>, a merged segment warmer can be configured to warm the reader on the newly merged segment, before the merge commits.
+When using Solr for xref:deployment-guide:solrcloud-distributed-requests.adoc#near-real-time-nrt-use-cases[Near Real Time Use Cases], a merged segment warmer can be configured to warm the reader on the newly merged segment, before the merge commits.
This is not required for near real-time search, but will reduce search latency on opening a new near real-time reader after a merge completes.
[source,xml]
@@ -272,7 +272,7 @@ Many <<Merging Index Segments,Merge Policy>> implementations support `noCFSRatio
The Segments Info screen in the Admin UI lets you see a visualization of the various segments in the underlying Lucene index for this core, with information about the size of each segment – both bytes and in number of documents – as well as other basic metadata about those segments.
Most visible is the number of deleted documents, but you can hover your mouse over the segments to see additional numeric details.
-image::images/index-segments-merging/segments_info.png[image,width=486,height=250]
+image::index-segments-merging/segments_info.png[image,width=486,height=250]
This information may be useful for people to help make decisions about the optimal <<merging-index-segments,merge settings>> for their data.
@@ -282,7 +282,7 @@ This information may be useful for people to help make decisions about the optim
The LockFactory options specify the locking implementation to use.
-The set of valid lock type options depends on the <<index-location-format.adoc#,DirectoryFactory>> you have configured.
+The set of valid lock type options depends on the xref:index-location-format.adoc[DirectoryFactory] you have configured.
The values listed below are are supported by `StandardDirectoryFactory` (the default):
@@ -304,7 +304,7 @@ WARNING: If multiple Solr instances in different JVMs modify an index, this type
See also the {lucene-javadocs}/core/org/apache/lucene/store/SingleInstanceLockFactory.html[SingleInstanceLockFactory javadocs].
* `hdfs` uses `HdfsLockFactory` to support reading and writing index and transaction log files to a HDFS filesystem.
-See the section <<solr-on-hdfs.adoc#,Solr on HDFS>> for more details on using this feature.
+See the section xref:deployment-guide:solr-on-hdfs.adoc[] for more details on using this feature.
[source,xml]
----
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/initparams.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/initparams.adoc
index 10c6641..31e8a5e 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/initparams.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/initparams.adoc
@@ -21,7 +21,7 @@ The `<initParams>` section of `solrconfig.xml` allows you to define request hand
There are a couple of use cases where this might be desired:
-* Some handlers are implicitly defined in code (see <<implicit-requesthandlers.adoc#,Implicit Request Handlers>>) and there should be a way to add, append, or override some of the implicitly defined properties.
+* Some handlers are implicitly defined in code (see xref:implicit-requesthandlers.adoc[]) and there should be a way to add, append, or override some of the implicitly defined properties.
* There are a few properties that are used across handlers.
This helps you keep only a single definition of those properties and apply them over multiple handlers.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc
index f4c1e9f..6552b26 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/libs.adoc
@@ -30,7 +30,7 @@ There are several special places you can place Solr plugin `.jar` files:
* `<solr_home>/lib/`: The `.jar` files placed here are available to all Solr cores running on the node, and to node level plugins referenced in `solr.xml` -- so basically everything.
This directory is not present by default so create it.
-See <<taking-solr-to-production.adoc#solr-home-directory,Solr home directory>>.
+See xref:deployment-guide:taking-solr-to-production.adoc[].
* `<core_instance>/lib/`: In a user-managed cluster or a single-node installation, you may want to add plugins just for a specific Solr core.
Create this adjacent to the `conf/` directory; it's not present by default.
@@ -45,7 +45,7 @@ Solr plugins won't work in these locations.
== Lib Directives in SolrConfig
-_Both_ plugin and <<resource-loading.adoc#,resource>> file paths are configurable via `<lib/>` directives in `solrconfig.xml`.
+_Both_ plugin and xref:resource-loading.adoc[resource] file paths are configurable via `<lib/>` directives in `solrconfig.xml`.
When a directive matches a directory, then resources can be resolved from it.
When a directive matches a `.jar` file, Solr plugins and their dependencies are resolved from it.
Resources can be placed in a `.jar` too but that's unusual.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/managed-resources.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/managed-resources.adoc
index b5cf5bb..7bcd165 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/managed-resources.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/managed-resources.adoc
@@ -40,7 +40,7 @@ After reading this section, you'll be ready to dig into the details of how manag
=== Managing Stop Words
-To begin, you need to define a field type that uses the <<filters.adoc#managed-stop-filter,ManagedStopFilterFactory>>, such as:
+To begin, you need to define a field type that uses the xref:indexing-guide:filters.adoc#managed-stop-filter[ManagedStopFilterFactory], such as:
[source,xml,subs="verbatim,callouts"]
----
@@ -56,7 +56,7 @@ To begin, you need to define a field type that uses the <<filters.adoc#managed-s
There are two important things to notice about this field type definition:
<1> The filter implementation class is `solr.ManagedStopFilterFactory`.
-This is a special implementation of the <<filters.adoc#stop-filter,StopFilterFactory>> that uses a set of stop words that are managed from a REST API.
+This is a special implementation of the xref:indexing-guide:filters.adoc#stop-filter[StopFilterFactory] that uses a set of stop words that are managed from a REST API.
<2> The `managed=”english”` attribute gives a name to the set of managed stop words, in this case indicating the stop words are for English text.
@@ -104,7 +104,7 @@ Assuming you sent this request to Solr, the response body is a JSON document:
}
----
-The `sample_techproducts_configs` <<config-sets.adoc#,configset>> ships with a pre-built set of managed stop words, however you should only interact with this file using the API and not edit it directly.
+The `sample_techproducts_configs` xref:config-sets.adoc[configset] ships with a pre-built set of managed stop words, however you should only interact with this file using the API and not edit it directly.
One thing that should stand out to you in this response is that it contains a `managedList` of words as well as `initArgs`.
This is an important concept in this framework -- managed resources typically have configuration and data.
@@ -144,7 +144,7 @@ This is because it is more common to add a term to an existing list than it is t
=== Managing Synonyms
For the most part, the API for managing synonyms behaves similar to the API for stop words, except instead of working with a list of words, it uses a map, where the value for each entry in the map is a set of synonyms for a term.
-As with stop words, the `sample_techproducts_configs` <<config-sets.adoc#,configset>> includes a pre-built set of synonym mappings suitable for the sample data that is activated by the following field type definition:
+As with stop words, the `sample_techproducts_configs` xref:config-sets.adoc[configset] includes a pre-built set of synonym mappings suitable for the sample data that is activated by the following field type definition:
[source,xml]
----
@@ -224,7 +224,7 @@ Lastly, you can delete a mapping by sending a DELETE request to the managed endp
Changes made to managed resources via this REST API are not applied to the active Solr components until the Solr collection (or Solr core in single server mode) is reloaded.
-For example: after adding or deleting a stop word, you must reload the core/collection before changes become active; related APIs: <<coreadmin-api.adoc#,CoreAdmin API>> and <<collections-api.adoc#,Collections API>>.
+For example: after adding or deleting a stop word, you must reload the core/collection before changes become active; related APIs: xref:coreadmin-api.adoc[] and xref:collections-api.adoc[].
This approach is required when running in distributed mode so that we are assured changes are applied to all cores in a collection at the same time so that behavior is consistent and predictable.
It goes without saying that you don’t want one of your replicas working with a different set of stop words or synonyms than the others.
@@ -238,7 +238,7 @@ However, the intent of this API implementation is that changes will be applied u
====
Changing things like stop words and synonym mappings typically require reindexing existing documents if being used by index-time analyzers.
The RestManager framework does not guard you from this, it simply makes it possible to programmatically build up a set of stop words, synonyms, etc.
-See the section <<reindexing.adoc#,Reindexing>> for more information about reindexing your documents.
+See the section xref:indexing-guide:reindexing.adoc[] for more information about reindexing your documents.
====
== RestManager Endpoint
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/package-manager.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/package-manager.adoc
index bdcf05b..e07996e 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/package-manager.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/package-manager.adoc
@@ -19,7 +19,7 @@
The package manager in Solr allows installation and updating of Solr-specific packages in Solr's cluster environment.
-In this system, a _package_ is a set of Java jar files (usually one) containing one or more <<solr-plugins.adoc#,Solr plugins>>.
+In this system, a _package_ is a set of Java jar files (usually one) containing one or more xref:solr-plugins.adoc[].
Each jar file is also accompanied by a signature string (which can be verified against a supplied public key).
A key design aspect of this system is the ability to install or update packages in a cluster environment securely without the need to restart every node.
@@ -27,7 +27,7 @@ A key design aspect of this system is the ability to install or update packages
Other elements of the design include the ability to install from a remote repository; package standardization; a command line interface (CLI); and a package store.
This section will focus on how to use the package manager to install and update packages.
-For technical details, see the section <<package-manager-internals.adoc#,Package Manager internals>>.
+For technical details, see the section xref:package-manager-internals.adoc[].
== Interacting with the Package Manager
@@ -51,7 +51,7 @@ $ bin/solr -c -Denable.packages=true
WARNING: There are security consequences to enabling the package manager.
If an unauthorized user gained access to the system, they would have write access to ZooKeeper and could install packages from untrusted sources.
-Always ensure you have secured Solr with firewalls and <<authentication-and-authorization-plugins.adoc#,authentication>> before enabling the package manager.
+Always ensure you have secured Solr with firewalls and xref:deployment-guide:authentication-and-authorization-plugins.adoc[] before enabling the package manager.
=== Add Trusted Repositories
@@ -118,7 +118,7 @@ If you pass `-y` to the command, confirmation can be skipped.
==== Manual Deploy
-It is also possible to deploy a package's collection level plugins manually by editing a <<config-sets.adoc#,configset>> and reloading the collection.
+It is also possible to deploy a package's collection level plugins manually by editing a xref:config-sets.adoc[configset] and reloading the collection.
For example, if a package named `mypackage` contains a request handler, we would add it to a configset's `solrconfig.xml` like this:
@@ -127,7 +127,7 @@ For example, if a package named `mypackage` contains a request handler, we would
<requestHandler name="/myhandler" class="mypackage:full.path.to.MyClass"></requestHandler>
----
-Then use either the Collections API <<collection-management.adoc#reload,RELOAD command>> or the <<collections-core-admin.adoc#,Admin UI>> to reload the collection.
+Then use either the Collections API xref:deployment-guide:collection-management.adoc#reload[RELOAD command] or the xref:deployment-guide:collections-core-admin.adoc[Admin UI] to reload the collection.
Next, set the package version that this collection is using.
If the collection is named `collection1`, the package name is `mypackage`, and the installed version is `1.0.0`, the command would look like this:
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/property-substitution.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/property-substitution.adoc
index b4fe681..e70df74 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/property-substitution.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/property-substitution.adoc
@@ -48,11 +48,11 @@ bin/solr start -Dsolr.lock.type=none
In general, any Java system property that you want to set can be passed through the `bin/solr` script using the standard `-Dproperty=value` syntax.
Alternatively, you can add common system properties to the `SOLR_OPTS` environment variable defined in the Solr include file (`bin/solr.in.sh` or `bin/solr.in.cmd`).
-For more information about how the Solr include file works, refer to: <<taking-solr-to-production.adoc#,Taking Solr to Production>>.
+For more information about how the Solr include file works, refer to: xref:deployment-guide:taking-solr-to-production.adoc[].
== Config API to Override solrconfig.xml
-The <<config-api.adoc#,Config API>> allows you to use an API to modify Solr's configuration, specifically user defined properties.
+The xref:config-api.adoc[] allows you to use an API to modify Solr's configuration, specifically user defined properties.
Changes made with this API are stored in a file named `configoverlay.json`.
This file should only be edited with the API, but will look like this example:
@@ -69,7 +69,7 @@ This file should only be edited with the API, but will look like this example:
"components":["terms"]}}}
----
-For more details, see the section <<config-api.adoc#,Config API>>.
+For more details, see the section xref:config-api.adoc[].
== User-Defined Properties in core.properties
@@ -136,7 +136,7 @@ For example, regardless of whether the name for a particular Solr core is explic
</requestHandler>
----
-All implicit properties use the `solr.core.` name prefix, and reflect the runtime value of the equivalent <<core-discovery.adoc#,`core.properties` property>>:
+All implicit properties use the `solr.core.` name prefix, and reflect the runtime value of the equivalent xref:core-discovery.adoc[`core.properties` property]:
* `solr.core.name`
* `solr.core.config`
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/realtime-get.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/realtime-get.adoc
index a74b868..e794bce 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/realtime-get.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/realtime-get.adoc
@@ -30,7 +30,7 @@ Real Time Get relies on the update log feature, which is enabled by default and
</updateLog>
----
-Real Time Get requests can be performed using the `/get` handler which exists implicitly in Solr - see <<implicit-requesthandlers.adoc#,Implicit Request Handlers>> - it's equivalent to the following configuration:
+Real Time Get requests can be performed using the `/get` handler which exists implicitly in Solr - see xref:implicit-requesthandlers.adoc[] - it's equivalent to the following configuration:
[source,xml]
----
@@ -166,7 +166,7 @@ http://localhost:8983/api/collections/techproducts/get?id=mydoc&id=IW-02
====
--
-Real Time Get requests can also be combined with filter queries, specified with an <<common-query-parameters.adoc#fq-filter-query-parameter,`fq` parameter>>:
+Real Time Get requests can also be combined with filter queries, specified with an xref:query-guide:common-query-parameters.adoc#fq-filter-query-parameter[`fq` parameter]:
[.dynamic-tabs]
--
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc
index 4c2daad..11b5e51 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/request-parameters-api.adoc
@@ -20,7 +20,7 @@ The Request Parameters API allows creating parameter sets, a.k.a. paramsets, tha
The parameter sets defined with this API can be used in requests to Solr, or referenced directly in `solrconfig.xml` request handler definitions.
-It is really another endpoint of the <<config-api.adoc#,Config API>> instead of a separate API, and has distinct commands.
+It is really another endpoint of the xref:config-api.adoc[] instead of a separate API, and has distinct commands.
It does not replace or modify any sections of `solrconfig.xml`, but instead provides another approach to handling parameters used in requests.
It behaves in the same way as the Config API, by storing parameters in another file that will be used at runtime.
In this case, the parameters are stored in a file named `params.json`.
@@ -145,7 +145,7 @@ It will be equivalent to a standard request handler definition like:
=== Implicit RequestHandlers with the Request Parameters API
Solr ships with many out-of-the-box request handlers that may only be configured via the Request Parameters API, because their configuration is not present in `solrconfig.xml`.
-See <<implicit-requesthandlers.adoc#,Implicit Request Handlers>> for the paramset to use when configuring an implicit request handler.
+See xref:implicit-requesthandlers.adoc[] for the paramset to use when configuring an implicit request handler.
=== Viewing Expanded Paramsets and Effective Parameters with RequestHandlers
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/requestdispatcher.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/requestdispatcher.adoc
index 290eadf..d706d58 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/requestdispatcher.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/requestdispatcher.adoc
@@ -34,7 +34,7 @@ The default value "false" will ignore requests to `/select` if a request handler
A value of "true" will route query requests to the parser defined with the `qt` value if a request handler is not explicitly registered with the name `/select`.
In recent versions of Solr, a `/select` request handler is defined by default, so a value of "false" will work fine.
-See the section <<requesthandlers-searchcomponents.adoc#,Request Handlers and Search Components>> for more information.
+See the section xref:requesthandlers-searchcomponents.adoc[] for more information.
[source,xml]
----
@@ -114,7 +114,7 @@ This `HttpServletRequest` is not used by any Solr component, but may be useful w
addHttpRequestToContext="false" />
----
-The below command is an example of how to enable RemoteStreaming and BodyStreaming through the <<config-api.adoc#commands-for-common-properties,Config API>>:
+The below command is an example of how to enable RemoteStreaming and BodyStreaming through the xref:config-api.adoc#commands-for-common-properties[Config API]:
[.dynamic-tabs]
--
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/requesthandlers-searchcomponents.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/requesthandlers-searchcomponents.adoc
index 6774322..59acc40 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/requesthandlers-searchcomponents.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/requesthandlers-searchcomponents.adoc
@@ -19,16 +19,16 @@
After the `<query>` section of `solrconfig.xml`, request handlers and search components are configured.
A _request handler_ processes requests coming to Solr.
-These might be query requests, index update requests or specialized interactions such as <<ping.adoc#,ping>>.
+These might be query requests, index update requests or specialized interactions such as xref:deployment-guide:ping.adoc[].
Not all handlers are defined explicitly in `solrconfig.xml`, many are defined implicitly.
-See <<implicit-requesthandlers.adoc#,Implicit Request Handlers>> for details.
+See xref:implicit-requesthandlers.adoc[] for details.
-Additionally, handlers can be defined or overridden in `configoverlay.json` by using <<config-api.adoc#,Config API>>.
-Finally, independent parameter sets can be also defined by <<request-parameters-api.adoc#,Request Parameters API>>.
-They will be stored in `params.json` file and referenced with <<#paramsets-and-useparams,useParams>>.
+Additionally, handlers can be defined or overridden in `configoverlay.json` by using xref:config-api.adoc[].
+Finally, independent parameter sets can be also defined by xref:request-parameters-api.adoc[].
+They will be stored in `params.json` file and referenced with <<paramsets-and-useparams,useParams>>.
-All of this multi-layered configuration, may be verified via <<config-api.adoc#,Config API>>.
+All of this multi-layered configuration can be verified via xref:config-api.adoc[].
Defining your own config handlers is often a useful way to provide defaults and advanced configuration to support business cases and simplify client API.
At the same time, using every single option explained in this guide, will most certainly cause some confusion about which parameter is actually used when.
@@ -81,7 +81,7 @@ Notice the URL-encoded space (as +) for the values of `fl` parameter.
http://localhost:8983/solr/techproducts/select?q=id:SP2514N&fl=id+name&wt=xml
----
-And here is an example of parameters being sent through the POST form to `/query` Search Handler using <<json-request-api.adoc#,JSON Request API>>.
+The following is an example of parameters being sent through the POST form to `/query` Search Handler using the xref:query-guide:json-request-api.adoc[].
[source,bash]
----
@@ -111,7 +111,7 @@ The parameters there are used unless they are overridden by any other method.
</requestHandler>
----
-This example defined a useful troubleshooting parameter <<common-query-parameters.adoc#echoparams-parameter,echoParams>>, with value that returns only params defined in the request itself (no defaults), set it to `all` for more information.
+This example defined a useful troubleshooting parameter xref:query-guide:common-query-parameters.adoc#echoparams-parameter[echoParams], with value that returns only params defined in the request itself (no defaults), set it to `all` for more information.
It also defines the `rows` parameter, with how many results to return (per page) (10 is a true default actually, so this is a redundant definition, if you are not going to modify it).
Note also that the way the defaults are defined in the list varies if the parameter is a string, an integer, or another type.
@@ -131,7 +131,7 @@ Other specialized types may exist, they would be explained in the sections for r
==== Appends
In the `appends` section, you can define parameters that are added those already defined elsewhere.
-These are useful when the same parameter may be meaningfully defined multiple times, such as for <<common-query-parameters.adoc#fq-filter-query-parameter,filter queries>>.
+These are useful when the same parameter may be meaningfully defined multiple times, such as for xref:query-guide:common-query-parameters.adoc#fq-filter-query-parameter[filter queries].
There is no mechanism in Solr to allow a client to override these additions, so you should be absolutely sure you always want these parameters applied to queries.
[source,xml]
@@ -167,11 +167,11 @@ these are the only facets they will be able to see counts for; regardless of wha
It is also possible to configure defaults for request handlers with a section called `initParams`.
These defaults can be used when you want to have common properties that will be used by each separate handler.
For example, if you intend to create several request handlers that will all request the same list of fields in the response, you can configure an `initParams` section with your list of fields.
-For more information about `initParams`, see the section <<initparams.adoc#,InitParams>>.
+For more information about `initParams`, see the section xref:initparams.adoc[].
=== Paramsets and UseParams
If you are expecting to change the parameters often, or if you want define sets of parameters that you can apply on the fly,
-you can define them with <<request-parameters-api.adoc#,Request Parameters API>> and then invoke them
+you can define them with xref:request-parameters-api.adoc[] and then invoke them
by providing one or more in `useParams` setting either in the handler definition itself or as a query parameter.
[source,xml]
@@ -187,9 +187,8 @@ by providing one or more in `useParams` setting either in the handler definition
http://localhost/solr/techproducts/select?useParams=myFacets,myQueries
----
-If paramset is called but is not defined, it is ignored.
-This allows most <<implicit-requesthandlers.adoc#,implicit request handlers>> to call specific paramsets,
-that you can define later, as needed.
+If a paramset is called but is not defined, it is ignored.
+This allows most xref:implicit-requesthandlers.adoc[] to call specific paramsets that you can define later, as needed.
== Search Handlers
@@ -210,10 +209,10 @@ The following sections are allowed within a Search Handler:
All the blocks are optional, especially since parameters can also be provided with `initParams` and `useParams`.
-The defaults/appends/invariants blocks were described <<#defaults-appends-and-invariants,higher>> on the page.
-All the parameters described in the section <<query-guide.adoc#,Query Guide>> can be defined as parameters for any of the Search Handlers.
+The defaults/appends/invariants blocks were described earlier in <<defaults-appends-and-invariants>>.
+All query parameters can be defined as parameters for any of the Search Handlers.
-The Search Components blocks are described next, and <<solrcloud-distributed-requests.adoc#configuring-the-shardhandlerfactory,shardHandlerFactory>> is for fine-tuning of the SolrCloud distributed requests.
+The Search Components blocks are described next, and xref:deployment-guide:solrcloud-distributed-requests.adoc#configuring-the-shardhandlerfactory[shardHandlerFactory] is for fine-tuning of the SolrCloud distributed requests.
=== Defining Search Components
The search components themselves are defined outside of the Request Handlers and then are referenced from various Search Handlers that want to use them.
@@ -228,30 +227,30 @@ They are called in the order listed.
[cols="20,40,40",options="header"]
|===
|Component Name |Class Name |More Information
-|query |`solr.QueryComponent` |Described in the section <<query-syntax-and-parsers.adoc#,Query Syntax and Parsing>>.
-|facet |`solr.FacetComponent` |Original parameter-based facet component, described in the section <<faceting.adoc#,Faceting>>.
-|facet_module |`solr.facet.FacetModule` | JSON Faceting and Analytics module, described in the section <<json-facet-api.adoc#, JSON Facet API>>.
-|mlt |`solr.MoreLikeThisComponent` |Described in the section <<morelikethis.adoc#,MoreLikeThis>>.
-|highlight |`solr.HighlightComponent` |Described in the section <<highlighting.adoc#,Highlighting>>.
-|stats |`solr.StatsComponent` |Described in the section <<stats-component.adoc#,The Stats Component>>.
-|expand |`solr.ExpandComponent` |Described in the section <<collapse-and-expand-results.adoc#,Collapse and Expand Results>>.
-|terms |`solr.TermsComponent` |Described in the section <<terms-component.adoc#,The Terms Component>>.
-|debug |`solr.DebugComponent` |Described in the section on <<common-query-parameters.adoc#debug-parameter,Common Query Parameters>>.
+|query |`solr.QueryComponent` |Described in the section xref:query-guide:query-syntax-and-parsers.adoc[].
+|facet |`solr.FacetComponent` |Original parameter-based facet component, described in the section xref:query-guide:faceting.adoc[].
+|facet_module |`solr.facet.FacetModule` | JSON Faceting and Analytics module, described in the section xref:query-guide:json-facet-api.adoc[].
+|mlt |`solr.MoreLikeThisComponent` |Described in the section xref:query-guide:morelikethis.adoc[].
+|highlight |`solr.HighlightComponent` |Described in the section xref:query-guide:highlighting.adoc[].
+|stats |`solr.StatsComponent` |Described in the section xref:query-guide:stats-component.adoc[].
+|expand |`solr.ExpandComponent` |Described in the section xref:query-guide:collapse-and-expand-results.adoc[].
+|terms |`solr.TermsComponent` |Described in the section xref:query-guide:terms-component.adoc[].
+|debug |`solr.DebugComponent` |Described in the section on xref:query-guide:common-query-parameters.adoc#debug-parameter[debug Parameter].
|===
==== Shipped Custom Components
Apart from default components, Solr ships with a number of additional - very useful - components.
They do need to defined and referenced in `solrconfig.xml` to be actually used.
-* `AnalyticsComponent`, described in the section <<analytics.adoc#,Analytics>>.
-* `ClusteringComponent`, described in the section <<result-clustering.adoc#,Result Clustering>>.
+* `AnalyticsComponent`, described in the section xref:query-guide:analytics.adoc[].
+* `ClusteringComponent`, described in the section xref:query-guide:result-clustering.adoc[].
* `PhrasesIdentificationComponent`, used to identify & score "phrases" found in the input string, based on shingles in indexed fields, described in the {solr-javadocs}/core/org/apache/solr/handler/component/PhrasesIdentificationComponent.html[PhrasesIdentificationComponent] javadocs.
-* `QueryElevationComponent`, described in the section <<query-elevation-component.adoc#,The Query Elevation Component>>.
-* `RealTimeGetComponent`, described in the section <<realtime-get.adoc#,RealTime Get>>.
+* `QueryElevationComponent`, described in the section xref:query-guide:query-elevation-component.adoc[].
+* `RealTimeGetComponent`, described in the section xref:realtime-get.adoc[].
* `ResponseLogComponent`, used to record which documents are returned to the user via the Solr log, described in the {solr-javadocs}/core/org/apache/solr/handler/component/ResponseLogComponent.html[ResponseLogComponent] javadocs.
-* `SpellCheckComponent`, described in the section <<spell-checking.adoc#,Spell Checking>>.
-* `SuggestComponent`, described in the section <<suggester.adoc#,Suggester>>.
-* `TermVectorComponent`, described in the section <<term-vector-component.adoc#,The Term Vector Component>>.
+* `SpellCheckComponent`, described in the section xref:query-guide:spell-checking.adoc[].
+* `SuggestComponent`, described in the section xref:query-guide:suggester.adoc[].
+* `TermVectorComponent`, described in the section xref:query-guide:term-vector-component.adoc[].
Some third party components are also linked from https://solr.cool/ website.
@@ -310,8 +309,7 @@ This should be considered as a last-resort option as the default list may change
== Update Request Handlers
The Update Request Handlers are request handlers which process updates to the index.
-Most of the request handlers are <<implicit-requesthandlers.adoc#update-handlers,implicit>>
-and can be customized by defining properly named Paramsets.
+Most of the available update request handlers are xref:implicit-requesthandlers.adoc#update-handlers[implicit] and can be customized by defining properly named Paramsets.
If you need to define additional Update Request Handler, the syntax is:
@@ -323,10 +321,10 @@ If you need to define additional Update Request Handler, the syntax is:
----
-The full details are covered in the section <<indexing-with-update-handlers.adoc#,Indexing with Update Handlers>>.
+The full details are covered in the section xref:indexing-guide:indexing-with-update-handlers.adoc[].
Similar to Search Components for Search Handlers, Solr has document-preprocessing plugins for Update Request Handlers,
-called <<update-request-processors.adoc#,Update Request Processors>>,
+called xref:update-request-processors.adoc[],
which also allow for default and custom configuration chains.
-Note: Do not confuse Update Request Handlers with <<commits-transaction-logs.adoc#,`updateHandler`>> section also defined in `solrconfig.xml`.
+Note: Do not confuse Update Request Handlers with xref:commits-transaction-logs.adoc[`updateHandler`] section also defined in `solrconfig.xml`.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc
index d489a35..bcdbe17 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/resource-loading.adoc
@@ -19,17 +19,17 @@
Solr components can be configured using *resources*: data stored in external files that may be referred to in a location-independent fashion.
-Examples of resources include: files needed by schema components, e.g., a stopword list for <<filters.adoc#stop-filter,Stop Filter>>; and machine-learned models for <<learning-to-rank.adoc#,Learning to Rank>>.
+Examples of resources include: files needed by schema components, e.g., a stopword list for xref:indexing-guide:filters.adoc#stop-filter[Stop Filter]; and machine-learned models for xref:query-guide:learning-to-rank.adoc[].
_Resources are typically resolved from the configSet_ but there are other options too.
Solr's resources are generally only loaded initially when the Solr collection or Solr core is loaded.
After you update a resource, you'll typically need to _reload_ the affected collections when running SolrCloud, or the cores when running a user-managed cluster or single-node installation.
Restarting all affected Solr nodes also works.
-<<managed-resources.adoc#,Managed resources>> can be manipulated via APIs and do not need an explicit reload.
+xref:managed-resources.adoc[] can be manipulated via APIs and do not need an explicit reload.
== Resources in Configsets
-<<config-sets.adoc#,Configsets>> are the directories containing solrconfig.xml, the schema, and resources referenced by them.
+xref:config-sets.adoc[] are the directories containing `solrconfig.xml`, the schema, and resources referenced by them.
In SolrCloud they are stored in ZooKeeper.
In a user-managed cluster and a single-node installation they are stored on the file system.
In any mode, resources may be shared or may be dedicated to a configSet.
@@ -37,7 +37,7 @@ Prefer to put resources here.
== Resources in Other Places
-Resources can also be placed in an arbitrary directory and <<libs.adoc#lib-directives-in-solrconfig,referenced>> from a `<lib />` directive in `solrconfig.xml`, provided the directive refers to a directory and not the actual resource file.
+Resources can also be placed in an arbitrary directory and xref:libs.adoc#lib-directives-in-solrconfig[referenced] from a `<lib />` directive in `solrconfig.xml`, provided the directive refers to a directory and not the actual resource file.
Example: `<lib path="/volume/models/" />`
This choice may make sense if the resource is too large for a configset in ZooKeeper.
However it's up to you to somehow ensure that all nodes in your cluster have access to these resources.
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/schema-factory.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/schema-factory.adoc
index 3b80f3b..61843aa 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/schema-factory.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/schema-factory.adoc
@@ -17,7 +17,7 @@
// under the License.
Solr supports two styles of schema: a managed schema and a manually maintained `schema.xml` file.
-When using a managed schema, features such as the <<schema-api.adoc#,Schema API>> and <<schemaless-mode.adoc#,Schemaless Mode>> are available.
+When using a managed schema, features such as the xref:indexing-guide:schema-api.adoc[] and xref:indexing-guide:schemaless-mode.adoc[] are available.
When using `schema.xml`, the only way changes can be made to Solr's schema is by manually editing the file.
== <schemaFactory> in solrconfig.xml
@@ -46,7 +46,7 @@ When a `<schemaFactory/>` is not explicitly declared in a `solrconfig.xml` file,
Using the Managed Schema is required to be able to use the Schema API to modify your schema.
However, using Managed Schema does not mean you are also using Solr in Schemaless Mode (or "schema guessing" mode).
-Schemaless mode requires enabling the Managed Schema if it is not already, but full schema guessing requires additional configuration as described in the section <<schemaless-mode.adoc#,Schemaless Mode>>.
+Schemaless mode requires enabling the Managed Schema if it is not already, but full schema guessing requires additional configuration as described in the section xref:indexing-guide:schemaless-mode.adoc[].
Below is an example of a `schemaFactory` that reflects Solr's defaults:
@@ -70,7 +70,7 @@ The defaults can be overridden by explicitly configuring `ManagedIndexSchemaFact
Controls whether changes may be made to the schema data.
This must be set to `true` to allow edits to be made with the Schema API.
+
-With the default configuration shown above, you could use the <<schema-api.adoc#,Schema API>> to modify the schema as much as you want, and then later change the value of `mutable` to `false` to "lock" the schema in place and prevent future changes.
+With the default configuration shown above, you could use the xref:indexing-guide:schema-api.adoc[] to modify the schema as much as you want, and then later change the value of `mutable` to `false` to "lock" the schema in place and prevent future changes.
`managedSchemaResourceName`::
+
@@ -110,7 +110,7 @@ If you look at the resulting file, you'll see this at the top of the page:
<!-- Solr managed schema - automatically generated - DO NOT EDIT -->
----
-You are now free to use the <<schema-api.adoc#,Schema API>> to make changes, and remove the `schema.xml.bak`.
+You are now free to use the xref:indexing-guide:schema-api.adoc[] to make changes, and remove the `schema.xml.bak`.
=== Switching from Managed Schema to schema.xml
@@ -124,10 +124,10 @@ If you have started Solr with managed schema enabled and you would like to switc
If you are using SolrCloud, you may need to modify the files via ZooKeeper.
The `bin/solr` script provides an easy way to download the files from ZooKeeper and upload them back after edits.
-See the section <<solr-control-script-reference.adoc#zookeeper-operations,ZooKeeper Operations>> for more information.
+See the section xref:deployment-guide:solr-control-script-reference.adoc#zookeeper-operations[ZooKeeper Operations] for more information.
[TIP]
====
To have full control over your `schema.xml` file, you may also want to disable schema guessing, which allows unknown fields to be added to the schema during indexing.
-The properties that enable this feature are discussed in the section <<schemaless-mode.adoc#,Schemaless Mode>>.
+The properties that enable this feature are discussed in the section xref:indexing-guide:schemaless-mode.adoc[].
====
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/script-update-processor.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/script-update-processor.adoc
index 5ca3cdb..9d47db3 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/script-update-processor.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/script-update-processor.adoc
@@ -35,7 +35,7 @@ The scripting update processor lives in the contrib module `/contrib/scripting`,
Java 11 and previous versions come with a JavaScript engine called Nashorn, but Java 12 will require you to add your own JavaScript engine.
Other supported scripting engines like JRuby, Jython, Groovy, all require you to add JAR files.
-Learn more about adding the `dist/solr-scripting-*.jar` file, and any other needed JAR files (depending on your scripting engine) into Solr's <<libs.adoc#lib-directories,Lib Directories>>.
+Learn more about adding the `dist/solr-scripting-*.jar` file, and any other needed JAR files (depending on your scripting engine) into Solr's xref:libs.adoc#lib-directories[Lib Directories].
== Configuration
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/solr-plugins.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/solr-plugins.adoc
index 3ec40f5..95ed8e8 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/solr-plugins.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/solr-plugins.adoc
@@ -36,12 +36,12 @@ One resource is the Solr Wiki documentation on plugins at https://cwiki.apache.o
There are essentially two types of plugins in Solr:
* Collection level plugins.
-These are registered on individual collections, either by hand-editing the `solrconfig.xml` or schema files for the collection's configset or by using the <<config-api.adoc#,config API>> or <<schema-api.adoc#,schema API>>.
+These are registered on individual collections, either by hand-editing the `solrconfig.xml` or schema files for the collection's configset or by using the xref:config-api.adoc[] or xref:indexing-guide:schema-api.adoc[].
Examples of these are query parsers, request handlers, update request processors, value source parsers, response writers etc.
* Cluster level (or Core Container level) plugins.
These are plugins that are installed at a cluster level and every Solr node has one instance each of these plugins.
-Examples of these are <<authentication-and-authorization-plugins.adoc#,authentication and authorization plugins>>, <<metrics-reporting.adoc#reporters,metrics reporters>>, https://issues.apache.org/jira/browse/SOLR-14404[cluster level request handlers] etc.
+Examples of these are xref:deployment-guide:authentication-and-authorization-plugins.adoc[], xref:deployment-guide:metrics-reporting.adoc#reporters[metrics reporters], https://issues.apache.org/jira/browse/SOLR-14404[cluster level request handlers], etc.
== Installing Plugins ==
@@ -56,10 +56,10 @@ The next sections describe some options:
// tag::plugin-sections[]
[cols="1,1",frame=none,grid=none,stripes=none]
|===
-| <<libs.adoc#,Lib Directories>>: Plugins as libraries on the filesystem.
-| <<package-manager.adoc#,Package Management>>: Package-based plugins.
-| <<cluster-plugins.adoc#,Cluster Plugins>>: Cluster-level plugins.
-| <<replica-placement-plugins.adoc#,Replica Placement Plugins>>: Plugins specifically for replica placement.
+| xref:libs.adoc[]: Plugins as libraries on the filesystem.
+| xref:package-manager.adoc[]: Package-based plugins.
+| xref:cluster-plugins.adoc[]: Cluster-level plugins.
+| xref:replica-placement-plugins.adoc[]: Plugins specifically for replica placement.
|===
// end::plugin-sections[]
****
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc b/solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc
index 3cd5e33..3f30675 100644
--- a/solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc
+++ b/solr/solr-ref-guide/modules/configuration-guide/pages/update-request-processors.adoc
@@ -138,7 +138,7 @@ For update requests this routing is implemented by the `DistributedUpdateRequest
In SolrCloud clusters, all processors in the chain _before_ the `DistributedUpdateProcessor` are run on the first node that receives an update from the client, regardless of this node's status as a leader or replica.
The `DistributedUpdateProcessor` then forwards the update to the appropriate shard leader for the update (or to multiple leaders in the event of an update that affects multiple documents, such as a delete by query or commit).
-The shard leader uses a transaction log to apply <<partial-document-updates.adoc#,Atomic Updates & Optimistic Concurrency>> and then forwards the update to all of the shard replicas.
+The shard leader uses a transaction log to apply xref:indexing-guide:partial-document-updates.adoc[] and then forwards the update to all of the shard replicas.
The leader and each replica run all of the processors in the chain that are listed _after_ the `DistributedUpdateProcessor`.
For example, consider the "dedupe" chain which we saw in a section above.
@@ -182,7 +182,7 @@ Otherwise the expensive computation is repeated on both the leader and replica n
.Custom update chain post-processors may never be invoked on a recovering replica
[WARNING]
====
-While a replica is in <<solrcloud-recoveries-and-write-tolerance.adoc#,recovery>>, inbound update requests are buffered to the transaction log.
+While a replica is in xref:deployment-guide:solrcloud-recoveries-and-write-tolerance.adoc[recovery], inbound update requests are buffered to the transaction log.
After recovery has completed successfully, those buffered update requests are replayed.
As of this writing, however, custom update chain post-processors are never invoked for buffered update requests.
See https://issues.apache.org/jira/browse/SOLR-8030[SOLR-8030].
@@ -193,7 +193,7 @@ To work around this problem until SOLR-8030 has been fixed, *avoid specifying po
If the `AtomicUpdateProcessorFactory` is in the update chain before the `DistributedUpdateProcessor`, the incoming document to the chain will be a partial document.
-Because `DistributedUpdateProcessor` is responsible for processing <<partial-document-updates.adoc#,Atomic Updates>> into full documents on the leader node, this means that pre-processors which are executed only on the forwarding nodes can only operate on the partial document.
+Because `DistributedUpdateProcessor` is responsible for processing xref:indexing-guide:partial-document-updates.adoc[atomic updates] into full documents on the leader node, this means that pre-processors which are executed only on the forwarding nodes can only operate on the partial document.
If you have a processor which must process a full document then the only choice is to specify it as a post-processor.
@@ -275,9 +275,9 @@ In the first example, Solr will dynamically create a chain which has "signature"
We can also specify a custom chain to be used by default for all requests sent to specific update handlers instead of specifying the names in request parameters for each request.
-This can be done by adding either "update.chain" or "processor" and "post-processor" as default parameter for a given path which can be done either via <<initparams.adoc#,initParams>> or by adding them in a <<requesthandlers-searchcomponents.adoc#,"defaults" section>> which is supported by all request handlers.
+This can be done by adding either "update.chain" or "processor" and "post-processor" as default parameter for a given path which can be done either via xref:initparams.adoc[] or by adding them in a xref:requesthandlers-searchcomponents.adoc["defaults" section] which is supported by all request handlers.
-The following is an `initParam` defined in the <<schemaless-mode.adoc#,schemaless configuration>> which applies a custom update chain to all request handlers starting with "/update/".
+The following is an `initParam` defined in the xref:indexing-guide:schemaless-mode.adoc[] which applies a custom update chain to all request handlers starting with "/update/".
.Example initParams
[source,xml]
@@ -338,7 +338,7 @@ It can help to prevent unexpected problems on indexing as well as on recovering
Useful for only indexing one copy of "similar" documents.
{solr-javadocs}/contrib/scripting/org/apache/solr/scripting/update/ScriptUpdateProcessorFactory.html[ScriptUpdateProcessorFactory]:: An processor that enables the use of update processors implemented as scripts.
-Learn more at the <<script-update-processor.adoc#,script update processor>> page.
+Learn more in the section xref:script-update-processor.adoc[].
{solr-javadocs}/core/org/apache/solr/update/processor/TemplateUpdateProcessorFactory.html[TemplateUpdateProcessorFactory]:: Allows adding new fields to documents based on a template pattern.
This update processor can also be used at runtime (without defining it in `solrconfig.xml`), see the section <<templateupdateprocessorfactory>> below.
@@ -413,7 +413,7 @@ The {solr-javadocs}/contrib/langid/index.html[`langid`] contrib provides::
The {solr-javadocs}/contrib/analysis-extras/index.html[`analysis-extras`] contrib provides::
{solr-javadocs}/contrib/analysis-extras/org/apache/solr/update/processor/OpenNLPExtractNamedEntitiesUpdateProcessorFactory.html[OpenNLPExtractNamedEntitiesUpdateProcessorFactory]::: Update document(s) to be indexed with named entities extracted using an OpenNLP NER model.
-Note that in order to use model files larger than 1MB on SolrCloud, you must either <<zookeeper-ensemble#increasing-the-file-size-limit,configure both ZooKeeper server and clients>> or <<libs.adoc#lib-directives-in-solrconfig,store the model files on the filesystem>> on each node hosting a collection replica.
+Note that in order to use model files larger than 1MB on SolrCloud, you must either xref:deployment-guide:zookeeper-ensemble#increasing-the-file-size-limit[configure both ZooKeeper server and clients] or xref:libs.adoc#lib-directives-in-solrconfig[store the model files on the filesystem] on each node hosting a collection replica.
=== Update Processor Factories You Should _Not_ Modify or Remove
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-apis.adoc b/solr/solr-ref-guide/src/old-pages/configuration-apis.adoc
similarity index 100%
rename from solr/solr-ref-guide/modules/configuration-guide/pages/configuration-apis.adoc
rename to solr/solr-ref-guide/src/old-pages/configuration-apis.adoc
diff --git a/solr/solr-ref-guide/modules/configuration-guide/pages/configuration-guide.adoc b/solr/solr-ref-guide/src/old-pages/configuration-guide.adoc
similarity index 100%
rename from solr/solr-ref-guide/modules/configuration-guide/pages/configuration-guide.adoc
rename to solr/solr-ref-guide/src/old-pages/configuration-guide.adoc