Automatic next/prev links for grouped content

app/_assets/stylesheets/pages/docs.less

@@ -792,3 +792,27 @@
       font-size: 11px;
   }
 }
+
+.book-nav-container {
+  hr {
+    margin: 1em 0;
+  }
+}
+
+.book-nav {
+  width: 48%;
+
+
+  .direction {
+    display: block;
+    font-weight: bold;
+  }
+  margin-bottom: 1em;
+}
+.book-nav.previous {
+  float: left;
+}
+.book-nav.next {
+  float: right;
+  text-align: right;
+}

app/_layouts/docs-v2.html

@@ -124,9 +124,26 @@ <h2 class="page-content-subtitle">{{page.subtitle | flatify }}</h2>
             <a href="/konnect/">current {{site.konnect_short_name}} documentation</a>.
             </blockquote>
             {% endif %}
-
             {{ content }}
 
+            {% if page.book %}
+            <div class="book-nav-container">
+            <hr />
+            {% if page.book.previous %}
+            <div class="book-nav previous">
+              <span class="direction">Previous</span>
+              <a href="{{ page.book.previous.url }}">{{ page.book.previous.title  }}</a>
+            </div>
+            {% endif %}
+            {% if page.book.next %}
+            <div class="book-nav next">
+              <span class="direction">Next</span>
+              <a href="{{ page.book.next.url }}">{{ page.book.next.title  }}</a>
+            </div>
+            {% endif %}
+            </div>
+            {% endif %}
+
           </div>
         </div>
       </div>

app/_plugins/generators/book.rb

@@ -22,9 +22,9 @@ def generate(site) # rubocop:disable Metrics/PerceivedComplexity, Metrics/Cyclom
             'chapters' => {}
           }
 
-          page.data['book']['previous'] = pages[idx - 1].url if idx.positive?
+          page.data['book']['previous'] = pages[idx - 1] if idx.positive?
 
-          page.data['book']['next'] = pages[idx + 1].url if idx < pages.size - 1
+          page.data['book']['next'] = pages[idx + 1] if idx < pages.size - 1
 
           # Add all existing pages links to this page
           pages.each do |p|

app/enterprise/2.1.x/plugin-development/access-the-datastore.md

@@ -68,8 +68,4 @@ local inserted_plugin, err = kong.db.plugins:insert({
 For a real-life example of the DAO being used in a plugin, see the
 [Key-Auth plugin source code](https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/handler.lua).
 
----
-
-Next: [Storing Custom Entities ›]({{page.book.next}})
-
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.1.x/plugin-development/admin-api.md

@@ -167,8 +167,4 @@ three functions:
 - The `PUT` function populates `self.args.post.consumer` before calling the `endpoints`-provided
   `put_entity_endpoint` function.
 
----
-
-Next: [Write tests for your plugin]({{page.book.next}})
-
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/

app/enterprise/2.1.x/plugin-development/custom-entities.md

@@ -11,7 +11,7 @@ its configuration in the database. In that case, Kong provides you with
 an abstraction on top of its primary datastores which allows you to store
 custom entities.
 
-As explained in the [previous chapter]({{page.book.previous}}), Kong interacts
+As explained in the [previous chapter]({{page.book.previous.url}}), Kong interacts
 with the model layer through classes we refer to as "DAOs", and available on a
 singleton often referred to as the "DAO Factory". This chapter will explain how
 to to provide an abstraction for your own entities.
@@ -635,11 +635,7 @@ When a custom entity is required on every request/response it is good practice
 to cache it in-memory by leveraging the in-memory cache API provided by Kong.
 
 The next chapter will focus on caching custom entities, and invalidating them
-when they change in the datastore: [Caching custom entities]({{page.book.next}}).
-
----
-
-Next: [Caching custom entities ›]({{page.book.next}})
+when they change in the datastore: [Caching custom entities]({{page.book.next.url}}).
 
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.1.x/plugin-development/custom-logic.md

@@ -54,7 +54,7 @@ All of those functions, except `init_worker`, take one parameter which is given
 by Kong upon its invocation: the configuration of your plugin. This parameter
 is a Lua table, and contains values defined by your users, according to your
 plugin's schema (described in the `schema.lua` module). More on plugins schemas
-in the [next chapter]({{page.book.next}}).
+in the [next chapter]({{page.book.next.url}}).
 
 [HTTP Module]: https://github.com/openresty/lua-nginx-module
 [Stream Module]: https://github.com/openresty/stream-lua-nginx-module
@@ -320,9 +320,5 @@ syslog                      | 4
 request-termination         | 2
 post-function               | -1000
 
----
-
-Next: [Plugin configuration ›]({{page.book.next}})
-
 [lua-nginx-module]: https://github.com/openresty/lua-nginx-module
 [pdk]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.1.x/plugin-development/entities-cache.md

@@ -7,7 +7,7 @@ chapter: 7
 ## Introduction
 
 Your plugin may need to frequently access custom entities (explained in the
-[previous chapter]({{page.book.previous}})) on every request and/or response.
+[previous chapter]({{page.book.previous.url}})) on every request and/or response.
 Usually, loading them once and caching them in-memory dramatically improves
 the performance while making sure the datastore is not stressed with an
 increased load.
@@ -339,11 +339,7 @@ Kong to setup their APIs and plugins. It is likely that they also need to be
 able to interact with the custom entities you implemented for your plugin (for
 example, creating and deleting API keys). The way you would do this is by
 extending the Admin API, which we will detail in the next chapter:
-[Extending the Admin API]({{page.book.next}}).
-
----
-
-Next: [Extending the Admin API ›]({{page.book.next}})
+[Extending the Admin API]({{page.book.next.url}}).
 
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.1.x/plugin-development/file-structure.md

@@ -111,10 +111,6 @@ master each one of them.
 The [Key-Auth plugin] is an example of plugin with this file structure.
 See [its source code] for more details.
 
----
-
-Next: [Write custom logic ›]({{page.book.next}})
-
 [api.lua]: {{page.book.chapters.admin-api}}
 [daos.lua]: {{page.book.chapters.custom-entities}}
 [handler.lua]: {{page.book.chapters.custom-logic}}

app/enterprise/2.1.x/plugin-development/index.md

@@ -29,9 +29,5 @@ This guide will explore in detail the structure of plugins, what they can
 extend, and how to distribute and install them. For a complete reference of the
 PDK, see the [Plugin Development Kit] reference.
 
----
-
-Next: [File structure of a plugin ›]({{page.book.next}})
-
 [lua-nginx-module]: https://github.com/openresty/lua-nginx-module
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.1.x/plugin-development/plugin-configuration.md

@@ -411,10 +411,6 @@ return CustomHandler
 
 You can also see a real-world example of schema in [the Key-Auth plugin source code].
 
----
-
-Next: [Accessing the Datastore ›]({{page.book.next}})
-
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk
 [the Key-Auth plugin source code]: https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/schema.lua

app/enterprise/2.1.x/plugin-development/tests.md

@@ -102,6 +102,3 @@ and Admin API on port 9001.
 If you want to see a real-world example, give a look at the
 [Key-Auth plugin specs](https://github.com/Kong/kong/tree/master/spec/03-plugins/09-key-auth)
 
----
-
-Next: [Distribute your plugin ›]({{page.book.next}})

app/enterprise/2.2.x/plugin-development/access-the-datastore.md

@@ -68,8 +68,4 @@ local inserted_plugin, err = kong.db.plugins:insert({
 For a real-life example of the DAO being used in a plugin, see the
 [Key-Auth plugin source code](https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/handler.lua).
 
----
-
-Next: [Storing Custom Entities ›]({{page.book.next}})
-
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.2.x/plugin-development/admin-api.md

@@ -167,8 +167,4 @@ three functions:
 - The `PUT` function populates `self.args.post.consumer` before calling the `endpoints`-provided
   `put_entity_endpoint` function.
 
----
-
-Next: [Write tests for your plugin]({{page.book.next}})
-
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/

app/enterprise/2.2.x/plugin-development/custom-entities.md

@@ -11,7 +11,7 @@ its configuration in the database. In that case, Kong provides you with
 an abstraction on top of its primary datastores which allows you to store
 custom entities.
 
-As explained in the [previous chapter]({{page.book.previous}}), Kong interacts
+As explained in the [previous chapter]({{page.book.previous.url}}), Kong interacts
 with the model layer through classes we refer to as "DAOs", and available on a
 singleton often referred to as the "DAO Factory". This chapter will explain how
 to to provide an abstraction for your own entities.
@@ -635,11 +635,7 @@ When a custom entity is required on every request/response it is good practice
 to cache it in-memory by leveraging the in-memory cache API provided by Kong.
 
 The next chapter will focus on caching custom entities, and invalidating them
-when they change in the datastore: [Caching custom entities]({{page.book.next}}).
-
----
-
-Next: [Caching custom entities ›]({{page.book.next}})
+when they change in the datastore: [Caching custom entities]({{page.book.next.url}}).
 
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.2.x/plugin-development/custom-logic.md

@@ -54,7 +54,7 @@ All of those functions, except `init_worker`, take one parameter which is given
 by Kong upon its invocation: the configuration of your plugin. This parameter
 is a Lua table, and contains values defined by your users, according to your
 plugin's schema (described in the `schema.lua` module). More on plugins schemas
-in the [next chapter]({{page.book.next}}).
+in the [next chapter]({{page.book.next.url}}).
 
 [HTTP Module]: https://github.com/openresty/lua-nginx-module
 [Stream Module]: https://github.com/openresty/stream-lua-nginx-module
@@ -320,9 +320,5 @@ syslog                      | 4
 request-termination         | 2
 post-function               | -1000
 
----
-
-Next: [Plugin configuration ›]({{page.book.next}})
-
 [lua-nginx-module]: https://github.com/openresty/lua-nginx-module
 [pdk]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.2.x/plugin-development/entities-cache.md

@@ -7,7 +7,7 @@ chapter: 7
 ## Introduction
 
 Your plugin may need to frequently access custom entities (explained in the
-[previous chapter]({{page.book.previous}})) on every request and/or response.
+[previous chapter]({{page.book.previous.url}})) on every request and/or response.
 Usually, loading them once and caching them in-memory dramatically improves
 the performance while making sure the datastore is not stressed with an
 increased load.
@@ -339,11 +339,7 @@ Kong to setup their APIs and plugins. It is likely that they also need to be
 able to interact with the custom entities you implemented for your plugin (for
 example, creating and deleting API keys). The way you would do this is by
 extending the Admin API, which we will detail in the next chapter:
-[Extending the Admin API]({{page.book.next}}).
-
----
-
-Next: [Extending the Admin API ›]({{page.book.next}})
+[Extending the Admin API]({{page.book.next.url}}).
 
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.2.x/plugin-development/file-structure.md

@@ -111,10 +111,6 @@ master each one of them.
 The [Key-Auth plugin] is an example of plugin with this file structure.
 See [its source code] for more details.
 
----
-
-Next: [Write custom logic ›]({{page.book.next}})
-
 [api.lua]: {{page.book.chapters.admin-api}}
 [daos.lua]: {{page.book.chapters.custom-entities}}
 [handler.lua]: {{page.book.chapters.custom-logic}}

app/enterprise/2.2.x/plugin-development/index.md

@@ -29,9 +29,5 @@ This guide will explore in detail the structure of plugins, what they can
 extend, and how to distribute and install them. For a complete reference of the
 PDK, see the [Plugin Development Kit] reference.
 
----
-
-Next: [File structure of a plugin ›]({{page.book.next}})
-
 [lua-nginx-module]: https://github.com/openresty/lua-nginx-module
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.2.x/plugin-development/plugin-configuration.md

@@ -411,10 +411,6 @@ return CustomHandler
 
 You can also see a real-world example of schema in [the Key-Auth plugin source code].
 
----
-
-Next: [Accessing the Datastore ›]({{page.book.next}})
-
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk
 [the Key-Auth plugin source code]: https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/schema.lua

app/enterprise/2.2.x/plugin-development/tests.md

@@ -102,6 +102,3 @@ and Admin API on port 9001.
 If you want to see a real-world example, give a look at the
 [Key-Auth plugin specs](https://github.com/Kong/kong/tree/master/spec/03-plugins/09-key-auth)
 
----
-
-Next: [Distribute your plugin ›]({{page.book.next}})

app/enterprise/2.3.x/plugin-development/access-the-datastore.md

@@ -68,8 +68,4 @@ local inserted_plugin, err = kong.db.plugins:insert({
 For a real-life example of the DAO being used in a plugin, see the
 [Key-Auth plugin source code](https://github.com/Kong/kong/blob/master/kong/plugins/key-auth/handler.lua).
 
----
-
-Next: [Storing Custom Entities ›]({{page.book.next}})
-
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.3.x/plugin-development/admin-api.md

@@ -167,8 +167,4 @@ three functions:
 - The `PUT` function populates `self.args.post.consumer` before calling the `endpoints`-provided
   `put_entity_endpoint` function.
 
----
-
-Next: [Write tests for your plugin]({{page.book.next}})
-
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/

app/enterprise/2.3.x/plugin-development/custom-entities.md

@@ -11,7 +11,7 @@ its configuration in the database. In that case, Kong provides you with
 an abstraction on top of its primary datastores which allows you to store
 custom entities.
 
-As explained in the [previous chapter]({{page.book.previous}}), Kong interacts
+As explained in the [previous chapter]({{page.book.previous.url}}), Kong interacts
 with the model layer through classes we refer to as "DAOs", and available on a
 singleton often referred to as the "DAO Factory". This chapter will explain how
 to to provide an abstraction for your own entities.
@@ -635,11 +635,7 @@ When a custom entity is required on every request/response it is good practice
 to cache it in-memory by leveraging the in-memory cache API provided by Kong.
 
 The next chapter will focus on caching custom entities, and invalidating them
-when they change in the datastore: [Caching custom entities]({{page.book.next}}).
-
----
-
-Next: [Caching custom entities ›]({{page.book.next}})
+when they change in the datastore: [Caching custom entities]({{page.book.next.url}}).
 
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.3.x/plugin-development/custom-logic.md

@@ -54,7 +54,7 @@ All of those functions, except `init_worker`, take one parameter which is given
 by Kong upon its invocation: the configuration of your plugin. This parameter
 is a Lua table, and contains values defined by your users, according to your
 plugin's schema (described in the `schema.lua` module). More on plugins schemas
-in the [next chapter]({{page.book.next}}).
+in the [next chapter]({{page.book.next.url}}).
 
 [HTTP Module]: https://github.com/openresty/lua-nginx-module
 [Stream Module]: https://github.com/openresty/stream-lua-nginx-module
@@ -320,9 +320,5 @@ syslog                      | 4
 request-termination         | 2
 post-function               | -1000
 
----
-
-Next: [Plugin configuration ›]({{page.book.next}})
-
 [lua-nginx-module]: https://github.com/openresty/lua-nginx-module
 [pdk]: /enterprise/{{page.kong_version}}/pdk

app/enterprise/2.3.x/plugin-development/entities-cache.md

@@ -7,7 +7,7 @@ chapter: 7
 ## Introduction
 
 Your plugin may need to frequently access custom entities (explained in the
-[previous chapter]({{page.book.previous}})) on every request and/or response.
+[previous chapter]({{page.book.previous.url}})) on every request and/or response.
 Usually, loading them once and caching them in-memory dramatically improves
 the performance while making sure the datastore is not stressed with an
 increased load.
@@ -339,11 +339,7 @@ Kong to setup their APIs and plugins. It is likely that they also need to be
 able to interact with the custom entities you implemented for your plugin (for
 example, creating and deleting API keys). The way you would do this is by
 extending the Admin API, which we will detail in the next chapter:
-[Extending the Admin API]({{page.book.next}}).
-
----
-
-Next: [Extending the Admin API ›]({{page.book.next}})
+[Extending the Admin API]({{page.book.next.url}}).
 
 [Admin API]: /enterprise/{{page.kong_version}}/admin-api/
 [Plugin Development Kit]: /enterprise/{{page.kong_version}}/pdk