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/29 20:52:45 UTC

[solr] 04/04: Fix refs in upgrade-notes + cleanups for earlier changes

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 efc87d0ec5aa2c7d620d6c7d36ec08e837b69b27
Author: Cassandra Targett <ct...@apache.org>
AuthorDate: Mon Nov 29 14:52:02 2021 -0600

    Fix refs in upgrade-notes + cleanups for earlier changes
---
 solr/solr-ref-guide/modules/ROOT/pages/index.adoc  |   8 -
 .../pages/configuration-files.adoc                 |   2 +-
 .../getting-started/pages/introduction.adoc        |   2 +-
 .../transforming-and-indexing-custom-json.adoc     |   2 +-
 .../query-guide/pages/block-join-query-parser.adoc |  10 +-
 .../pages/collapse-and-expand-results.adoc         |   2 +-
 .../query-guide/pages/common-query-parameters.adoc |   2 +-
 .../query-guide/pages/dismax-query-parser.adoc     |   2 +-
 .../query-guide/pages/document-transformers.adoc   |   2 +-
 .../modules/query-guide/pages/faceting.adoc        |   4 +-
 .../query-guide/pages/function-queries.adoc        |   2 +-
 .../pages/json-faceting-domain-changes.adoc        |   2 +-
 .../query-guide/pages/math-expressions.adoc        |   3 +-
 .../pages/searching-nested-documents.adoc          |  13 +-
 .../modules/query-guide/pages/spell-checking.adoc  |   2 +-
 .../modules/query-guide/pages/sql-query.adoc       |   2 +-
 .../query-guide/pages/standard-query-parser.adoc   |   4 +-
 .../pages/stream-decorator-reference.adoc          |   2 +-
 .../pages/major-changes-in-solr-6.adoc             |  40 +++--
 .../pages/major-changes-in-solr-7.adoc             | 162 ++++++++++++++-------
 .../pages/major-changes-in-solr-8.adoc             |  59 ++++----
 .../pages/major-changes-in-solr-9.adoc             |   8 +-
 .../upgrade-notes/pages/solr-upgrade-notes.adoc    |  23 +--
 .../modules/upgrade-notes/upgrade-nav.adoc         |   1 -
 solr/solr-ref-guide/package-lock.json              |   6 +-
 25 files changed, 211 insertions(+), 154 deletions(-)

diff --git a/solr/solr-ref-guide/modules/ROOT/pages/index.adoc b/solr/solr-ref-guide/modules/ROOT/pages/index.adoc
index 8f9eb3f..33086df 100644
--- a/solr/solr-ref-guide/modules/ROOT/pages/index.adoc
+++ b/solr/solr-ref-guide/modules/ROOT/pages/index.adoc
@@ -1,13 +1,5 @@
 = Apache Solr Reference Guide
-:page-children: getting-started, \
-    deployment-guide, \
-    configuration-guide, \
-    schema-indexing-guide, \
-    query-guide, \
-    solr-upgrade-notes
-:page-notitle:
 :page-show-toc: false
-:page-layout: home
 // Licensed to the Apache Software Foundation (ASF) under one
 // or more contributor license agreements.  See the NOTICE file
 // distributed with this work for additional information
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 45aeef3..9cb7be6 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
@@ -80,7 +80,7 @@ For more information on `solrconfig.xml`, see xref:configuring-solrconfig-xml.ad
 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 xref:indexing-guide:solr-schema.adoc[].
+For more information on Solr schemas, see xref:indexing-guide:schema-elements.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).
diff --git a/solr/solr-ref-guide/modules/getting-started/pages/introduction.adoc b/solr/solr-ref-guide/modules/getting-started/pages/introduction.adoc
index 0700b7a..216679c 100644
--- a/solr/solr-ref-guide/modules/getting-started/pages/introduction.adoc
+++ b/solr/solr-ref-guide/modules/getting-started/pages/introduction.adoc
@@ -26,7 +26,7 @@ Any platform capable of HTTP can talk to Solr.
 See xref:deployment-guide:client-apis.adoc[] for details on client APIs.
 
 Flexible schema configurations allow nearly any type of data to be stored in Solr.
-The xref:indexing-guide:schema-indexing-guide.adoc[] has more details on these options.
+The xref:indexing-guide:schema-elements.adoc[] has more details on these options.
 
 Solr offers support for the simplest keyword searching through to complex queries on multiple fields and faceted search results.
 Collapsing and clustering results offer compelling features for e-commerce and storefronts.
diff --git a/solr/solr-ref-guide/modules/indexing-guide/pages/transforming-and-indexing-custom-json.adoc b/solr/solr-ref-guide/modules/indexing-guide/pages/transforming-and-indexing-custom-json.adoc
index 621874d..766ee74 100644
--- a/solr/solr-ref-guide/modules/indexing-guide/pages/transforming-and-indexing-custom-json.adoc
+++ b/solr/solr-ref-guide/modules/indexing-guide/pages/transforming-and-indexing-custom-json.adoc
@@ -332,7 +332,7 @@ Solr will automatically attempt to add the content of the field from the JSON in
 ====
 Documents will be rejected during indexing if the fields do not exist in the schema before indexing.
 So, if you are NOT using schemaless mode, you must pre-create all fields.
-If you are working in xref:configuration-guide:schemaless-mode.adoc[], however, fields that don't exist will be created on the fly with Solr's best guess for the field type.
+If you are working in xref:schemaless-mode.adoc[], however, fields that don't exist will be created on the fly with Solr's best guess for the field type.
 ====
 
 === Reusing Parameters in Multiple Requests
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/block-join-query-parser.adoc b/solr/solr-ref-guide/modules/query-guide/pages/block-join-query-parser.adoc
index 9cfbed4..b798ffe 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/block-join-query-parser.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/block-join-query-parser.adoc
@@ -54,7 +54,7 @@ This parser wraps a query that matches some parent documents and returns the chi
 The syntax for this parser is: `q={!child of=<blockMask>}<someParents>`.
 
 * The inner subordinate query string (`someParents`) must be a query that will match some parent documents
-* The `of` parameter must be a query string to use as a <<#block-mask,Block Mask>> -- typically a query that matches the set of all possible parent documents
+* The `of` parameter must be a query string to use as a <<block-mask,Block Mask>> -- typically a query that matches the set of all possible parent documents
 
 The resulting query will match all documents which do _not_ match the `<blockMask>` query and are children (or descendents) of the documents matched by `<someParents>`.
 
@@ -74,7 +74,7 @@ We only get one document in response:
 
 [CAUTION]
 ====
-The query for `someParents` *MUST* match a strict subset of the documents matched by the <<#block-mask,Block Mask>> or your query may result in an Error:
+The query for `someParents` *MUST* match a strict subset of the documents matched by the <<block-mask,Block Mask>> or your query may result in an Error:
 
 [literal]
 Parent query must not match any docs besides parent filter.
@@ -114,7 +114,7 @@ This parser takes a query that matches child documents and returns their parents
 The syntax for this parser is similar to the `child` parser: `q={!parent which=<blockMask>}<someChildren>`.
 
 * The inner subordinate query string (`someChildren`) must be a query that will match some child documents
-* The `which` parameter must be a query string to use as a <<#block-mask,Block Mask>> -- typically a query that matches the set of all possible parent documents
+* The `which` parameter must be a query string to use as a <<block-mask,Block Mask>> -- typically a query that matches the set of all possible parent documents
 
 The resulting query will match all documents which _do_ match the `<blockMask>` query and are parents (or ancestors) of the documents matched by `<someChildren>`.
 
@@ -135,7 +135,7 @@ We get this document in response:
 
 [CAUTION]
 ====
-The query for `someChildren` *MUST NOT* match any documents matched by the <<#block-mask,Block Mask>> or your query may result in an Error:
+The query for `someChildren` *MUST NOT* match any documents matched by the <<block-mask,Block Mask>> or your query may result in an Error:
 
 [literal]
 Child query must not match same docs with parent filter.
@@ -210,4 +210,4 @@ A similar problematic situation can arise when mixing parent/child documents wit
 ...then our simple `doc_type:parent` Block Mask would no longer be adequate.
  We would instead need to use `\*:* -doc_type:child` or `doc_type:(simple parent)` to prevent our "simple" document from mistakenly being treated as a "child" of an adjacent "parent" document.
 
-The <<searching-nested-documents#searching-nested-documents,Searching Nested Documents>> section contains more detailed examples of specifing Block Mask queries with non trivial hierarchicies of documents.
+The xref:query-guide:searching-nested-documents[] section contains more detailed examples of specifying Block Mask queries with non trivial hierarchies of documents.
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/collapse-and-expand-results.adoc b/solr/solr-ref-guide/modules/query-guide/pages/collapse-and-expand-results.adoc
index bb55fd8..2d23b9d 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/collapse-and-expand-results.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/collapse-and-expand-results.adoc
@@ -107,7 +107,7 @@ The `top_fc` hint is only available when collapsing on String fields.
 `top_fc` will also result in having the collapsed field cached in memory twice if it's used for faceting or sorting.
 For very high cardinality (high distinct count) fields, `top_fc` may not fare so well.
 +
-* `block`: This indicates that the field being collapsed on is suitable for the optimzed <<#block-collapsing,Block Collapse>> logic described below.
+* `block`: This indicates that the field being collapsed on is suitable for the optimized <<Block Collapsing>> logic described below.
 
 `size`::
 +
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/common-query-parameters.adoc b/solr/solr-ref-guide/modules/query-guide/pages/common-query-parameters.adoc
index 1576a09..bbdd5c5 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/common-query-parameters.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/common-query-parameters.adoc
@@ -18,7 +18,7 @@
 
 Several query parsers share supported query parameters.
 
-The following sections describe Solr's common query parameters, which are supported by the <<requesthandlers-searchcomponents#search-handlers,Search RequestHandlers>>.
+The following sections describe Solr's common query parameters, which are supported by the xref:configuration-guide:requesthandlers-searchcomponents#search-handlers[search request handlers].
 
 == defType Parameter
 
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/dismax-query-parser.adoc b/solr/solr-ref-guide/modules/query-guide/pages/dismax-query-parser.adoc
index b0c03af..52d209b 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/dismax-query-parser.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/dismax-query-parser.adoc
@@ -198,7 +198,7 @@ q=cheese
 bf=div(1,sum(1,price))^1.5
 ----
 
-Specifying functions with the bf parameter is essentially just shorthand for using the `bq` parameter (<<#bq-bf-shortcomings,with the same shortcomings>>) combined with the `{!func}` parser -- with the addition of the simplified "query boost" syntax.
+Specifying functions with the bf parameter is essentially just shorthand for using the `bq` parameter (<<bq-bf-shortcomings,with the same shortcomings>>) combined with the `{!func}` parser -- with the addition of the simplified "query boost" syntax.
 
 For example, the two `bf` parameters listed below, are completely equivalent to the two `bq` parameters below:
 
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/document-transformers.adoc b/solr/solr-ref-guide/modules/query-guide/pages/document-transformers.adoc
index e4ab4b4..c1ddce4 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/document-transformers.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/document-transformers.adoc
@@ -137,7 +137,7 @@ Note that this transformer can be used even when the query used to match the res
 q=book_title:Solr&fl=id,[child childFilter=doc_type:chapter limit=100]
 ----
 
-If the documents involved include a `\_nest_path_` field, then it is used to re-create the hierarchical structure of the descendent documents using the original pseudo-field names the documents were indexed with, otherwise the descendent documents are returned as a flat list of <<indexing-nested-documents#indexing-anonymous-children,anonymous children>>.
+If the documents involved include a `\_nest_path_` field, then it is used to re-create the hierarchical structure of the descendent documents using the original pseudo-field names the documents were indexed with, otherwise the descendent documents are returned as a flat list of xref:indexing-guide:indexing-nested-documents#indexing-anonymous-children[anonymous children].
 
 `childFilter`::
 +
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/faceting.adoc b/solr/solr-ref-guide/modules/query-guide/pages/faceting.adoc
index fdfeac4..8c1cacf 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/faceting.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/faceting.adoc
@@ -140,7 +140,7 @@ There are two options for this parameter.
 For terms in the ASCII range, this will be alphabetically sorted.
 +
 The default is `count` if `facet.limit` is greater than 0, otherwise, the default is `index`.
-Note that the default logic is changed when <<#limiting-facet-with-certain-terms>>
+Note that the default logic is changed when <<Limiting Facet with Certain Terms>>.
 
 `facet.limit`::
 +
@@ -423,7 +423,7 @@ filter::: This method generates the ranges based on other facet.range parameters
 It will make use of the filterCache, so it will benefit of a cache large enough to contain all ranges.
 +
 dv::: This method iterates the documents that match the main query, and for each of them finds the correct range for the value.
-This method will make use of xref:docvalues.adoc[] (if enabled for the field) or fieldCache.
+This method will make use of xref:indexing-guide:docvalues.adoc[] (if enabled for the field) or fieldCache.
 The `dv` method is not supported for field type DateRangeField or when using xref:result-grouping.adoc[group.facets].
 --
 
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/function-queries.adoc b/solr/solr-ref-guide/modules/query-guide/pages/function-queries.adoc
index d679525..be91507 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/function-queries.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/function-queries.adoc
@@ -285,7 +285,7 @@ Use the `field(myfield,min)` <<field Function,syntax for selecting the minimum v
 Returns milliseconds of difference between its arguments.
 Dates are relative to the Unix or POSIX time epoch, midnight, January 1, 1970 UTC.
 
-Arguments may be the name of a `DatePointField`, `TrieDateField`, or date math based on a xref:date-formatting-math.adoc[constant date or `NOW`].
+Arguments may be the name of a `DatePointField`, `TrieDateField`, or date math based on a xref:indexing-guide:date-formatting-math.adoc[constant date or `NOW`].
 
 * `ms()`: Equivalent to `ms(NOW)`, number of milliseconds since the epoch.
 * `ms(a):` Returns the number of milliseconds since the epoch that the argument represents.
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/json-faceting-domain-changes.adoc b/solr/solr-ref-guide/modules/query-guide/pages/json-faceting-domain-changes.adoc
index d7e5049..6390db0 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/json-faceting-domain-changes.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/json-faceting-domain-changes.adoc
@@ -226,7 +226,7 @@ When a collection contains xref:indexing-guide:indexing-nested-documents.adoc[ne
 Both of these options work similarly to the corresponding xref:block-join-query-parser.adoc[] by taking in a single String query that exclusively matches all parent documents in the collection.
 If `blockParent` is used, then the resulting domain will contain all parent documents of the children from the original domain.
 If `blockChildren` is used, then the resulting domain will contain all child documents of the parents from the original domain.
-Quite often facets over child documents needs to be counted in parent documents, this can be done by `uniqueBlock(\_root_)` as described in <<json-facet-api#uniqueblock-and-block-join-counts, Block Join Facet Counts>>.
+Quite often facets over child documents needs to be counted in parent documents, this can be done by `uniqueBlock(\_root_)` as described in xref:json-facet-api.adoc#uniqueblock-and-block-join-counts[Block Join Facet Counts].
 
 [source,json,subs="verbatim,callouts"]]
 ----
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/math-expressions.adoc b/solr/solr-ref-guide/modules/query-guide/pages/math-expressions.adoc
index 512ed1a..d3030c5 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/math-expressions.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/math-expressions.adoc
@@ -1,5 +1,5 @@
 = Streaming Expressions and Math Expressions
-:toc!:
+:page-toclevels: 0
 // Licensed to the Apache Software Foundation (ASF) under one
 // or more contributor license agreements.  See the NOTICE file
 // distributed with this work for additional information
@@ -47,3 +47,4 @@ image::math-expressions/searchiris.png[]
 | *xref:graph.adoc[]*: Bipartite graphs, in-degree centrality, graph recommenders, temporal graphs and event correlation.
 | *xref:computational-geometry.adoc[]*: Convex Hulls and Enclosing Disks.
 | *xref:logs.adoc[]*: Solr log analytics and visualization.
+|===
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/searching-nested-documents.adoc b/solr/solr-ref-guide/modules/query-guide/pages/searching-nested-documents.adoc
index 6650402..c3ae864 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/searching-nested-documents.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/searching-nested-documents.adoc
@@ -1,4 +1,5 @@
 = Searching Nested Child Documents
+:page-partial:
 // Licensed to the Apache Software Foundation (ASF) under one
 // or more contributor license agreements.  See the NOTICE file
 // distributed with this work for additional information
@@ -23,13 +24,13 @@ Please refer to xref:indexing-guide:indexing-nested-documents.adoc[] for details
 
 [NOTE]
 This section does not demonstrate faceting on nested documents.
-For nested document faceting, please refer to the <<json-facet-api#uniqueblock-and-block-join-counts,Block Join Facet Counts>> section.
+For nested document faceting, please refer to the xref:json-facet-api.adoc#uniqueblock-and-block-join-counts[Block Join Facet Counts] section.
 
 == Query Examples
 
-For the upcoming examples, we'll assume an index containing the same documents covered in <<indexing-nested-documents#example-indexing-syntax,Indexing Nested Documents>>:
+For the upcoming examples, we'll assume an index containing the same documents covered in xref:indexing-guide:indexing-nested-documents.adoc#example-indexing-syntax[Indexing Nested Documents]:
 
-include::indexing-nested-documents.adoc[tag=sample-indexing-deeply-nested-documents]
+include::indexing-guide:page$indexing-nested-documents.adoc[tag=sample-indexing-deeply-nested-documents]
 
 === Child Doc Transformer
 
@@ -175,7 +176,7 @@ Note that in the above example, the `/` characters in the `\_nest_path_` were "d
 
 (You can see that only a single level of of `\` escaping is needed in the body of the query string -- to prevent the Regex syntax --  because it's not a quoted string local param).
 
-You may find it more convenient to use <<local-params#parameter-dereferencing,parameter references>> in conjunction with <<other-parsers#other-parsers,other parsers>> that do not treat `/` as a special character to express the same query in a more verbose form:
+You may find it more convenient to use xref:local-params.adoc#parameter-dereferencing[parameter references] in conjunction with xref:other-parsers[other parsers] that do not treat `/` as a special character to express the same query in a more verbose form:
 
 [source,text]
 ----
@@ -236,7 +237,7 @@ $ curl 'http://localhost:8983/solr/gettingstarted/select' -d 'omitHeader=true' -
   }}
 ----
 
-In this example we've used `\*:* -\_nest_path_:*` as our <<block-join-query-parser#block-mask,`which` parameter>> to indicate we want to consider all documents which don't have a nest path -- i.e., all "root" level document -- as the set of possible parents.
+In this example we've used `\*:* -\_nest_path_:*` as our xref:block-join-query-parser.adoc#block-mask[`which` parameter] to indicate we want to consider all documents which don't have a nest path -- i.e., all "root" level document -- as the set of possible parents.
 
 By changing the `which` parameter to match ancestors at specific `\_nest_path_` levels, we can change the type of ancestors we return.
 In the query below, we search for `skus` (using an `which` parameter that identifies all documents that do _not_ have a `\_nest_path_` with the prefix `/skus/*`) that are the ancestors of `manuals` with exactly `1` page:
@@ -261,7 +262,7 @@ $ curl 'http://localhost:8983/solr/gettingstarted/select' -d 'omitHeader=true' -
 
 [CAUTION]
 ====
-Note that in the above example, the `/` characters in the `\_nest_path_` were "double escaped" in the `which` parameter, for the <<#double-escaping-nest-path-slashes,same reasons discussed above>> regarding the `{!child} pasers `of` parameter.
+Note that in the above example, the `/` characters in the `\_nest_path_` were "double escaped" in the `which` parameter, for the <<double-escaping-nest-path-slashes,same reasons discussed above>> regarding the `{!child} pasers `of` parameter.
 ====
 
 === Combining Block Join Query Parsers with Child Doc Transformer
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/spell-checking.adoc b/solr/solr-ref-guide/modules/query-guide/pages/spell-checking.adoc
index 40b4c63..84b0194 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/spell-checking.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/spell-checking.adoc
@@ -173,7 +173,7 @@ The results are combined and collations can contain a mix of corrections from bo
 
 === Add It to a Request Handler
 
-Queries will be sent to a xref:configuration-guide:request-handlers-and-search-components.adoc[request handler].
+Queries will be sent to a xref:configuration-guide:requesthandlers-searchcomponents.adoc[request handler].
 If every request should generate a suggestion, then you would add the following to the `requestHandler` that you are using:
 
 [source,xml]
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/sql-query.adoc b/solr/solr-ref-guide/modules/query-guide/pages/sql-query.adoc
index 7a6ef1c..e6ec10f 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/sql-query.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/sql-query.adoc
@@ -356,7 +356,7 @@ By default, the `/sql` request handler is configured as an implicit handler, mea
 
 ==== Authorization for SQL Requests
 
-If your Solr cluster is configured to use the xref:rule-based-authorization-plugin.adoc[],
+If your Solr cluster is configured to use the xref:deployment-guide:rule-based-authorization-plugin.adoc[],
 then you need to grant `GET` and `POST` permissions on the `/sql`, `/select`, and `/export` endpoints for all collections you intend to execute SQL queries against.
 The `/select` endpoint is used for `LIMIT` queries, whereas the `/export` handler is used for queries without a `LIMIT`, so in most cases, you'll want to grant access to both.
 If you're using a worker collection for the `/sql` handler, then you only need to grant access to the `/sql` endpoint for the worker collection and not the collections in the data tier.
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/standard-query-parser.adoc b/solr/solr-ref-guide/modules/query-guide/pages/standard-query-parser.adoc
index 8aac0d2..fe9bb92 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/standard-query-parser.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/standard-query-parser.adoc
@@ -200,7 +200,7 @@ The brackets around a query determine its inclusiveness.
 Here's an example: `count:{1 TO 10]`
 
 Wildcards, `*`, can also be used for either or both endpoints to specify an open-ended range query.
-This is a <<#differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser,divergence from Lucene's Classic Query Parser>>.
+This is a <<differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser,divergence from Lucene's Classic Query Parser>>.
 
 * `field:[* TO 100]` finds all field values less than or equal to 100.
 * `field:[100 TO *]` finds all field values greater than or equal to 100.
@@ -253,7 +253,7 @@ Example:
 
 == Querying Specific Fields
 
-Data indexed in Solr is organized in xref:indexing-guide:fields.adoc[fields], which are defined in xref:indexing-guide:schema-element.adoc[a schema].
+Data indexed in Solr is organized in xref:indexing-guide:fields.adoc[fields], which are defined in xref:indexing-guide:schema-elements.adoc[a schema].
 Searches can take advantage of fields to add precision to queries.
 For example, you can search for a term only in a specific field, such as a title field.
 
diff --git a/solr/solr-ref-guide/modules/query-guide/pages/stream-decorator-reference.adoc b/solr/solr-ref-guide/modules/query-guide/pages/stream-decorator-reference.adoc
index 322c754..7774a35 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/stream-decorator-reference.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/stream-decorator-reference.adoc
@@ -632,7 +632,7 @@ daemonStream.close();
 
 The `delete` function wraps other functions and uses the `id` and `\_version_` values found to send the tuples to a SolrCloud collection as xref:indexing-guide:indexing-with-update-handlers.adoc#delete-operations[Delete By Id] commands.
 
-This is similar to the `<<#update,update()>>` function described below.
+This is similar to the `<<update,update()>>` function described below.
 
 === delete Parameters
 
diff --git a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-6.adoc b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-6.adoc
index 04fced2..ace04dd 100644
--- a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-6.adoc
+++ b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-6.adoc
@@ -18,7 +18,8 @@
 
 There are some major changes in Solr 6 to consider before starting to migrate your configurations and indexes.
 
-There are many hundreds of changes, so a thorough review of the <<solr-upgrade-notes.adoc#,Solr Upgrade Notes>> section as well as the {solr-javadocs}/changes//Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 6. This section attempts to highlight some of the major changes you should be aware of.
+There are many hundreds of changes, so a thorough review of the xref:solr-upgrade-notes.adoc[] section as well as the {solr-javadocs}/changes//Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 6.
+This section attempts to highlight some of the major changes you should be aware of.
 
 == Highlights of New Features in Solr 6
 
@@ -27,7 +28,7 @@ Some of the major improvements in Solr 6 include:
 [[major-5-6-streaming]]
 === Streaming Expressions
 
-Introduced in Solr 5, <<streaming-expressions.adoc#,Streaming Expressions>> allow querying Solr and getting results as a stream of data, sorted and aggregated as requested.
+Introduced in Solr 5, xref:query-guide:streaming-expressions.adoc[] allow querying Solr and getting results as a stream of data, sorted and aggregated as requested.
 
 Several new expression types have been added in Solr 6:
 
@@ -40,7 +41,8 @@ Several new expression types have been added in Solr 6:
 [[major-5-6-parallel-sql]]
 === SQL Query
 
-Built on streaming expressions, new in Solr 6 is a <<sql-query.adoc#,SQL support>> to be able to send SQL queries to Solr. SQL statements are compiled to streaming expressions on the fly, providing the full range of aggregations available to streaming expression requests. A JDBC driver is included, which allows using SQL clients and database visualization tools to query your Solr index and import data to other systems.
+Built on streaming expressions, new in Solr 6 is a xref:query-guide:sql-query.adoc[SQL support] to be able to send SQL queries to Solr. SQL statements are compiled to streaming expressions on the fly, providing the full range of aggregations available to streaming expression requests.
+A JDBC driver is included, which allows using SQL clients and database visualization tools to query your Solr index and import data to other systems.
 
 
 === Cross Data Center Replication
@@ -49,42 +51,52 @@ Replication across data centers is now possible with Cross Data Center Replicati
 
 === Graph QueryParser
 
-A new <<other-parsers.adoc#graph-query-parser,`graph` query parser>> makes it possible to to graph traversal queries of Directed (Cyclic) Graphs modelled using Solr documents.
+A new xref:query-guide:other-parsers.adoc#graph-query-parser[`graph` query parser] makes it possible to to graph traversal queries of Directed (Cyclic) Graphs modelled using Solr documents.
 
 [[major-5-6-docvalues]]
 === DocValues
 
-Most non-text field types in the Solr sample configsets now default to using <<docvalues.adoc#,DocValues>>.
+Most non-text field types in the Solr sample configsets now default to using xref:indexing-guide:docvalues.adoc[].
 
 == Java 8 Required
 
-The minimum supported version of Java for Solr 6 (and the <<solrj.adoc#,SolrJ client libraries>>) is now Java 8.
+The minimum supported version of Java for Solr 6 (and the xref:deployment-guide:solrj.adoc[SolrJ client libraries]) is now Java 8.
 
 == Index Format Changes
 
-Solr 6 has no support for reading Lucene/Solr 4.x and earlier indexes. Be sure to run the Lucene `IndexUpgrader` included with Solr 5.5 if you might still have old 4x formatted segments in your index. Alternatively: fully optimize your index with Solr 5.5 to make sure it consists only of one up-to-date index segment.
+Solr 6 has no support for reading Lucene/Solr 4.x and earlier indexes.
+Be sure to run the Lucene `IndexUpgrader` included with Solr 5.5 if you might still have old 4x formatted segments in your index.
+Alternatively: fully optimize your index with Solr 5.5 to make sure it consists only of one up-to-date index segment.
 
 == Managed Schema is now the Default
 
-Solr's default behavior when a `solrconfig.xml` does not explicitly define a `<schemaFactory/>` is now dependent on the `luceneMatchVersion` specified in that `solrconfig.xml`. When `luceneMatchVersion < 6.0`, `ClassicIndexSchemaFactory` will continue to be used for back compatibility, otherwise an instance of <<schema-factory.adoc#,`ManagedIndexSchemaFactory`>> will be used.
+Solr's default behavior when a `solrconfig.xml` does not explicitly define a `<schemaFactory/>` is now dependent on the `luceneMatchVersion` specified in that `solrconfig.xml`.
+When `luceneMatchVersion < 6.0`, `ClassicIndexSchemaFactory` will continue to be used for back compatibility, otherwise an instance of xref:configuration-guide:schema-factory.adoc[`ManagedIndexSchemaFactory`] will be used.
 
 The most notable impacts of this change are:
 
 * Existing `solrconfig.xml` files that are modified to use `luceneMatchVersion >= 6.0`, but do _not_ have an explicitly configured `ClassicIndexSchemaFactory`, will have their `schema.xml` file automatically upgraded to a `managed-schema` file.
-* Schema modifications via the <<schema-api.adoc#,Schema API>> will now be enabled by default.
+* Schema modifications via the xref:indexing-guide:schema-api.adoc[] will now be enabled by default.
 
-Please review the <<schema-factory.adoc#,Schema Factory Definition in SolrConfig>> section for more details.
+Please review the xref:configuration-guide:schema-factory.adoc[] section for more details.
 
 == Default Similarity Changes
 
-Solr's default behavior when a Schema does not explicitly define a global <<schema-elements.adoc#similarity,`<similarity/>`>> is now dependent on the `luceneMatchVersion` specified in the `solrconfig.xml`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarityFactory` will be used, otherwise an instance of `SchemaSimilarityFactory` will be used. Most notably this change means that users can take advantage of per Field Type similarity declarations, without needing to also expl [...]
+Solr's default behavior when a Schema does not explicitly define a global xref:indexing-guide:schema-elements.adoc#similarity[`<similarity/>`] is now dependent on the `luceneMatchVersion` specified in the `solrconfig.xml`.
+When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarityFactory` will be used, otherwise an instance of `SchemaSimilarityFactory` will be used.
+Most notably this change means that users can take advantage of per Field Type similarity declarations, without needing to also explicitly declare a global usage of `SchemaSimilarityFactory`.
 
-Regardless of whether it is explicitly declared, or used as an implicit global default, `SchemaSimilarityFactory` 's implicit behavior when a Field Types do not declare an explicit `<similarity />` has also been changed to depend on the `luceneMatchVersion`. When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarity` will be used, otherwise an instance of `BM25Similarity` will be used. A `defaultSimFromFieldType` init option may be specified on the `SchemaSimilarityFactory` decla [...]
+Regardless of whether it is explicitly declared, or used as an implicit global default, `SchemaSimilarityFactory` 's implicit behavior when a Field Types do not declare an explicit `<similarity />` has also been changed to depend on the `luceneMatchVersion`.
+When `luceneMatchVersion < 6.0`, an instance of `ClassicSimilarity` will be used, otherwise an instance of `BM25Similarity` will be used.
+A `defaultSimFromFieldType` init option may be specified on the `SchemaSimilarityFactory` declaration to change this behavior.
+Please review the `SchemaSimilarityFactory` javadocs for more details.
 
 == Replica & Shard Delete Command Changes
 
-DELETESHARD and DELETEREPLICA now default to deleting the instance directory, data directory, and index directory for any replica they delete. Please review the <<collections-api.adoc#,Collection API>> documentation for details on new request parameters to prevent this behavior if you wish to keep all data on disk when using these commands.
+DELETESHARD and DELETEREPLICA now default to deleting the instance directory, data directory, and index directory for any replica they delete.
+Please review the xref:configuration-guide:collections-api.adoc[] documentation for details on new request parameters to prevent this behavior if you wish to keep all data on disk when using these commands.
 
 == facet.date.* Parameters Removed
 
-The `facet.date` parameter (and associated `facet.date.*` parameters) that were deprecated in Solr 3.x have been removed completely. If you have not yet switched to using the equivalent <<faceting.adoc#,`facet.range`>> functionality you must do so now before upgrading.
+The `facet.date` parameter (and associated `facet.date.*` parameters) that were deprecated in Solr 3.x have been removed completely.
+If you have not yet switched to using the equivalent xref:query-guide:faceting.adoc[`facet.range`] functionality you must do so now before upgrading.
diff --git a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-7.adoc b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-7.adoc
index 9d4dfe3..4293deb 100644
--- a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-7.adoc
+++ b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-7.adoc
@@ -19,28 +19,40 @@
 Solr 7 is a major new release of Solr which introduces new features and a number of other changes that may impact your existing installation.
 
 == Upgrade Planning
-There are major changes in Solr 7 to consider before starting to migrate your configurations and indexes. This page is designed to highlight the biggest changes - new features you may want to be aware of, but also changes in default behavior and deprecated features that have been removed.
+There are major changes in Solr 7 to consider before starting to migrate your configurations and indexes.
+This page is designed to highlight the biggest changes - new features you may want to be aware of, but also changes in default behavior and deprecated features that have been removed.
 
-There are many hundreds of changes in Solr 7, however, so a thorough review of the <<solr-upgrade-notes.adoc#,Solr Upgrade Notes>> as well as the {solr-javadocs}/changes//Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 7. This section attempts to highlight some of the major changes you should be aware of.
+There are many hundreds of changes in Solr 7, however, so a thorough review of the xref:solr-upgrade-notes.adoc[] as well as the {solr-javadocs}/changes//Changes.html[CHANGES.txt] file in your Solr instance will help you plan your migration to Solr 7.
+This section attempts to highlight some of the major changes you should be aware of.
 
-You should also consider all changes that have been made to Solr in any version you have not upgraded to already. For example, if you are currently using Solr 6.2, you should review changes made in all subsequent 6.x releases in addition to changes for 7.0.
+You should also consider all changes that have been made to Solr in any version you have not upgraded to already.
+For example, if you are currently using Solr 6.2, you should review changes made in all subsequent 6.x releases in addition to changes for 7.0.
 
-<<reindexing.adoc#upgrades,Reindexing>> your data is considered the best practice and you should try to do so if possible. However, if reindexing is not feasible, keep in mind you can only upgrade one major version at a time. Thus, Solr 6.x indexes will be compatible with Solr 7 but Solr 5.x indexes will not be.
+xref:indexing-guide:reindexing.adoc#upgrades[Reindexing] your data is considered the best practice and you should try to do so if possible.
+However, if reindexing is not feasible, keep in mind you can only upgrade one major version at a time.
+Thus, Solr 6.x indexes will be compatible with Solr 7 but Solr 5.x indexes will not be.
 
-If you do not reindex now, keep in mind that you will need to either reindex your data or upgrade your indexes before you will be able to move to Solr 8 when it is released in the future. See the section <<indexupgrader-tool.adoc#,IndexUpgrader Tool>> for more details on how to upgrade your indexes.
+If you do not reindex now, keep in mind that you will need to either reindex your data or upgrade your indexes before you will be able to move to Solr 8 when it is released in the future.
+See the section xref:deployment-guide:indexupgrader-tool.adoc[] for more details on how to upgrade your indexes.
 
-See also the section <<upgrading-a-solr-cluster.adoc#,Upgrading a Solr Cluster>> for details on how to upgrade a SolrCloud cluster.
+See also the section xref:deployment-guide:upgrading-a-solr-cluster.adoc[] for details on how to upgrade a SolrCloud cluster.
 
 == New Features & Enhancements
 
 === Replication Modes
-Until Solr 7, the SolrCloud model for replicas has been to allow any replica to become a leader when a leader is lost. This is highly effective for most users, providing reliable failover in case of issues in the cluster. However, it comes at a cost in large clusters because all replicas must be in sync at all times.
+Until Solr 7, the SolrCloud model for replicas has been to allow any replica to become a leader when a leader is lost.
+This is highly effective for most users, providing reliable failover in case of issues in the cluster.
+However, it comes at a cost in large clusters because all replicas must be in sync at all times.
 
-To provide additional flexibility, two new types of replicas have been added, named TLOG & PULL. These new types provide options to have replicas which only sync with the leader by copying index segments from the leader. The TLOG type has an additional benefit of maintaining a transaction log (the "tlog" of its name), which would allow it to recover and become a leader if necessary; the PULL type does not maintain a transaction log, so cannot become a leader.
+To provide additional flexibility, two new types of replicas have been added, named TLOG & PULL.
+These new types provide options to have replicas which only sync with the leader by copying index segments from the leader.
+The TLOG type has an additional benefit of maintaining a transaction log (the "tlog" of its name), which would allow it to recover and become a leader if necessary; the PULL type does not maintain a transaction log, so cannot become a leader.
 
-As part of this change, the traditional type of replica is now named NRT. If you do not explicitly define a number of TLOG or PULL replicas, Solr defaults to creating NRT replicas. If this model is working for you, you will not have to change anything.
+As part of this change, the traditional type of replica is now named NRT.
+If you do not explicitly define a number of TLOG or PULL replicas, Solr defaults to creating NRT replicas.
+If this model is working for you, you will not have to change anything.
 
-See the section <<solrcloud-shards-indexing.adoc#types-of-replicas,Types of Replicas>> for more details on the new replica modes, and how define the replica type in your cluster.
+See the section xref:deployment-guide:solrcloud-shards-indexing.adoc#types-of-replicas[Types of Replicas] for more details on the new replica modes, and how define the replica type in your cluster.
 
 === Autoscaling
 Solr autoscaling is a new suite of features in Solr to make managing a SolrCloud cluster easier and more automated.
@@ -49,23 +61,25 @@ At its core, Solr autoscaling provides users with a rule syntax to define prefer
 
 === Other Features & Enhancements
 
-* The <<analytics.adoc#,Analytics Component>> has been refactored.
+* The xref:query-guide:analytics.adoc[] has been refactored.
 
 * There were several other new features released in earlier 6.x releases, which you may have missed:
-** <<learning-to-rank.adoc#,Learning to Rank>>
-** <<highlighting.adoc#unified-highlighter,Unified Highlighter>>
-** <<metrics-reporting.adoc#,Metrics API>>. See also information about related deprecations in the section <<JMX Support and MBeans>> below.
-** <<other-parsers.adoc#payload-query-parsers,Payload queries>>
-** <<stream-evaluator-reference.adoc#,Streaming Evaluators>>
-** <<v2-api.adoc#,/v2 API>>
-** <<graph-traversal.adoc#,Graph streaming expressions>>
+** xref:query-guide:learning-to-rank.adoc[]
+** xref:query-guide:highlighting.adoc#unified-highlighter[Unified Highlighter]
+** xref:deployment-guide:metrics-reporting.adoc[Metrics API].
+See also information about related deprecations in the section <<JMX Support and MBeans>> below.
+** xref:query-guide:other-parsers.adoc#payload-query-parsers[Payload queries]
+** xref:query-guide:stream-evaluator-reference.adoc[Streaming Evaluators]
+** xref:configuration-guide:v2-api.adoc[v2 API]
+** xref:query-guide:graph-traversal.adoc[Graph streaming expressions]
 
 == Configuration and Default Changes
 
 === New Default Configset
 Several changes have been made to configsets that ship with Solr; not only their content but how Solr behaves in regard to them:
 
-* The `data_driven_configset` and `basic_configset` have been removed, and replaced by the `_default` configset. The `sample_techproducts_configset` also remains, and is designed for use with the example documents shipped with Solr in the `example/exampledocs` directory.
+* The `data_driven_configset` and `basic_configset` have been removed, and replaced by the `_default` configset.
+The `sample_techproducts_configset` also remains, and is designed for use with the example documents shipped with Solr in the `example/exampledocs` directory.
 * When creating a new collection, if you do not specify a configset, the `_default` will be used.
 ** If you use SolrCloud, the `_default` configset will be automatically uploaded to ZooKeeper.
 ** If you run a user-managed cluster or a single-node installation, the instanceDir will be created automatically, using the `_default` configset as its basis.
@@ -74,14 +88,20 @@ Several changes have been made to configsets that ship with Solr; not only their
 
 To improve the functionality of Schemaless Mode, Solr now behaves differently when it detects that data in an incoming field should have a text-based field type.
 
-* Incoming fields will be indexed as `text_general` by default (you can change this). The name of the field will be the same as the field name defined in the document.
-* A copy field rule will be inserted into your schema to copy the new `text_general` field to a new field with the name `<name>_str`. This field's type will be a `strings` field (to allow for multiple values). The first 256 characters of the text field will be inserted to the new `strings` field.
+* Incoming fields will be indexed as `text_general` by default (you can change this).
+The name of the field will be the same as the field name defined in the document.
+* A copy field rule will be inserted into your schema to copy the new `text_general` field to a new field with the name `<name>_str`.
+This field's type will be a `strings` field (to allow for multiple values).
+The first 256 characters of the text field will be inserted to the new `strings` field.
 
-This behavior can be customized if you wish to remove the copy field rule, or to change the number of characters inserted to the string field, or the field type used. See the section <<schemaless-mode.adoc#,Schemaless Mode>> for details.
+This behavior can be customized if you wish to remove the copy field rule, or to change the number of characters inserted to the string field, or the field type used.
+See the section xref:indexing-guide:schemaless-mode.adoc[] for details.
 
-TIP: Because copy field rules can slow indexing and increase index size, it's recommended you only use copy fields when you need to. If you do not need to sort or facet on a field, you should remove the automatically-generated copy field rule.
+TIP: Because copy field rules can slow indexing and increase index size, it's recommended you only use copy fields when you need to.
+If you do not need to sort or facet on a field, you should remove the automatically-generated copy field rule.
 
-Automatic field creation can be disabled with the `update.autoCreateFields` property. To do this, you can use the Config API with a command such as:
+Automatic field creation can be disabled with the `update.autoCreateFields` property.
+To do this, you can use the Config API with a command such as:
 
 [.dynamic-tabs]
 --
@@ -105,28 +125,40 @@ curl http://host:8983/api/collections/mycollection/config -d '{"set-user-propert
 --
 
 === Changes to Default Behaviors
-* JSON is now the default response format. If you rely on XML responses, you must now define `wt=xml` in your request. In addition, line indentation is enabled by default (`indent=on`).
-* The `sow` parameter (short for "Split on Whitespace") now defaults to `false`, which allows support for multi-word synonyms out of the box. This parameter is used with the eDisMax and standard/"lucene" query parsers. If this parameter is not explicitly specified as `true`, query text will not be split on whitespace before analysis.
-* The `legacyCloud` parameter now defaults to `false`. If an entry for a replica does not exist in `state.json`, that replica will not get registered.
+* JSON is now the default response format.
+If you rely on XML responses, you must now define `wt=xml` in your request.
+In addition, line indentation is enabled by default (`indent=on`).
+* The `sow` parameter (short for "Split on Whitespace") now defaults to `false`, which allows support for multi-word synonyms out of the box.
+This parameter is used with the eDisMax and standard/"lucene" query parsers.
+If this parameter is not explicitly specified as `true`, query text will not be split on whitespace before analysis.
+* The `legacyCloud` parameter now defaults to `false`.
+If an entry for a replica does not exist in `state.json`, that replica will not get registered.
 +
-This may affect users who bring up replicas and they are automatically registered as a part of a shard. It is possible to fall back to the old behavior by setting the property `legacyCloud=true`, in the cluster properties using the following command:
+This may affect users who bring up replicas and they are automatically registered as a part of a shard.
+It is possible to fall back to the old behavior by setting the property `legacyCloud=true`, in the cluster properties using the following command:
 +
 `./server/scripts/cloud-scripts/zkcli.sh -zkhost 127.0.0.1:2181  -cmd clusterprop -name legacyCloud -val true`
-* The eDisMax query parser parameter `lowercaseOperators` now defaults to `false` if the `luceneMatchVersion` in `solrconfig.xml` is 7.0.0 or above. Behavior for `luceneMatchVersion` lower than 7.0.0 is unchanged (so, `true`). This means that clients must sent boolean operators (such as AND, OR and NOT) in upper case in order to be recognized, or you must explicitly set this parameter to `true`.
-* The `handleSelect` parameter in `solrconfig.xml` now defaults to `false` if the `luceneMatchVersion` is 7.0.0 or above. This causes Solr to ignore the `qt` parameter if it is present in a request. If you have request handlers without a leading '/', you can set `handleSelect="true"` or consider migrating your configuration.
+* The eDisMax query parser parameter `lowercaseOperators` now defaults to `false` if the `luceneMatchVersion` in `solrconfig.xml` is 7.0.0 or above.
+Behavior for `luceneMatchVersion` lower than 7.0.0 is unchanged (so, `true`).
+This means that clients must sent boolean operators (such as AND, OR and NOT) in upper case in order to be recognized, or you must explicitly set this parameter to `true`.
+* The `handleSelect` parameter in `solrconfig.xml` now defaults to `false` if the `luceneMatchVersion` is 7.0.0 or above.
+This causes Solr to ignore the `qt` parameter if it is present in a request.
+If you have request handlers without a leading '/', you can set `handleSelect="true"` or consider migrating your configuration.
 +
 The `qt` parameter is still used as a SolrJ special parameter that specifies the request handler (tail URL path) to use.
-* The `lucenePlusSort` query parser (aka the "Old Lucene Query Parser") has been deprecated and is no longer implicitly defined. If you wish to continue using this parser until Solr 8 (when it will be removed), you must register it in your `solrconfig.xml`, as in: `<queryParser name="lucenePlusSort" class="solr.OldLuceneQParserPlugin"/>`.
+* The `lucenePlusSort` query parser (aka the "Old Lucene Query Parser") has been deprecated and is no longer implicitly defined.
+If you wish to continue using this parser until Solr 8 (when it will be removed), you must register it in your `solrconfig.xml`, as in: `<queryParser name="lucenePlusSort" class="solr.OldLuceneQParserPlugin"/>`.
 * The name of `TemplateUpdateRequestProcessorFactory` is changed to `template` from `Template` and the name of `AtomicUpdateProcessorFactory` is changed to `atomic` from `Atomic`
 ** Also, `TemplateUpdateRequestProcessorFactory` now uses `{}` instead of `${}` for `template`.
 
-
 == Deprecations and Removed Features
 
 === Point Fields Are Default Numeric Types
-Solr has implemented \*PointField types across the board, to replace Trie* based numeric fields. All Trie* fields are now considered deprecated, and will be removed in Solr 8.
+Solr has implemented \*PointField types across the board, to replace Trie* based numeric fields.
+All Trie* fields are now considered deprecated, and will be removed in Solr 8.
 
-If you are using Trie* fields in your schema, you should consider moving to PointFields as soon as feasible. Changing to the new PointField types will require you to reindex your data.
+If you are using Trie* fields in your schema, you should consider moving to PointFields as soon as feasible.
+Changing to the new PointField types will require you to reindex your data.
 
 === Spatial Fields
 
@@ -143,50 +175,70 @@ Choose one of these field types instead:
 * `SpatialRecursivePrefixTreeField`
 * `RptWithGeometrySpatialField`
 
-See the section <<spatial-search.adoc#,Spatial Search>> for more information.
+See the section xref:query-guide:spatial-search.adoc[] for more information.
 
 === JMX Support and MBeans
 * The `<jmx>` element in `solrconfig.xml` has been removed in favor of `<metrics><reporter>` elements defined in `solr.xml`.
 +
-Limited back-compatibility is offered by automatically adding a default instance of `SolrJmxReporter` if it's missing AND when a local MBean server is found. A local MBean server can be activated either via `ENABLE_REMOTE_JMX_OPTS` in `solr.in.sh` or via system properties, e.g., `-Dcom.sun.management.jmxremote`. This default instance exports all Solr metrics from all registries as hierarchical MBeans.
+Limited back-compatibility is offered by automatically adding a default instance of `SolrJmxReporter` if it's missing AND when a local MBean server is found.
+A local MBean server can be activated either via `ENABLE_REMOTE_JMX_OPTS` in `solr.in.sh` or via system properties, e.g., `-Dcom.sun.management.jmxremote`.
+This default instance exports all Solr metrics from all registries as hierarchical MBeans.
 +
-This behavior can be also disabled by specifying a `SolrJmxReporter` configuration with a boolean init argument `enabled` set to `false`. For a more fine-grained control users should explicitly specify at least one `SolrJmxReporter` configuration.
+This behavior can be also disabled by specifying a `SolrJmxReporter` configuration with a boolean init argument `enabled` set to `false`.
+For a more fine-grained control users should explicitly specify at least one `SolrJmxReporter` configuration.
 +
-See also the section <<metrics-reporting.adoc#the-metrics-reporters-element,The <metrics><reporters> Element>>, which describes how to set up Metrics Reporters in `solr.xml`. Note that back-compatibility support may be removed in Solr 8.
+See also the section xref:deployment-guide:metrics-reporting.adoc#the-metrics-reporters-element[The <metrics><reporters> Element], which describes how to set up Metrics Reporters in `solr.xml`.
+Note that back-compatibility support may be removed in Solr 8.
 
-* MBean names and attributes now follow the hierarchical names used in metrics. This is reflected also in `/admin/mbeans` and `/admin/plugins` output, and can be observed in the UI Plugins tab, because now all these APIs get their data from the metrics API. The old (mostly flat) JMX view has been removed.
+* MBean names and attributes now follow the hierarchical names used in metrics. This is reflected also in `/admin/mbeans` and `/admin/plugins` output, and can be observed in the UI Plugins tab, because now all these APIs get their data from the metrics API.
+The old (mostly flat) JMX view has been removed.
 
 === SolrJ
 The following changes were made in SolrJ.
 
 * `HttpClientInterceptorPlugin` is now `HttpClientBuilderPlugin` and must work with a `SolrHttpClientBuilder` rather than an `HttpClientConfigurer`.
-* `HttpClientUtil` now allows configuring `HttpClient` instances via `SolrHttpClientBuilder` rather than an `HttpClientConfigurer`. Use of env variable `SOLR_AUTHENTICATION_CLIENT_CONFIGURER` no longer works, please use `SOLR_AUTHENTICATION_CLIENT_BUILDER`
-* `SolrClient` implementations now use their own internal configuration for socket timeouts, connect timeouts, and allowing redirects rather than what is set as the default when building the `HttpClient` instance. Use the appropriate setters on the `SolrClient` instance.
+* `HttpClientUtil` now allows configuring `HttpClient` instances via `SolrHttpClientBuilder` rather than an `HttpClientConfigurer`.
+Use of env variable `SOLR_AUTHENTICATION_CLIENT_CONFIGURER` no longer works, please use `SOLR_AUTHENTICATION_CLIENT_BUILDER`
+* `SolrClient` implementations now use their own internal configuration for socket timeouts, connect timeouts, and allowing redirects rather than what is set as the default when building the `HttpClient` instance.
+Use the appropriate setters on the `SolrClient` instance.
 * `HttpSolrClient#setAllowCompression` has been removed and compression must be enabled as a constructor parameter.
-* `HttpSolrClient#setDefaultMaxConnectionsPerHost` and `HttpSolrClient#setMaxTotalConnections` have been removed. These now default very high and can only be changed via parameter when creating an HttpClient instance.
+* `HttpSolrClient#setDefaultMaxConnectionsPerHost` and `HttpSolrClient#setMaxTotalConnections` have been removed.
+These now default very high and can only be changed via parameter when creating an HttpClient instance.
 
 === Other Deprecations and Removals
-* The `defaultOperator` parameter in the schema is no longer supported. Use the `q.op` parameter instead. This option had been deprecated for several releases. See the section <<standard-query-parser.adoc#standard-query-parser-parameters,Standard Query Parser Parameters>> for more information.
-* The `defaultSearchField` parameter in the schema is no longer supported. Use the `df` parameter instead. This option had been deprecated for several releases. See the section <<standard-query-parser.adoc#standard-query-parser-parameters,Standard Query Parser Parameters>> for more information.
-* The `mergePolicy`, `mergeFactor` and `maxMergeDocs` parameters have been removed and are no longer supported. You should define a `mergePolicyFactory` instead. See the section <<index-segments-merging.adoc#mergepolicyfactory,the mergePolicyFactory>> for more information.
-* The PostingsSolrHighlighter has been deprecated. It's recommended that you move to using the UnifiedHighlighter instead. See the section <<highlighting.adoc#unified-highlighter,Unified Highlighter>> for more information about this highlighter.
-* Index-time boosts have been removed from Lucene, and are no longer available from Solr. If any boosts are provided, they will be ignored by the indexing chain. As a replacement, index-time scoring factors should be indexed in a separate field and combined with the query score using a function query. See the section <<function-queries.adoc#,Function Queries>> for more information.
-* The `StandardRequestHandler` is deprecated. Use `SearchHandler` instead.
-* To improve parameter consistency in the Collections API, the parameter names `fromNode` for the MOVEREPLICA command and `source`, `target` for the REPLACENODE command have been deprecated and replaced with `sourceNode` and `targetNode` instead. The old names will continue to work for back-compatibility but they will be removed in Solr 8.
+* The `defaultOperator` parameter in the schema is no longer supported. Use the `q.op` parameter instead. This option had been deprecated for several releases. See the section xref:query-guide:standard-query-parser.adoc#standard-query-parser-parameters[Standard Query Parser Parameters] for more information.
+* The `defaultSearchField` parameter in the schema is no longer supported.
+Use the `df` parameter instead. This option had been deprecated for several releases.
+See the section xref:query-guide:standard-query-parser.adoc#standard-query-parser-parameters[Standard Query Parser Parameters] for more information.
+* The `mergePolicy`, `mergeFactor` and `maxMergeDocs` parameters have been removed and are no longer supported.
+You should define a `mergePolicyFactory` instead. See the section xref:configuration-guide:index-segments-merging.adoc#mergepolicyfactory[mergePolicyFactory] for more information.
+* The PostingsSolrHighlighter has been deprecated. It's recommended that you move to using the UnifiedHighlighter instead.
+See the section xref:query-guide:highlighting.adoc#unified-highlighter[Unified Highlighter] for more information about this highlighter.
+* Index-time boosts have been removed from Lucene, and are no longer available from Solr.
+If any boosts are provided, they will be ignored by the indexing chain.
+As a replacement, index-time scoring factors should be indexed in a separate field and combined with the query score using a function query.
+See the section xref:query-guide:function-queries.adoc[] for more information.
+* The `StandardRequestHandler` is deprecated.
+Use `SearchHandler` instead.
+* To improve parameter consistency in the Collections API, the parameter names `fromNode` for the MOVEREPLICA command and `source`, `target` for the REPLACENODE command have been deprecated and replaced with `sourceNode` and `targetNode` instead.
+The old names will continue to work for back-compatibility but they will be removed in Solr 8.
 * The unused `valType` option has been removed from ExternalFileField, if you have this in your schema you can safely remove it.
 
 == Major Changes in Earlier 6.x Versions
-The following summary of changes in earlier 6.x releases highlights significant changes released between Solr 6.0 and 6.6 that were listed in earlier versions of this Guide. Mentions of deprecations are likely superseded by removal in Solr 7, as noted in the above sections.
+The following summary of changes in earlier 6.x releases highlights significant changes released between Solr 6.0 and 6.6 that were listed in earlier versions of this Guide.
+Mentions of deprecations are likely superseded by removal in Solr 7, as noted in the above sections.
 
 Note again that this is not a complete list of all changes that may impact your installation, so a thorough review of CHANGES.txt is highly recommended if upgrading from any version earlier than 6.6.
 
 * The Solr contribs map-reduce, morphlines-core and morphlines-cell have been removed.
 * JSON Facet API now uses hyper-log-log for numBuckets cardinality calculation and calculates cardinality before filtering buckets by any `mincount` greater than 1.
 * If you use historical dates, specifically on or before the year 1582, you should reindex for better date handling.
-* If you use the JSON Facet API (json.facet) with `method=stream`, you must now set `sort='index asc'` to get the streaming behavior; otherwise it won't stream. Reminder: `method` is a hint that doesn't change defaults of other parameters.
+* If you use the JSON Facet API (json.facet) with `method=stream`, you must now set `sort='index asc'` to get the streaming behavior; otherwise it won't stream.
+Reminder: `method` is a hint that doesn't change defaults of other parameters.
 * If you use the JSON Facet API (json.facet) to facet on a numeric field and if you use `mincount=0` or if you set the prefix, you will now get an error as these options are incompatible with numeric faceting.
 * Solr's logging verbosity at the INFO level has been greatly reduced, and you may need to update the log configs to use the DEBUG level to see all the logging messages you used to see at INFO level before.
-* We are no longer backing up `solr.log` and `solr_gc.log` files in date-stamped copies forever. If you relied on the `solr_log_<date>` or `solr_gc_log_<date>` being in the logs folder that will no longer be the case. See the section <<configuring-logging.adoc#,Configuring Logging>> for details on how log rotation works as of Solr 6.3.
+* We are no longer backing up `solr.log` and `solr_gc.log` files in date-stamped copies forever. If you relied on the `solr_log_<date>` or `solr_gc_log_<date>` being in the logs folder that will no longer be the case.
+See the section xref:deployment-guide:configuring-logging.adoc[] for details on how log rotation works as of Solr 6.3.
 * The create/deleteCollection methods on `MiniSolrCloudCluster` have been deprecated. Clients should instead use the `CollectionAdminRequest` API. In addition, `MiniSolrCloudCluster#uploadConfigDir(File, String)` has been deprecated in favour of `#uploadConfigSet(Path, String)`.
 * The `bin/solr.in.sh` (`bin/solr.in.cmd` on Windows) is now completely commented by default. Previously, this wasn't so, which had the effect of masking existing environment variables.
 * The `\_version_` field is no longer indexed and is now defined with `indexed=false` by default, because the field has DocValues enabled.
@@ -196,7 +248,7 @@ Note again that this is not a complete list of all changes that may impact your
 ** The metrics "75thPctlRequestTime", "95thPctlRequestTime", "99thPctlRequestTime" and "999thPctlRequestTime" in Overseer Status API have been renamed to "75thPcRequestTime", "95thPcRequestTime" and so on for consistency with stats output in other parts of Solr.
 ** The metrics "avgRequestsPerMinute", "5minRateRequestsPerMinute" and "15minRateRequestsPerMinute" have been replaced by corresponding per-second rates viz. "avgRequestsPerSecond", "5minRateRequestsPerSecond" and "15minRateRequestsPerSecond" for consistency with stats output in other parts of Solr.
 * A new highlighter named UnifiedHighlighter has been added. You are encouraged to try out the UnifiedHighlighter by setting `hl.method=unified` and report feedback. It's more efficient/faster than the other highlighters, especially compared to the original Highlighter. See `HighlightParams.java` for a listing of highlight parameters annotated with which highlighters use them. `hl.useFastVectorHighlighter` is now considered deprecated in lieu of `hl.method=fastVector`.
-* The <<caches-warming.adoc#,`maxWarmingSearchers` parameter>> now defaults to 1, and more importantly commits will now block if this limit is exceeded instead of throwing an exception (a good thing). Consequently there is no longer a risk in overlapping commits. Nonetheless users should continue to avoid excessive committing. Users are advised to remove any pre-existing `maxWarmingSearchers` entries from their `solrconfig.xml` files.
-* The <<other-parsers.adoc#complex-phrase-query-parser,Complex Phrase query parser>> now supports leading wildcards. Beware of its possible heaviness, users are encouraged to use ReversedWildcardFilter in index time analysis.
+* The xref:configuration-guide:caches-warming.adoc[`maxWarmingSearchers` parameter] now defaults to 1, and more importantly commits will now block if this limit is exceeded instead of throwing an exception (a good thing). Consequently there is no longer a risk in overlapping commits. Nonetheless users should continue to avoid excessive committing. Users are advised to remove any pre-existing `maxWarmingSearchers` entries from their `solrconfig.xml` files.
+* The xref:query-guide:other-parsers.adoc#complex-phrase-query-parser[Complex Phrase query parser] now supports leading wildcards. Beware of its possible heaviness, users are encouraged to use ReversedWildcardFilter in index time analysis.
 * The JMX metric "avgTimePerRequest" (and the corresponding metric in the metrics API for each handler) used to be a simple non-decaying average based on total cumulative time and the number of requests. The Codahale Metrics implementation applies exponential decay to this value, which heavily biases the average towards the last 5 minutes.
-* Parallel SQL now uses Apache Calcite as its SQL framework. As part of this change the default aggregation mode has been changed to `facet` rather than `map_reduce`. There have also been changes to the SQL aggregate response and some SQL syntax changes. Consult the <<sql-query.adoc#,SQL Query>> documentation for full details.
+* Parallel SQL now uses Apache Calcite as its SQL framework. As part of this change the default aggregation mode has been changed to `facet` rather than `map_reduce`. There have also been changes to the SQL aggregate response and some SQL syntax changes. Consult the xref:query-guide:sql-query.adoc[] documentation for full details.
diff --git a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-8.adoc b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-8.adoc
index e343e5e..99fade5 100644
--- a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-8.adoc
+++ b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-8.adoc
@@ -52,7 +52,7 @@ When using this parameter internal requests are sent by using HTTP/1.1.
 ./bin/solr start -c -Dsolr.http1=true -z localhost:2481/solr -s /path/to/solr/home
 ----
 +
-Note the above command *must* be customized for your environment. The section <<solr-control-script-reference.adoc#,Solr Control Script Reference>> has all the possible options. If you are running Solr as a service, you may prefer to review the section <<upgrading-a-solr-cluster.adoc#,Upgrading a Solr Cluster>>.
+Note the above command *must* be customized for your environment. The section xref:deployment-guide:solr-control-script-reference.adoc[] has all the possible options. If you are running Solr as a service, you may prefer to review the section xref:deployment-guide:upgrading-a-solr-cluster.adoc[].
 
 . When all nodes have been upgraded to 8.0, restart each one without the `-Dsolr.http1` parameter.
 
@@ -60,7 +60,7 @@ Note the above command *must* be customized for your environment. The section <<
 
 It is always strongly recommended that you fully reindex your documents after a major version upgrade.
 
-Solr has a new section of the Reference Guide, <<reindexing.adoc#,Reindexing>> which covers several strategies for how to reindex.
+Solr has a new section of the Reference Guide, xref:indexing-guide:reindexing.adoc[] which covers several strategies for how to reindex.
 
 [#new-features-8]
 == New Features & Enhancements
@@ -135,8 +135,8 @@ then you must do so with a delete-by-query technique.
 * Solr has a new field in the `\_default` configset, called `_nest_path_`. This field stores the path of the document
 in the hierarchy for non-root documents.
 
-See the sections <<indexing-nested-documents.adoc#,Indexing Nested Documents>> and
-<<searching-nested-documents.adoc#,Searching Nested Documents>> for more information
+See the sections xref:indexing-guide:indexing-nested-documents.adoc[] and
+xref:query-guide:searching-nested-documents.adoc[] for more information
 and configuration details.
 
 [#config-changes-8]
@@ -153,15 +153,15 @@ The following changes impact how fields behave.
 Note that if you have not specified any similarityFactory in the schema, or use the default
 `SchemaSimilarityFactory`, then `LegacyBM25Similarity` is automatically selected when the value for `luceneMatchVersion` is lower than `8.0.0`.
 +
-See also the section <<schema-elements.adoc#similarity,Similarity>> for more information.
+See also the section xref:indexing-guide:schema-elements.adoc#similarity[Similarity] for more information.
 
 *Memory Codecs Removed*
 
 * Memory codecs have been removed from Lucene (`MemoryPostings`, `MemoryDocValues`) and are no longer available in Solr.
 If you used `postingsFormat="Memory"` or `docValuesFormat="Memory"` on any field or field type configuration then either remove that setting to use the default or experiment with one of the other options.
 +
-For more information on defining a codec, see the section <<codec-factory.adoc#,Codec Factory>>;
-for more information on field properties, see the section <<field-type-definitions-and-properties.adoc#, Field Type Definitions and Properties>>.
+For more information on defining a codec, see the section xref:configuration-guide:codec-factory.adoc[];
+for more information on field properties, see the section xref:indexing-guide:field-type-definitions-and-properties.adoc[].
 
 *LowerCaseTokenizer*
 
@@ -177,7 +177,7 @@ The following changes impact how documents are indexed.
 
 *Index-time Boosts*
 
-* Index-time boosts were removed from <<major-changes-in-solr-7.adoc#other-deprecations-and-removals,Lucene in version 7.0>>, and in Solr 7.x the syntax was still allowed (although it logged a warning in the logs). The syntax was similar to:
+* Index-time boosts were removed from xref:major-changes-in-solr-7.adoc#other-deprecations-and-removals[Lucene in version 7.0], and in Solr 7.x the syntax was still allowed (although it logged a warning in the logs). The syntax was similar to:
 +
 [source,json]
 ----
@@ -192,13 +192,13 @@ This syntax has been removed entirely and if sent to Solr it will now produce an
 The pattern language is very similar but not the same.
 Typically, simply update the pattern by changing an uppercase 'Z' to lowercase 'z' and that's it.
 +
-For the current recommended set of patterns in schemaless mode, see the section <<schemaless-mode.adoc#,Schemaless Mode>>, or simply examine the `_default` configset (found in `server/solr/configsets`).
+For the current recommended set of patterns in schemaless mode, see the section xref:indexing-guide:schemaless-mode.adoc[], or simply examine the `_default` configset (found in `server/solr/configsets`).
 +
 Also note that the default set of date patterns (formats) have expanded from previous releases to subsume those patterns previously handled by the "extract" contrib (Solr Cell / Tika).
 
 *Solr Cell*
 
-* The extraction contrib (<<indexing-with-tika.adoc#,Solr Cell>>) no longer does any date parsing, and thus no longer supports the `date.formats` parameter. To ensure date strings are properly parsed, use the `ParseDateFieldUpdateProcessorFactory` in your update chain. This update request processor is found by default with the "parse-date" update processor when running Solr in "<<schemaless-mode.adoc#set-the-default-updaterequestprocessorchain,schemaless mode>>".
+* The extraction contrib xref:indexing-guide:indexing-with-tika.adoc[Solr Cell]) no longer does any date parsing, and thus no longer supports the `date.formats` parameter. To ensure date strings are properly parsed, use the `ParseDateFieldUpdateProcessorFactory` in your update chain. This update request processor is found by default with the "parse-date" update processor when running Solr in xref:indexing-guide:schemaless-mode.adoc#set-the-default-updaterequestprocessorchain[schemaless mode]".
 
 *Langid Contrib*
 
@@ -210,7 +210,7 @@ The following changes impact query behavior.
 
 *Highlighting*
 
-* The Unified Highlighter parameter `hl.weightMatches` now defaults to `true`. See the section <<highlighting.adoc#,Highlighting>> for more information about Highlighter parameters.
+* The Unified Highlighter parameter `hl.weightMatches` now defaults to `true`. See the section xref:query-guide:highlighting.adoc[] for more information about Highlighter parameters.
 
 *eDisMax Query Parser*
 
@@ -218,7 +218,7 @@ The following changes impact query behavior.
 
 *Function Query Parser*
 
-* The <<other-parsers.adoc#function-query-parser,Function Query Parser>> now returns scores that are equal to zero (0) when a negative value is produced. This change is due to the fact that Lucene now requires scores to be positive.
+* The xref:query-guide:other-parsers.adoc#function-query-parser[Function Query Parser] now returns scores that are equal to zero (0) when a negative value is produced. This change is due to the fact that Lucene now requires scores to be positive.
 
 === Authentication & Security Changes in 8.0
 
@@ -277,8 +277,8 @@ When upgrading to Solr 7.7.x, users should be aware of the following major chang
 *Admin UI*
 
 * The Admin UI now presents a login screen for any users with authentication enabled on their cluster.
-Clusters with <<basic-authentication-plugin.adoc#,Basic Authentication>> will prompt users to enter a username and password.
-On clusters configured to use <<kerberos-authentication-plugin.adoc#,Kerberos Authentication>>, authentication is handled transparently by the browser as before, but if authentication fails, users will be directed to configure their browser to provide an appropriate Kerberos ticket.
+Clusters with xref:deployment-guide:basic-authentication-plugin.adoc[Basic Authentication] will prompt users to enter a username and password.
+On clusters configured to use xref:deployment-guide:kerberos-authentication-plugin.adoc[Kerberos Authentication], authentication is handled transparently by the browser as before, but if authentication fails, users will be directed to configure their browser to provide an appropriate Kerberos ticket.
 +
 The login screen's purpose is cosmetic only - Admin UI-triggered Solr requests were subject to authentication prior to 7.7 and still are today.  The login screen changes only the user experience of providing this authentication.
 
@@ -291,7 +291,7 @@ In SolrCloud mode this allow-list is automatically configured to contain all liv
 In a user-managed cluster or a single-node installation the allow-list is empty by default.
 Upgrading users who use the `shards` parameter in these installations can set this value by setting the `shardsWhitelist` property in any `shardHandler` configurations in their `solrconfig.xml` file.
 +
-For more information, see the <<solrcloud-distributed-requests.adoc#configuring-the-shardhandlerfactory,Distributed Request>> documentation.
+For more information, see the xref:deployment-guide:solrcloud-distributed-requests.adoc#configuring-the-shardhandlerfactory[Distributed Request] documentation.
 
 === Solr 7.6
 
@@ -301,7 +301,7 @@ When upgrading to Solr 7.6, users should be aware of the following major changes
 
 *Collections*
 
-* The JSON parameter to set cluster-wide default cluster properties with the <<cluster-node-management.adoc#clusterprop,CLUSTERPROP>> command has changed.
+* The JSON parameter to set cluster-wide default cluster properties with the xref:deployment-guide:cluster-node-management.adoc#clusterprop[CLUSTERPROP] command has changed.
 +
 The old syntax nested the defaults into a property named `clusterDefaults`. The new syntax uses only `defaults`. The command to use is still `set-obj-property`.
 +
@@ -348,7 +348,7 @@ While most users are still encouraged to use the `NRTCachingDirectoryFactory`, w
 +
 For more information about the new directory factory, see the Jira issue https://issues.apache.org/jira/browse/LUCENE-8438[LUCENE-8438].
 +
-For more information about the directory factory configuration in Solr, see the section <<index-location-format.adoc#,DataDir and DirectoryFactory in SolrConfig>>.
+For more information about the directory factory configuration in Solr, see the section xref:configuration-guide:index-location-format.adoc[].
 
 === Solr 7.5
 
@@ -358,12 +358,12 @@ When upgrading to Solr 7.5, users should be aware of the following major changes
 
 *Schema Changes*
 
-* Since Solr 7.0, Solr's schema field-guessing has created `_str` fields for all `_txt` fields, and returned those by default with queries. As of 7.5, `_str` fields will no longer be returned by default. They will still be available and can be requested with the `fl` parameter on queries. See also the section on <<schemaless-mode.adoc#enable-field-class-guessing,field guessing>> for more information about how schema field guessing works.
+* Since Solr 7.0, Solr's schema field-guessing has created `_str` fields for all `_txt` fields, and returned those by default with queries. As of 7.5, `_str` fields will no longer be returned by default. They will still be available and can be requested with the `fl` parameter on queries. See also the section on xref:indexing-guide:schemaless-mode.adoc#enable-field-class-guessing[field guessing] for more information about how schema field guessing works.
 * The Standard Filter, which has been non-operational since at least Solr v4, has been removed.
 
 *Index Merge Policy*
 
-* When using the <<index-segments-merging.adoc#mergepolicyfactory,`TieredMergePolicy`>>, the default merge policy for Solr, `optimize` and `expungeDeletes` now respect the `maxMergedSegmentMB` configuration parameter, which defaults to `5000` (5GB).
+* When using the xref:configuration-guide:index-segments-merging.adoc#mergepolicyfactory[`TieredMergePolicy`], the default merge policy for Solr, `optimize` and `expungeDeletes` now respect the `maxMergedSegmentMB` configuration parameter, which defaults to `5000` (5GB).
 +
 If it is absolutely necessary to control the number of segments present after optimize, specify `maxSegments` as a positive integer. Setting `maxSegments` higher than `1` are honored on a "best effort" basis.
 +
@@ -377,8 +377,7 @@ The `TieredMergePolicy` will also reclaim resources from segments that exceed `m
 
 * Solr's logging configuration file is now located in `server/resources/log4j2.xml` by default.
 
-* A bug for Windows users has been corrected. When using Solr's examples (`bin/solr start -e`) log files will now be put in the correct location (`example/` instead of `server`). See also <<installing-solr.adoc#solr-examples,Solr Examples>> and <<solr-control-script-reference.adoc#,Solr Control Script Reference>> for more information.
-
+* A bug for Windows users has been corrected. When using Solr's examples (`bin/solr start -e`) log files will now be put in the correct location (`example/` instead of `server`). See also xref:deployment-guide:installing-solr.adoc#solr-examples[Solr Examples] and xref:deployment-guide:solr-control-script-reference.adoc[] for more information.
 
 === Solr 7.4
 
@@ -388,13 +387,13 @@ When upgrading to Solr 7.4, users should be aware of the following major changes
 
 *Logging*
 
-* Solr now uses Log4j v2.11. The Log4j configuration is now in `log4j2.xml` rather than `log4j.properties` files. This is a server side change only and clients using SolrJ won't need any changes. Clients can still use any logging implementation which is compatible with SLF4J. We now let Log4j handle rotation of Solr logs at startup, and `bin/solr` start scripts will no longer attempt this nor move existing console or garbage collection logs into `logs/archived` either. See <<configuring- [...]
+* Solr now uses Log4j v2.11. The Log4j configuration is now in `log4j2.xml` rather than `log4j.properties` files. This is a server side change only and clients using SolrJ won't need any changes. Clients can still use any logging implementation which is compatible with SLF4J. We now let Log4j handle rotation of Solr logs at startup, and `bin/solr` start scripts will no longer attempt this nor move existing console or garbage collection logs into `logs/archived` either. See xref:deploymen [...]
 
 * Configuring `slowQueryThresholdMillis` now logs slow requests to a separate file named `solr_slow_requests.log`. Previously they would get logged in the `solr.log` file.
 
 *User-Managed Clusters*
 
-* In the <<user-managed-index-replication.adoc#,leader-follower model>> of scaling Solr, a follower no longer commits an empty index when a completely new index is detected on leader during replication. To return to the previous behavior pass `false` to `skipCommitOnLeaderVersionZero` in the follower section of replication handler configuration, or pass it to the `fetchindex` command.
+* In the xref:deployment-guide:user-managed-index-replication.adoc[leader-follower model] of scaling Solr, a follower no longer commits an empty index when a completely new index is detected on leader during replication. To return to the previous behavior pass `false` to `skipCommitOnLeaderVersionZero` in the follower section of replication handler configuration, or pass it to the `fetchindex` command.
 
 If you are upgrading from a version earlier than Solr 7.3, please see previous version notes below.
 
@@ -410,7 +409,7 @@ When upgrading to Solr 7.3, users should be aware of the following major changes
 
 *Learning to Rank*
 
-* The `rq` parameter used with Learning to Rank `rerank` query parsing no longer considers the `defType` parameter. See <<learning-to-rank.adoc#running-a-rerank-query,Running a Rerank Query>> for more information about this parameter.
+* The `rq` parameter used with Learning to Rank `rerank` query parsing no longer considers the `defType` parameter. See xref:query-guide:learning-to-rank.adoc#running-a-rerank-query[Running a Rerank Query] for more information about this parameter.
 
 *Autoscaling & AutoAddReplicas*
 
@@ -422,7 +421,7 @@ When upgrading to Solr 7.3, users should be aware of the following major changes
 
 *Logging*
 
-* The default Solr log file size and number of backups have been raised to 32MB and 10 respectively. See the section <<configuring-logging.adoc#,Configuring Logging>> for more information about how to configure logging.
+* The default Solr log file size and number of backups have been raised to 32MB and 10 respectively. See the section xref:deployment-guide:configuring-logging.adoc[] for more information about how to configure logging.
 
 *SolrCloud*
 
@@ -430,11 +429,11 @@ When upgrading to Solr 7.3, users should be aware of the following major changes
 +
 This means to upgrade to Solr 8 in the future, you will need to be on Solr 7.3 or higher.
 
-* Replicas which are not up-to-date are no longer allowed to become leader. Use the <<shard-management.adoc#forceleader,FORCELEADER command>> of the Collections API to allow these replicas become leader.
+* Replicas which are not up-to-date are no longer allowed to become leader. Use the xref:deployment-guide:shard-management.adoc#forceleader[FORCELEADER command] of the Collections API to allow these replicas become leader.
 
 *Spatial*
 
-* If you are using the spatial JTS library with Solr, you must upgrade to 1.15.0. This new version of JTS is now dual-licensed to include a BSD style license. See the section on <<spatial-search.adoc#,Spatial Search>> for more information.
+* If you are using the spatial JTS library with Solr, you must upgrade to 1.15.0. This new version of JTS is now dual-licensed to include a BSD style license. See the section on xref:query-guide:spatial-search.adoc[] for more information.
 
 *Highlighting*
 
@@ -450,7 +449,7 @@ When upgrading to Solr 7.2, users should be aware of the following major changes
 
 *Local Params*
 
-* Starting a query string with <<local-params.adoc#,local params>> `{!myparser ...}` is used to switch from one query parser to another, and is intended for use by Solr system developers, not end users doing searches. To reduce negative side-effects of unintended hack-ability, Solr now limits the cases when local params will be parsed to only contexts in which the default parser is "<<standard-query-parser.adoc#,lucene>>" or "<<other-parsers.adoc#function-query-parser,func>>".
+* Starting a query string with xref:query-guide:local-params.adoc[] `{!myparser ...}` is used to switch from one query parser to another, and is intended for use by Solr system developers, not end users doing searches. To reduce negative side-effects of unintended hack-ability, Solr now limits the cases when local params will be parsed to only contexts in which the default parser is xref:query-guide:standard-query-parser.adoc[`lucene`] or xref:query-guide:other-parsers.adoc#function-quer [...]
 +
 So, if `defType=edismax` then `q={!myparser ...}` won't work. In that example, put the desired query parser into the `defType` parameter.
 +
@@ -480,7 +479,7 @@ When upgrading to Solr 7.1, users should be aware of the following major changes
 +
 Existing users of this feature should not have to change anything. However, they should note these changes:
 
-** Behavior: Changing the `autoAddReplicas` property from disabled (`false`) to enabled (`true`) using <<collection-management.adoc#modifycollection,MODIFYCOLLECTION API>> no longer replaces down replicas for the collection immediately. Instead, replicas are only added if a node containing them went down while `autoAddReplicas` was enabled. The parameters `autoReplicaFailoverBadNodeExpiration` and `autoReplicaFailoverWorkLoopDelay` are no longer used.
+** Behavior: Changing the `autoAddReplicas` property from disabled (`false`) to enabled (`true`) using xref:deployment-guide:collection-management.adoc#modifycollection[MODIFYCOLLECTION API] no longer replaces down replicas for the collection immediately. Instead, replicas are only added if a node containing them went down while `autoAddReplicas` was enabled. The parameters `autoReplicaFailoverBadNodeExpiration` and `autoReplicaFailoverWorkLoopDelay` are no longer used.
 ** Deprecations: Enabling/disabling autoAddReplicas cluster-wide with the API will be deprecated; use suspend/resume trigger APIs with `name=".auto_add_replicas"` instead.
 
 *Metrics Reporters*
@@ -507,4 +506,4 @@ See the section in Metrics Reporting: Shard and Cluster Reporters for more infor
 
 * In the XML query parser (`defType=xmlparser` or `{!xmlparser ... }`) the resolving of external entities is now disallowed by default.
 
-If you are upgrading from a version earlier than Solr 7.0, please see <<major-changes-in-solr-7.adoc#,Major Changes in Solr 7>> before starting your upgrade.
+If you are upgrading from a version earlier than Solr 7.0, please see xref:major-changes-in-solr-7.adoc[] before starting your upgrade.
diff --git a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-9.adoc b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-9.adoc
index cd8c41e..4d7e0d6 100644
--- a/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-9.adoc
+++ b/solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-9.adoc
@@ -44,7 +44,7 @@ Also removes support for cluster property `legacyCloud` (as if always false now)
 Otherwise, SolrJ will not be able to connect to the cluster once it has upgraded to Solr 9.
 Once you have upgraded all Solr clusters that the client is connecting to, you can upgrade the SolrJ client to 9.x.
 
-* If you're using Solr in standalone mode with the <<query-elevation-component.adoc#,Query Elevation Component>> with it's elevation file in the data directory, you'll have to move it to the <<config-sets.adoc#,Configset>> instead.
+* If you're using Solr in standalone mode with the xref:query-guide:query-elevation-component.adoc[] with it's elevation file in the data directory, you'll have to move it to the xref:configuration-guide:config-sets.adoc[Configset] instead.
 The only reason QEC supported the data directory was to support loading its changes on a commit instead of a more expensive core reload.
 That feature now works from the configset dir too.
 SolrCloud doesn't support that but may sometime.
@@ -128,14 +128,14 @@ Any custom response writer extending `TextResponseWriter` will need to implement
 
 === solr.xml maxBooleanClauses now enforced recursively
 
-Lucene 9.0 has additional safety checks over previous versions that impact how the `solr.xml` global `<<configuring-solr-xml#global-maxbooleanclauses,maxBooleanClauses>>` option is enforced.
+Lucene 9.0 has additional safety checks over previous versions that impact how the `solr.xml` global xref:configuration-guide:configuring-solr-xml#global-maxbooleanclauses[`maxBooleanClauses`] option is enforced.
 
 In previous versios of Solr, this option was a hard limit on the number of clauses in any `BooleanQuery` object - but it was only enforced for the _direct_ clauses.
 Starting with Solr 9, this global limit is now also enforced against the total number of clauses in a _nested_ query structure.
 
 Users who upgrade from prior versions of Solr may find that some requests involving complex internal query structures (Example: long query strings using `edismax` with many `qf` and `pf` fields that include query time synonym expansion) which worked in the past now hit this limit and fail.
 
-User's in this situation are advised to consider the complexity f their queries/configuration, and increase the value of `<<configuring-solr-xml#global-maxbooleanclauses,maxBooleanClauses>>` if warranted.
+User's in this situation are advised to consider the complexity f their queries/configuration, and increase the value of xref:configuration-guide:configuring-solr-xml#global-maxbooleanclauses[`maxBooleanClauses`] if warranted.
 
 === Log4J configuration & Solr MDC values
 
@@ -174,7 +174,7 @@ What percentage of them get reported to a tracing server is up to you.
 This change is backward incompatible.
 If you need the pre-9.0 default behavior, you need to explicitly set `blockUnknown:false` in `security.json`.
 
-* The allow-list defining allowed URLs for the `shards` parameter is not in the `shardHandler` configuration anymore. It is defined by the `allowUrls` top-level property of the `solr.xml` file. For more information, see <<configuring-solr-xml.adoc#allow-urls, Format of solr.allowUrls>> documentation.
+* The allow-list defining allowed URLs for the `shards` parameter is not in the `shardHandler` configuration anymore. It is defined by the `allowUrls` top-level property of the `solr.xml` file. For more information, see xref:configuration-guide:configuring-solr-xml.adoc#allow-urls[Format of solr.allowUrls] documentation.
 
 * SOLR-13985: Solr's Jetty now binds to localhost network interface by default for better out of the box security.
 Administrators that need Solr exposed more broadly can change the SOLR_JETTY_HOST property in their Solr include (solr.in.sh/solr.in.cmd) file.
diff --git a/solr/solr-ref-guide/modules/upgrade-notes/pages/solr-upgrade-notes.adoc b/solr/solr-ref-guide/modules/upgrade-notes/pages/solr-upgrade-notes.adoc
index e6b5802..60d2f87 100644
--- a/solr/solr-ref-guide/modules/upgrade-notes/pages/solr-upgrade-notes.adoc
+++ b/solr/solr-ref-guide/modules/upgrade-notes/pages/solr-upgrade-notes.adoc
@@ -60,21 +60,22 @@ The `MultiAuthRuleBasedAuthorizationPlugin` is used when the `MultiAuthPlugin` i
 
 For information on configuring these plugins, see the following sections:
 
-* <<basic-authentication-plugin.adoc#combining-basic-authentication-with-other-schemes,Combining Basic Authentication with Other Schemes>>
-* <<rule-based-authorization-plugin.adoc#multiple-authorization-plugins,Multiple Authorization Plugins>>
+* xref:deployment-guide:basic-authentication-plugin.adoc#combining-basic-authentication-with-other-schemes[Combining Basic Authentication with Other Schemes]
+* xref:deployment-guide:rule-based-authorization-plugin.adoc#multiple-authorization-plugins[Multiple Authorization Plugins]
 
 
 *ZooKeeper chroot*
 
 It's now possible to create the ZooKeeper chroot at startup if it does not already exist.
-See the section <<zookeeper-ensemble.adoc#using-the-z-parameter-with-binsolr,Using the -z Parameter with bin/solr>> for an example.
+See the section xref:deployment-guide:zookeeper-ensemble.adoc#using-the-z-parameter-with-binsolr[Using the -z Parameter with bin/solr] for an example.
 
 *Other Changes*
 
 A few other minor changes are worth noting:
 
-* The `config-read` pre-defined permission now correctly governs access for various configuration-related APIs. See also <<rule-based-authorization-plugin.adoc#predefined-permissions,Predefined Permissions>>.
-* The S3BackupRepository supports configuring the AWS Profile, if necessary. See also <<backup-restore.adoc#s3backuprepository,S3BackupRepository>>.
+* The `config-read` pre-defined permission now correctly governs access for various configuration-related APIs.
+See also xref:deployment-guide:rule-based-authorization-plugin.adoc#predefined-permissions[Predefined Permissions].
+* The S3BackupRepository supports configuring the AWS Profile, if necessary. See also xref:deployment-guide:backup-restore.adoc#s3backuprepository[S3BackupRepository].
 * Additionally, backups will now properly succeed after SPLITSHARD operations, and will correctly handle incremental backup purges.
 * SolrJ now supports uploading configsets.
 
@@ -100,13 +101,13 @@ The designer screen provides a safe environment for you to:
 * Test how schema changes will impact query-time behavior.
 * Save your changes to a configset to use with a new collection.
 
-See the section <<schema-designer.adoc#,Schema Designer>> for full details.
+See the section xref:indexing-guide:schema-designer.adoc[] for full details.
 
 *Backups in S3*
 
 Following the redesign of backups in Solr 8.8 that allowed storage of incremental backups in Google Cloud environments, Solr 8.10 provides support for storing backups in Amazon S3 buckets.
 
-See the section <<backup-restore.adoc#s3backuprepository,S3BackupRepository>> for how to configure.
+See the section xref:deployment-guide:backup-restore.adoc#s3backuprepository[S3BackupRepository] for how to configure.
 
 *Security Admin UI*
 
@@ -115,7 +116,7 @@ Solr's Admin UI also got a new screen to support management of users, roles, and
 The new UI works when authentication and/or authorization has been enabled with `bin/solr auth` or by manually installing a `security.json` file.
 Before this, it provides a warning that your Solr instance is unsecured.
 
-See the section <<security-ui.adoc#,Security UI>> for details.
+See the section xref:deployment-guide:security-ui.adoc[] for details.
 
 *Solr SQL Improvements*
 
@@ -132,12 +133,12 @@ A number of improvements have been made in Solr's SQL functionality:
 A new option for the `shards.preference` parameter allows selection of nodes based on whether or not the replica is a leader.
 Now adding `shards.preference=replica.leader:false` will limit queries only to replicas which are not currently their shard's leader.
 
-See the section <<solrcloud-distributed-requests.adoc#shards-preference-parameter,shards.preference Parameter>> for details and examples.
+See the section xref:deployment-guide:solrcloud-distributed-requests.adoc#shards-preference-parameter[shards.preference Parameter] for details and examples.
 
 *Metrics & Prometheus Exporter*
 
 A new `expr` option in the Metrics API allows for more advanced filtering of metrics based on regular expressions.
-See the section <<metrics-reporting.adoc#metrics-api,Metrics API>> for examples.
+See the section xref:deployment-guide:metrics-reporting.adoc#metrics-api[Metrics API] for examples.
 
 The Prometheus Exporter's default `solr-exporter.config` has been improved to use the new `expr` option in the Metrics API to get a smaller set of metrics.
 The default metrics exported still include most metrics, but the configuration will be easier to trim as needed.
@@ -146,7 +147,7 @@ This should help provide performance improvements in busy clusters being monitor
 *ZooKeeper Credentials*
 
 ZooKeeper credentials can now be stored in a file whose location is defined with a system property instead of being passed in plain-text.
-See <<zookeeper-access-control.adoc#out-of-the-box-credential-implementations,Out of the Box Credential Implementations>> for how to set this up.
+See xref:deployment-guide:zookeeper-access-control.adoc#out-of-the-box-credential-implementations[Out of the Box Credential Implementations] for how to set this up.
 
 === Solr 8.9
 
diff --git a/solr/solr-ref-guide/modules/upgrade-notes/upgrade-nav.adoc b/solr/solr-ref-guide/modules/upgrade-notes/upgrade-nav.adoc
index 844b76a..3ee8638 100644
--- a/solr/solr-ref-guide/modules/upgrade-notes/upgrade-nav.adoc
+++ b/solr/solr-ref-guide/modules/upgrade-notes/upgrade-nav.adoc
@@ -1,4 +1,3 @@
-.Solr Upgrade Notes
 * xref:solr-upgrade-notes.adoc[]
 ** xref:major-changes-in-solr-9.adoc[]
 ** xref:major-changes-in-solr-8.adoc[]
diff --git a/solr/solr-ref-guide/package-lock.json b/solr/solr-ref-guide/package-lock.json
index 7e2dfa5..546befa 100644
--- a/solr/solr-ref-guide/package-lock.json
+++ b/solr/solr-ref-guide/package-lock.json
@@ -328,9 +328,9 @@
           "integrity": "sha512-WuyALRjWPDGtt/wzJiadO5AXY+8hZ80hVpe6MyivgraREW751X3SbhRvG3eLKOYN+8VEvqLcf3wdnt44Z4S4SA=="
         },
         "sonic-boom": {
-          "version": "2.3.1",
-          "resolved": "https://registry.npmjs.org/sonic-boom/-/sonic-boom-2.3.1.tgz",
-          "integrity": "sha512-o0vJPsRiCW5Q0EmRKjNiiYGy2DqSXcxk4mY9vIBSPwmkH/e/vJ2Tq8EECd5NTiO77x8vlVN+ykDjRQJTqf7eKg==",
+          "version": "2.3.2",
+          "resolved": "https://registry.npmjs.org/sonic-boom/-/sonic-boom-2.3.2.tgz",
+          "integrity": "sha512-qr2XGoMP23j85LfqOMxBEunlJ5P66hhy+3CLLTFtoLHYJuG89Qs+zUZC+d4xH1Jd4lfT7IkGaNa1z5kJt15fjA==",
           "requires": {
             "atomic-sleep": "^1.0.0"
           }