j1-template 2020.0.25 → 2021.0.4

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/documents/300_first_awesome_web.asciidoc

@@ -1,12 +1,11 @@
-lorem:sentences[5]
-
-To not waste time, get through the turorial and find out what is the *Jekyll Way*.
-And if this the way you want to go.
-
-Have a good time, a good day learning Jekyll.
-
-== First awesome website
-
-lorem:sentences[5] +
-lorem:sentences[3] +
-
+lorem:sentences[5]
+
+To not waste time, get through the turorial and find out what is the *Jekyll Way*.
+And if this the way you want to go.
+
+Have a good time, a good day learning Jekyll.
+
+== First awesome website
+
+lorem:sentences[5] +
+lorem:sentences[3] +

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/tables/debug_variables.asciidoc

@@ -1,48 +1,47 @@
-ifeval::["{debug}" == "true"]
-.Liquid variables
-[cols="2,4,6a, options="header", role="table-responsive, full-width"]
-|===============================================================================
-|name |value |description 
-
-|`page.path`
-|{{ page.path }}
-|The path to the raw post or page. Example usage: Linking back to the page 
-or post's source on GitHub. This can be overridden in the `YAML Front Matter`.
-
-|`site.collections_dir`
-|{{ site.collections_dir }}
-|lorem:sentences[1]
-
-|`page.images.dir`
-|{{ page.images.dir }}
-|Image path set pagewise. See FRONTMATTER defaults in `_config.yml` for the 
-images path specified by: `images.dir` for specific page *type*. See the 
-example below for a page of type *pages*.
-[source, yaml]
-----
-defaults:
-  - scope:
-      path:          pages
-      type:          pages
-
-    values:
-      images:
-        dir:        /assets/images/pages
-----
-
-|`page-imagesdir`
-|{{ page-imagesdir }}
-| Images path set in the page by `:page-imagesdir:`. 
-
-|`template`
-|{{ site.template.name }}
-|Name of the template used for rendering a page. Settings are taken from 
-sitewide configuration defined by `_config.yml`.
-
-|`includedir`
-|{{ includedir }}
-|lorem:sentences[1]
-
-|===============================================================================
-endif::[]
-
+ifeval::["{debug}" == "true"]
+.Liquid variables
+[cols="2,4,6a, options="header", role="table-responsive, full-width"]
+|===============================================================================
+|name |value |description
+
+|`page.path`
+|{{ page.path }}
+|The path to the raw post or page. Example usage: Linking back to the page
+or post's source on GitHub. This can be overridden in the `YAML Front Matter`.
+
+|`site.collections_dir`
+|{{ site.collections_dir }}
+|lorem:sentences[1]
+
+|`page.images.dir`
+|{{ page.images.dir }}
+|Image path set pagewise. See FRONTMATTER defaults in `_config.yml` for the
+images path specified by: `images.dir` for specific page *type*. See the
+example below for a page of type *pages*.
+[source, yaml]
+----
+defaults:
+  - scope:
+      path:          pages
+      type:          pages
+
+    values:
+      images:
+        dir:        /assets/images/pages
+----
+
+|`page-imagesdir`
+|{{ page-imagesdir }}
+| Images path set in the page by `:page-imagesdir:`.
+
+|`template`
+|{{ site.template.name }}
+|Name of the template used for rendering a page. Settings are taken from
+sitewide configuration defined by `_config.yml`.
+
+|`includedir`
+|{{ includedir }}
+|lorem:sentences[1]
+
+|===============================================================================
+endif::[]

data/lib/starter_web/pages/public/learn/kickstarter/web_in_a_day/_includes/tables/readme

@@ -0,0 +1 @@
+bla

data/lib/starter_web/pages/public/learn/roundtrip/100_present_images.adoc

@@ -141,7 +141,7 @@ implementation for J1 Template support a lot more sources to be displayed
 as a slide show: simple text, for example.
 
 .Simple text carousel
-carousel::owl_demo_text_carousel[role="mb-3"]
+carousel::demo_text_carousel[role="mb-3"]
 
 Important statements or topics can be placed e.g. on top of an article or a
 paragraph to give them better visibility. In one line, you can present
@@ -156,25 +156,8 @@ kind of a slide show may be interesting. Image-based slide shows may draw off
 the reader's attention from the text, therefor a pure text-based presentation
 may the better choice.
 
-// .Parallax text carousel
-// carousel::owl_demo_text_carousel_parallax[role="mb-3"]
-
-++++
-  <div class="slider-title">Parallax text carousel</div>
-  <div class="parallax-slider__owl_demo_text_carousel_parallax mb-3" style="background-position: 50% 45px">
-    <div id="owl_demo_text_carousel_parallax"></div>
-  </div>
-
- <script>
-    $('head').append('<style>.parallax-slider__owl_demo_text_carousel_parallax{background:url(/assets/images/quotes/default.png) 50% 0 repeat fixed}</style>');
-    $('head').append('<style>.parallax-slider__owl_demo_text_carousel_parallax{padding:75px 0 75px 25px;position:relative}</style>');
-    $('head').append('<style>.parallax-slider__owl_demo_text_carousel_parallax{color:#e5e5e5;font-size:1.5rem;font-weight:400}</style>');
-    $('head').append('<!-- style>.parallax-slider__owl_demo_text_carousel_parallax{text-align:center}</style -->');
-    $('head').append('<!-- style>.parallax-slider__owl_demo_text_carousel_parallax{text-transform:uppercase}</style -->');
-    $('head').append('<style>.parallax-slider__owl_demo_text_carousel_parallax:before{top:0;left:0;width:100%;height:100%;content:" ";position:absolute;background:url(/assets/images/modules/patterns/gridtile.png) repeat;}</style>');
-    $('head').append('<style>.parallax-slider__owl_demo_text_carousel_parallax:after{top:0;left:0;width:100%;height:100%;content:" ";position:absolute;background:rgba(0,0,0,0.3)}</style>');
-  </script>
-++++
+.Parallax text carousel
+carousel::demo_text_carousel_parallax[role="mb-3"]
 
 Parallax text shows can be placed as banners on a page. A lot of different
 animations can be used. Internally, J1 Template is using some of the really
@@ -195,7 +178,7 @@ A simple image show is useful for example as an animated (or not animated)
 banner presenting exciting things of your site or the products offered.
 
 .Simple Image Carousel
-carousel::owl_demo_simple[role="mb-5"]
+carousel::demo_simple[role="mb-5"]
 
 === Carousel + Caption + Lightbox
 
@@ -205,7 +188,7 @@ a lightbox to enlarge images full size. For the example below, a almost simple
 lightbox is used: Lightbox V2; or short: lightbox.
 
 .Nice cats
-carousel::owl_demo_cats[role="mb-5"]
+carousel::demo_cats[role="mb-5"]
 
 The J1 module lightbox is a simple Lightbox but offers a bunch of impressive
 features for displaying images. For example, the lightbox can display all
@@ -220,7 +203,7 @@ to browse all images back and forth. An indicator below the slider shows how
 many images the show contains.
 
 .Single Slide Carousel and a Lightbox
-carousel::owl_demo_oneslide[role="mb-5"]
+carousel::demo_oneslide[role="mb-5"]
 
 == J1 Gallery App
 

data/lib/starter_web/pages/public/learn/roundtrip/600_lunr.adoc

@@ -1,236 +1,335 @@
----
-title:                                  Lunr
-tagline:                                full index search
-date:                                   2020-11-08 12:00:00
-description: >
-                                        Learn the search query language used by Lunr. The DSL used by Lunr
-                                        is quite close to Solr to support a powerful search experience
-                                        for better result. Using search expressions with wildcards, conditions
-                                        like and|or and fuzzy search algorithms are supported.
-
-tags:                                   [ Roundtrip, Introduction ]
-categories:                             [ Search ]
-
-toc:                                    true
-scrollbar:                              false
-
-permalink:                              /pages/public/learn/roundtrip/lunr/
-regenerate:                             true
-
-resources:                              [ lunr, rouge ]
-resource_options:
-  - attic:
-      padding_top:                      400
-      padding_bottom:                   50
-      opacity:                          0.5
-      slides:
-        - url:                          /assets/images/modules/attics/banner/lunr-banner-1280x800.jpg
-          alt:                          Lunr
----
-
-// Page Initializer
-// =============================================================================
-// Enable the Liquid Preprocessor
-:page-liquid:
-
-// Set page (local) attributes here
-// -----------------------------------------------------------------------------
-// :page--attr:                         <attr-value>
-
-//  Load Liquid procedures
-// -----------------------------------------------------------------------------
-{% capture load_attributes %}themes/{{site.template.name}}/procedures/global/attributes_loader.proc{%endcapture%}
-
-// Load page attributes
-// -----------------------------------------------------------------------------
-{% include {{load_attributes}} scope="all" %}
-
-
-// Page content
-// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-== Searching
-
-After you have built an index of your documents, the next step is to
-perform a search.
-
-The simplest way to start is to pass the text on which you want to
-search into the search method:
-
-[source, javascript]
-----
-idx.search('foo')
-----
-
-The above will return details of all documents that match the term
-“foo”. Although it looks like a string, the `search` method parses the
-string into a search query. This supports special syntax for defining
-more complex queries.
-
-Searches for multiple terms are also supported. If a document matches
-_at least_ one of the search terms, it will show in the results. The
-search terms are combined with OR.
-
-[source, javascript]
-----
-idx.search('foo bar')
-----
-
-The above example will match documents that contain either “foo” or
-“bar”. Documents that contain _both_ will score more highly and will be
-returned first.
-
-=== Scoring
-
-The score (also known as relevance) of a document is calculated by the
-https://en.wikipedia.org/wiki/Okapi_BM25[BM25] algorithm, along with
-other factors such as link:#Boosts[boosts]. You don’t need to worry too
-much about the details of how BM25 works; to summarize, the more a
-search term occurs in a single document, the more that term will
-increase that document’s score, but the more a search term occurs in the
-overall _collection_ of documents, the less that term will increase a
-document’s score.
-
-For example, let’s say you’re indexing a collection of documents about
-JavaScript testing libraries. The terms “JavaScript”, “library”, and
-“test” may occur very frequently throughout the entire collection, so
-finding a document that mentions one of these terms isn’t very
-significant. However, if you’re searching for “integration test”, only
-three documents in the collection have the term “integration” in them,
-and _one_ of them mentions “integration” many times, that will bring the
-score for that one document higher up.
-
-=== Wildcards
-
-Lunr supports wildcards when performing searches. A wildcard is
-represented as an asterisk (`*`) and can appear anywhere in a search
-term. For example, the following will match all documents with words
-beginning with “foo”:
-
-[source, javascript]
-----
-idx.search('foo*')
-----
-
-This will match all documents that end with ‘oo’:
-
-[source, javascript]
-----
-idx.search('*oo')
-----
-
-Leading wildcards, as in the above example, should be used sparingly.
-They can have a negative impact on the performance of a search,
-especially in large indexes.
-
-Finally, a wildcard can be in the middle of a term. The following will
-match any documents that contain a term that begins with “f” and ends in
-“o”:
-
-[source, javascript]
-----
-idx.search('f*o')
-----
-
-It is also worth noting that, when a search term contains a wildcard, no
-stemming is performed on the search term.
-
-=== Fields
-
-By default, Lunr will search all fields in a document for the query
-term, and it is possible to restrict a term to a specific field. The
-following example searches for the term “foo” in the field title:
-
-[source, javascript]
-----
-idx.search('title:foo')
-----
-
-The search term is prefixed with the name of the field, followed by a
-colon (`:`). The field _must_ be one of the fields defined when building
-the index. Unrecognised fields will lead to an error.
-
-Field-based searches can be combined with all other term modifiers and
-wildcards, as well as other terms. For example, to search for words
-beginning with “foo” in the title or with “bar” in any field the
-following query can be used:
-
-[source, javascript]
-----
-idx.search('title:foo* bar')
-----
-
-=== Boosts
-
-In multi-term searches, a single term may be important than others. For
-these cases Lunr supports term level boosts. Any document that matches a
-boosted term will get a higher relevance score, and appear higher up in
-the results. A boost is applied by appending a caret (`^`) and then a
-positive integer to a term.
-
-[source, javascript]
-----
-idx.search('foo^10 bar')
-----
-
-The above example weights the term “foo” 10 times higher than the term
-“bar”. The boost value can be any positive integer, and different terms
-can have different boosts:
-
-[source, javascript]
-----
-idx.search('foo^10 bar^5 baz')
-----
-
-=== Fuzzy Matches
-
-Lunr supports fuzzy matching search terms in documents, which can be
-helpful if the spelling of a term is unclear, or to increase the number
-of search results that are returned. The amount of fuzziness to allow
-when searching can also be controlled. Fuzziness is applied by appending
-a tilde (`~`) and then a positive integer to a term. The following
-search matches all documents that have a word within 1 edit distance of
-“foo”:
-
-[source, javascript]
-----
-idx.search('foo~1')
-----
-
-An edit distance of 1 allows words to match if either adding, removing,
-changing or transposing a character in the word would lead to a match.
-For example “boo” requires a single edit (replacing “f” with “b”) and
-would match, but “boot” would not as it also requires an additional “t”
-at the end.
-
-=== Term Presence
-
-By default, Lunr combines multiple terms together in a search with a
-logical OR. That is, a search for “foo bar” will match documents that
-contain “foo” or contain “bar” or contain both. This behaviour is
-controllable at the term level, i.e. the presence of each term in
-matching documents can be specified. By default each term is optional in
-a matching document, though a document must have at least one matching
-term. It is possible to specify that a term must be present in matching
-documents, or that it must be absent in matching documents.
-
-To indicate that a term must be present in matching documents the term
-should be prefixed with a plus (`+`) and to indicate that a term must be
-absent the term should be prefixed with a minus (`-`). Without either
-prefix the term’s presence in matching documents is optional.
-
-The below example searches for documents that must contain “foo”, might
-contain “bar” and must not contain “baz”:
-
-[source, javascript]
-----
-idx.search("+foo bar -baz")
-----
-
-To simulate a logical AND search of “foo AND bar” mark both terms as
-required:
-
-[source, javascript]
-----
-idx.search("+foo +bar")
-----
+---
+title:                                  Lunr
+tagline:                                full index search
+date:                                   2020-11-08 12:00:00
+description: >
+                                        The search engine Lunr is fully integrated with
+                                        J1 Template. Designed to be small, yet full featured,
+                                        to provide a great search experience without the
+                                        need for external, server-side, search services.
+
+tags:                                   [ Roundtrip, Introduction ]
+categories:                             [ Search ]
+
+toc:                                    true
+scrollbar:                              false
+
+permalink:                              /pages/public/learn/roundtrip/lunr/
+regenerate:                             true
+
+resources:                              [ lunr, rouge ]
+resource_options:
+  - attic:
+      padding_top:                      400
+      padding_bottom:                   50
+      opacity:                          0.5
+      slides:
+        - url:                          /assets/images/modules/attics/banner/lunr-banner-1280x800.jpg
+          alt:                          Lunr
+---
+
+// Page Initializer
+// =============================================================================
+// Enable the Liquid Preprocessor
+:page-liquid:
+
+// Set page (local) attributes here
+// -----------------------------------------------------------------------------
+// :page--attr:                         <attr-value>
+
+//  Load Liquid procedures
+// -----------------------------------------------------------------------------
+{% capture load_attributes %}themes/{{site.template.name}}/procedures/global/attributes_loader.proc{%endcapture%}
+
+// Load page attributes
+// -----------------------------------------------------------------------------
+{% include {{load_attributes}} scope="all" %}
+
+
+// Page content
+// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The search engine Lunr is fully integrated with J1 Template. Designed to be
+small, yet full featured, to provide a great search experience without the
+need for external, server-side search services.
+
+Searching a website using Lunr a different in compare to search engines
+like Google or Microsoft Bing. These search platforms using complex algorithm
+to provide a simple interface to the public using a lot of artificial
+intelligence (AI) methods to make senseful results out of a handfull words
+given for a search.
+
+Nevertheless, a QuickSearch, the J1 implementation of Lunr, is simple like
+searching at Google, but offers additional features to do searches more
+specific. QuickSearch provides a easy to use query language for better results.
+
+== Core concepts
+
+Understanding some of the concepts and terminology that QuickSearch (based on
+Lunr) uses will allow you to provide powerful search functionality to get more
+relevant search results.
+
+=== Indexing documnents
+
+QuickSearch, the J1 implementation of Lunr, offers searches on *all* documents
+of website generated by J1, but only for this site. No internet access is done,
+or needed. Searches are based on a pre-build *local index* generated by the
+Jekyll plugin `lunr_index.rb` located in the `_plugins` folder.
+
+The index is generated at build-time:
+
+.Index creation at buildtime
+----
+Startup the site ..
+Configuration file: ...
+
+ Incremental build: enabled
+      Generating...
+     J1 LunrSearch: creating search index ...
+     J1 LunrSearch: finished, index ready.
+     ....
+----
+
+Or, if you're running a website in development mode, the index gets refreshed
+for all files added or modified.
+
+.Index creation if files added, or modified
+----
+site:       Regenerating: n file(s) changed at ...
+site:       ...
+site:      J1 LunrSearch: creating search index ...
+site:      J1 LunrSearch: finished, index ready.
+           ...
+----
+
+=== Documents
+
+The searchable data in an index is organized as documents that contains the
+text that you want to be able to search. A document is a JSON object with one
+or more fields and an identifier that is returned in the results from a search.
+A document representing an article might look like this:
+
+[ source, json ]
+----
+{
+  "id": 0,
+  "title": "Web in a Day",
+  "tagline": "meet & greet jekyll",
+  "url": "/pages/public/learn/kickstarter/web_in_a_day/meet_and_greet/",
+  "date": "2018-05-01 00:00:00 +0000",
+  "tags": [
+    "Introduction"
+  ],
+  "categories": [
+    "Jekyll",
+    "Knowledge",
+    "Tutorial"
+  ],
+  "description": "Web in a Day is the first in a series of tutorials ... J1 Template\n",
+  "is_post": false
+}
+----
+
+In this document there are several fields, like `title`, `tagline`, or
+`description` that could be used for *full-text* searches. But additional
+fields are available, like `tags` or `categories` that can be used for
+more specific searches based on `identifiers`.
+
+To do a simple full-text search as well as more specific searches, QuickSearch
+offers a query language, a DSL (domain specific language). Find more about
+*QuickSearch DSL* queries below.
+
+=== Scoring
+
+The relevance (the `score`) of a document is calculated by an algorithm
+called BM25, along with other factors. You don’t need to worry too much about
+the details of how BM25 works. To summarize, the more a search term occurs in
+a single document, the more that term will increase that document’s score,
+but the more a search term occurs in the *overall collection* of documents,
+the less that term will increase a document’s score. In other words: seldom
+words count, increase the score.
+
+Scoring information, generated by the BM25 algorithm, is added to the (local)
+index. This allows a very fast calculation of the relevance of documents for
+a query.
+
+For example, imagine you’re website contains documents about Jekyll. The
+term `Jekyll` may occur very frequently throughout the entire website
+(used quite often for the content), so finding a document that mentions the
+term Jekyll isn’t very significant.
+
+However, if you’re searching for `Jekyll Generator`, only some documents of
+the website have the term `Generator` in them, and that will bring the score
+(relevance) for documents having both terms (words) in them at a higher score,
+bring them higher up in your search results.
+
+Matching and scoring is used by all search engines; the same to J1 QuickSearch.
+You'll see for QuickSearch a similiar behavior in *sorting* search results as
+you already know from internet search engines like Google. The top results
+are the more relevant ones.
+
+== Searching
+
+Search queries looks like simple text. But the search `engine` Lunr under the
+hood transforms the given search string (text) always into a search query.
+This supports special syntax, the DSL, for defining more complex queries.
+
+As always: start simple!
+
+=== Simple searches
+
+The simplest way to run a search is to pass the text (words) on which you
+want to search on:
+
+----
+  jekyll
+----
+
+The above will return details of all documents that match the term
+`jekyll`. Searches for *multiple* terms (words) are also supported. If
+a document matches *at least* one of the search terms, it will show in the
+results. The search terms are combined with `OR`.
+
+----
+  jekyll generator
+----
+
+The above example will match documents that contain either `jekyll` *or*
+`generator`. Documents that contain _both_ will score more highly and will
+be returned first.
+
+NOTE: In difference to a Google search (terms are combined at Google by
+`AND`) a Quicksearch combines the terms by `OR`.
+
+=== Wildcards
+
+QuickSearch supports wildcards when performing searches. A wildcard is
+represented as an asterisk (`*`) and can appear anywhere in a search
+term. For example, the following will match all documents with words
+beginning with `Jek`:
+
+----
+jek*
+----
+
+This will match all documents that end with `kyll`:
+
+----
+*kyll
+----
+
+Leading wildcards, as in the above example, should be used sparingly.
+They can have a negative impact on the performance of a search,
+especially in large indexes.
+
+Finally, a wildcard can be in the middle of a term. The following will
+match any documents that contain a term that begins with “f” and ends in
+“o”:
+
+[source, javascript]
+----
+idx.search('f*o')
+----
+
+It is also worth noting that, when a search term contains a wildcard, no
+stemming is performed on the search term.
+
+=== Fields
+
+By default, Lunr will search all fields in a document for the query
+term, and it is possible to restrict a term to a specific field. The
+following example searches for the term “foo” in the field title:
+
+[source, javascript]
+----
+idx.search('title:foo')
+----
+
+The search term is prefixed with the name of the field, followed by a
+colon (`:`). The field _must_ be one of the fields defined when building
+the index. Unrecognised fields will lead to an error.
+
+Field-based searches can be combined with all other term modifiers and
+wildcards, as well as other terms. For example, to search for words
+beginning with “foo” in the title or with “bar” in any field the
+following query can be used:
+
+[source, javascript]
+----
+idx.search('title:foo* bar')
+----
+
+=== Boosts
+
+In multi-term searches, a single term may be important than others. For
+these cases Lunr supports term level boosts. Any document that matches a
+boosted term will get a higher relevance score, and appear higher up in
+the results. A boost is applied by appending a caret (`^`) and then a
+positive integer to a term.
+
+[source, javascript]
+----
+idx.search('foo^10 bar')
+----
+
+The above example weights the term “foo” 10 times higher than the term
+“bar”. The boost value can be any positive integer, and different terms
+can have different boosts:
+
+[source, javascript]
+----
+idx.search('foo^10 bar^5 baz')
+----
+
+=== Fuzzy Matches
+
+Lunr supports fuzzy matching search terms in documents, which can be
+helpful if the spelling of a term is unclear, or to increase the number
+of search results that are returned. The amount of fuzziness to allow
+when searching can also be controlled. Fuzziness is applied by appending
+a tilde (`~`) and then a positive integer to a term. The following
+search matches all documents that have a word within 1 edit distance of
+“foo”:
+
+[source, javascript]
+----
+idx.search('foo~1')
+----
+
+An edit distance of 1 allows words to match if either adding, removing,
+changing or transposing a character in the word would lead to a match.
+For example “boo” requires a single edit (replacing “f” with “b”) and
+would match, but “boot” would not as it also requires an additional “t”
+at the end.
+
+=== Term Presence
+
+By default, Lunr combines multiple terms together in a search with a
+logical OR. That is, a search for “foo bar” will match documents that
+contain “foo” or contain “bar” or contain both. This behaviour is
+controllable at the term level, i.e. the presence of each term in
+matching documents can be specified. By default each term is optional in
+a matching document, though a document must have at least one matching
+term. It is possible to specify that a term must be present in matching
+documents, or that it must be absent in matching documents.
+
+To indicate that a term must be present in matching documents the term
+should be prefixed with a plus (`+`) and to indicate that a term must be
+absent the term should be prefixed with a minus (`-`). Without either
+prefix the term’s presence in matching documents is optional.
+
+The below example searches for documents that must contain “foo”, might
+contain “bar” and must not contain “baz”:
+
+[source, javascript]
+----
+idx.search("+foo bar -baz")
+----
+
+To simulate a logical AND search of “foo AND bar” mark both terms as
+required:
+
+[source, javascript]
+----
+idx.search("+foo +bar")
+----