2017-05-06 14:15:28 -04:00
|
|
|
|
// Copyright 2017 The Hugo Authors. All rights reserved.
|
2013-07-04 11:32:55 -04:00
|
|
|
|
//
|
2015-11-23 22:16:36 -05:00
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
2013-07-04 11:32:55 -04:00
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
|
// You may obtain a copy of the License at
|
2015-11-23 22:16:36 -05:00
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
2013-07-04 11:32:55 -04:00
|
|
|
|
//
|
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
|
// limitations under the License.
|
|
|
|
|
|
|
|
|
|
package hugolib
|
|
|
|
|
|
|
|
|
|
import (
|
2015-06-21 07:08:30 -04:00
|
|
|
|
"bytes"
|
|
|
|
|
"errors"
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
"fmt"
|
2014-01-29 17:50:31 -05:00
|
|
|
|
"html/template"
|
2018-11-26 05:01:27 -05:00
|
|
|
|
"path"
|
|
|
|
|
|
|
|
|
|
"github.com/gohugoio/hugo/common/herrors"
|
2018-10-21 06:20:21 -04:00
|
|
|
|
|
2014-02-25 23:57:31 -05:00
|
|
|
|
"reflect"
|
2018-10-21 06:20:21 -04:00
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
"regexp"
|
2014-11-18 04:20:52 -05:00
|
|
|
|
"sort"
|
2018-10-03 08:58:09 -04:00
|
|
|
|
|
2018-10-17 06:57:09 -04:00
|
|
|
|
"github.com/gohugoio/hugo/parser/pageparser"
|
|
|
|
|
|
2018-10-03 08:58:09 -04:00
|
|
|
|
_errors "github.com/pkg/errors"
|
|
|
|
|
|
2014-01-29 17:50:31 -05:00
|
|
|
|
"strings"
|
2015-01-21 13:13:11 -05:00
|
|
|
|
"sync"
|
2014-11-20 12:32:21 -05:00
|
|
|
|
|
2018-07-06 08:12:10 -04:00
|
|
|
|
"github.com/gohugoio/hugo/common/maps"
|
2018-11-01 06:28:30 -04:00
|
|
|
|
"github.com/gohugoio/hugo/common/text"
|
|
|
|
|
"github.com/gohugoio/hugo/common/urls"
|
2017-06-13 12:42:45 -04:00
|
|
|
|
"github.com/gohugoio/hugo/output"
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
2017-06-13 12:42:45 -04:00
|
|
|
|
"github.com/gohugoio/hugo/media"
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
2017-06-13 12:42:45 -04:00
|
|
|
|
bp "github.com/gohugoio/hugo/bufferpool"
|
|
|
|
|
"github.com/gohugoio/hugo/helpers"
|
|
|
|
|
"github.com/gohugoio/hugo/tpl"
|
2014-03-31 13:23:34 -04:00
|
|
|
|
)
|
2013-07-04 11:32:55 -04:00
|
|
|
|
|
2018-11-01 06:28:30 -04:00
|
|
|
|
var (
|
|
|
|
|
_ urls.RefLinker = (*ShortcodeWithPage)(nil)
|
|
|
|
|
_ pageContainer = (*ShortcodeWithPage)(nil)
|
|
|
|
|
_ text.Positioner = (*ShortcodeWithPage)(nil)
|
|
|
|
|
)
|
|
|
|
|
|
2016-03-24 09:11:04 -04:00
|
|
|
|
// ShortcodeWithPage is the "." context in a shortcode template.
|
2013-07-04 11:32:55 -04:00
|
|
|
|
type ShortcodeWithPage struct {
|
2015-11-20 19:59:54 -05:00
|
|
|
|
Params interface{}
|
|
|
|
|
Inner template.HTML
|
2018-04-19 12:06:40 -04:00
|
|
|
|
Page *PageWithoutContent
|
2016-03-08 14:56:24 -05:00
|
|
|
|
Parent *ShortcodeWithPage
|
2018-12-21 03:51:15 -05:00
|
|
|
|
Name string
|
2015-11-20 19:59:54 -05:00
|
|
|
|
IsNamedParams bool
|
2018-04-23 02:09:56 -04:00
|
|
|
|
|
2018-05-27 15:34:05 -04:00
|
|
|
|
// Zero-based ordinal in relation to its parent. If the parent is the page itself,
|
|
|
|
|
// this ordinal will represent the position of this shortcode in the page content.
|
2018-04-23 02:09:56 -04:00
|
|
|
|
Ordinal int
|
|
|
|
|
|
2018-11-01 05:39:44 -04:00
|
|
|
|
// pos is the position in bytes in the source file. Used for error logging.
|
|
|
|
|
posInit sync.Once
|
|
|
|
|
posOffset int
|
2018-11-01 06:28:30 -04:00
|
|
|
|
pos text.Position
|
2018-11-01 05:39:44 -04:00
|
|
|
|
|
2018-07-06 08:12:10 -04:00
|
|
|
|
scratch *maps.Scratch
|
2013-07-04 11:32:55 -04:00
|
|
|
|
}
|
|
|
|
|
|
2018-11-01 05:39:44 -04:00
|
|
|
|
// Position returns this shortcode's detailed position. Note that this information
|
|
|
|
|
// may be expensive to calculate, so only use this in error situations.
|
2018-11-01 06:28:30 -04:00
|
|
|
|
func (scp *ShortcodeWithPage) Position() text.Position {
|
2018-11-01 05:39:44 -04:00
|
|
|
|
scp.posInit.Do(func() {
|
|
|
|
|
scp.pos = scp.Page.posFromPage(scp.posOffset)
|
|
|
|
|
})
|
|
|
|
|
return scp.pos
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-24 09:11:04 -04:00
|
|
|
|
// Site returns information about the current site.
|
2016-03-14 09:10:15 -04:00
|
|
|
|
func (scp *ShortcodeWithPage) Site() *SiteInfo {
|
|
|
|
|
return scp.Page.Site
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-01 06:28:30 -04:00
|
|
|
|
// Ref is a shortcut to the Ref method on Page. It passes itself as a context
|
|
|
|
|
// to get better error messages.
|
2018-07-17 15:44:08 -04:00
|
|
|
|
func (scp *ShortcodeWithPage) Ref(args map[string]interface{}) (string, error) {
|
2018-11-01 06:28:30 -04:00
|
|
|
|
return scp.Page.ref(args, scp)
|
Provide (relative) reference funcs & shortcodes.
- `.Ref` and `.RelRef` take a reference (the logical filename for a
page, including extension and/or a document fragment ID) and return
a permalink (or relative permalink) to the referenced document.
- If the reference is a page name (such as `about.md`), the page
will be discovered and the permalink will be returned: `/about/`
- If the reference is a page name with a fragment (such as
`about.md#who`), the page will be discovered and used to add the
`page.UniqueID()` to the resulting fragment and permalink:
`/about/#who:deadbeef`.
- If the reference is a fragment and `.*Ref` has been called from
a `Node` or `SiteInfo`, it will be returned as is: `#who`.
- If the reference is a fragment and `.*Ref` has been called from
a `Page`, it will be returned with the page’s unique ID:
`#who:deadbeef`.
- `.*Ref` can be called from either `Node`, `SiteInfo` (e.g.,
`Node.Site`), `Page` objects, or `ShortcodeWithPage` objects in
templates.
- `.*Ref` cannot be used in content, so two shortcodes have been
created to provide the functionality to content: `ref` and `relref`.
These are intended to be used within markup, like `[Who]({{% ref
about.md#who %}})` or `<a href="{{% ref about.md#who %}}">Who</a>`.
- There are also `ref` and `relref` template functions (used to create
the shortcodes) that expect a `Page` or `Node` object and the
reference string (e.g., `{{ relref . "about.md" }}` or `{{
"about.md" | ref . }}`). It actually looks for `.*Ref` as defined on
`Node` or `Page` objects.
- Shortcode handling had to use a *differently unique* wrapper in
`createShortcodePlaceholder` because of the way that the `ref` and
`relref` are intended to be used in content.
2014-11-24 01:15:34 -05:00
|
|
|
|
}
|
|
|
|
|
|
2018-11-01 06:28:30 -04:00
|
|
|
|
// RelRef is a shortcut to the RelRef method on Page. It passes itself as a context
|
|
|
|
|
// to get better error messages.
|
2018-07-17 15:44:08 -04:00
|
|
|
|
func (scp *ShortcodeWithPage) RelRef(args map[string]interface{}) (string, error) {
|
2018-11-01 06:28:30 -04:00
|
|
|
|
return scp.Page.relRef(args, scp)
|
Provide (relative) reference funcs & shortcodes.
- `.Ref` and `.RelRef` take a reference (the logical filename for a
page, including extension and/or a document fragment ID) and return
a permalink (or relative permalink) to the referenced document.
- If the reference is a page name (such as `about.md`), the page
will be discovered and the permalink will be returned: `/about/`
- If the reference is a page name with a fragment (such as
`about.md#who`), the page will be discovered and used to add the
`page.UniqueID()` to the resulting fragment and permalink:
`/about/#who:deadbeef`.
- If the reference is a fragment and `.*Ref` has been called from
a `Node` or `SiteInfo`, it will be returned as is: `#who`.
- If the reference is a fragment and `.*Ref` has been called from
a `Page`, it will be returned with the page’s unique ID:
`#who:deadbeef`.
- `.*Ref` can be called from either `Node`, `SiteInfo` (e.g.,
`Node.Site`), `Page` objects, or `ShortcodeWithPage` objects in
templates.
- `.*Ref` cannot be used in content, so two shortcodes have been
created to provide the functionality to content: `ref` and `relref`.
These are intended to be used within markup, like `[Who]({{% ref
about.md#who %}})` or `<a href="{{% ref about.md#who %}}">Who</a>`.
- There are also `ref` and `relref` template functions (used to create
the shortcodes) that expect a `Page` or `Node` object and the
reference string (e.g., `{{ relref . "about.md" }}` or `{{
"about.md" | ref . }}`). It actually looks for `.*Ref` as defined on
`Node` or `Page` objects.
- Shortcode handling had to use a *differently unique* wrapper in
`createShortcodePlaceholder` because of the way that the `ref` and
`relref` are intended to be used in content.
2014-11-24 01:15:34 -05:00
|
|
|
|
}
|
|
|
|
|
|
2016-03-24 09:11:04 -04:00
|
|
|
|
// Scratch returns a scratch-pad scoped for this shortcode. This can be used
|
|
|
|
|
// as a temporary storage for variables, counters etc.
|
2018-07-06 08:12:10 -04:00
|
|
|
|
func (scp *ShortcodeWithPage) Scratch() *maps.Scratch {
|
2016-03-21 06:10:57 -04:00
|
|
|
|
if scp.scratch == nil {
|
2018-07-06 08:12:10 -04:00
|
|
|
|
scp.scratch = maps.NewScratch()
|
2016-03-21 06:10:57 -04:00
|
|
|
|
}
|
|
|
|
|
return scp.scratch
|
2015-04-19 08:50:24 -04:00
|
|
|
|
}
|
|
|
|
|
|
2016-03-24 09:11:04 -04:00
|
|
|
|
// Get is a convenience method to look up shortcode parameters by its key.
|
2014-02-25 23:57:31 -05:00
|
|
|
|
func (scp *ShortcodeWithPage) Get(key interface{}) interface{} {
|
2016-07-21 11:18:55 -04:00
|
|
|
|
if scp.Params == nil {
|
|
|
|
|
return nil
|
|
|
|
|
}
|
2014-02-25 23:57:31 -05:00
|
|
|
|
if reflect.ValueOf(scp.Params).Len() == 0 {
|
|
|
|
|
return nil
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var x reflect.Value
|
|
|
|
|
|
|
|
|
|
switch key.(type) {
|
|
|
|
|
case int64, int32, int16, int8, int:
|
|
|
|
|
if reflect.TypeOf(scp.Params).Kind() == reflect.Map {
|
2018-05-21 11:47:52 -04:00
|
|
|
|
// We treat this as a non error, so people can do similar to
|
|
|
|
|
// {{ $myParam := .Get "myParam" | default .Get 0 }}
|
|
|
|
|
// Without having to do additional checks.
|
|
|
|
|
return nil
|
2014-02-25 23:57:31 -05:00
|
|
|
|
} else if reflect.TypeOf(scp.Params).Kind() == reflect.Slice {
|
2015-08-07 13:21:26 -04:00
|
|
|
|
idx := int(reflect.ValueOf(key).Int())
|
|
|
|
|
ln := reflect.ValueOf(scp.Params).Len()
|
|
|
|
|
if idx > ln-1 {
|
2018-04-17 05:24:03 -04:00
|
|
|
|
return ""
|
2015-08-07 13:21:26 -04:00
|
|
|
|
}
|
|
|
|
|
x = reflect.ValueOf(scp.Params).Index(idx)
|
2014-02-25 23:57:31 -05:00
|
|
|
|
}
|
|
|
|
|
case string:
|
|
|
|
|
if reflect.TypeOf(scp.Params).Kind() == reflect.Map {
|
|
|
|
|
x = reflect.ValueOf(scp.Params).MapIndex(reflect.ValueOf(key))
|
|
|
|
|
if !x.IsValid() {
|
|
|
|
|
return ""
|
|
|
|
|
}
|
|
|
|
|
} else if reflect.TypeOf(scp.Params).Kind() == reflect.Slice {
|
2018-05-21 11:47:52 -04:00
|
|
|
|
// We treat this as a non error, so people can do similar to
|
|
|
|
|
// {{ $myParam := .Get "myParam" | default .Get 0 }}
|
|
|
|
|
// Without having to do additional checks.
|
|
|
|
|
return nil
|
2014-02-25 23:57:31 -05:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch x.Kind() {
|
|
|
|
|
case reflect.String:
|
|
|
|
|
return x.String()
|
|
|
|
|
case reflect.Int64, reflect.Int32, reflect.Int16, reflect.Int8, reflect.Int:
|
|
|
|
|
return x.Int()
|
|
|
|
|
default:
|
|
|
|
|
return x
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-01 06:28:30 -04:00
|
|
|
|
func (scp *ShortcodeWithPage) page() *Page {
|
|
|
|
|
return scp.Page.Page
|
|
|
|
|
}
|
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
// Note - this value must not contain any markup syntax
|
|
|
|
|
const shortcodePlaceholderPrefix = "HUGOSHORTCODE"
|
2013-07-04 11:32:55 -04:00
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
type shortcode struct {
|
2018-11-26 05:01:27 -05:00
|
|
|
|
name string
|
|
|
|
|
isInline bool // inline shortcode. Any inner will be a Go template.
|
|
|
|
|
isClosing bool // whether a closing tag was provided
|
|
|
|
|
inner []interface{} // string or nested shortcode
|
|
|
|
|
params interface{} // map or array
|
|
|
|
|
ordinal int
|
|
|
|
|
err error
|
|
|
|
|
doMarkup bool
|
|
|
|
|
pos int // the position in bytes in the source file
|
2013-07-04 11:32:55 -04:00
|
|
|
|
}
|
|
|
|
|
|
Move the emoji parsing to pageparser
This avoids double parsing the page content when `enableEmoji=true`.
This commit also adds some general improvements to the parser, making it in general much faster:
```bash
benchmark old ns/op new ns/op delta
BenchmarkShortcodeLexer-4 90258 101730 +12.71%
BenchmarkParse-4 148940 15037 -89.90%
benchmark old allocs new allocs delta
BenchmarkShortcodeLexer-4 456 700 +53.51%
BenchmarkParse-4 28 33 +17.86%
benchmark old bytes new bytes delta
BenchmarkShortcodeLexer-4 69875 81014 +15.94%
BenchmarkParse-4 8128 8304 +2.17%
```
Running some site benchmarks with Emoji support turned on:
```bash
benchmark old ns/op new ns/op delta
BenchmarkSiteBuilding/TOML,num_langs=3,num_pages=5000,tags_per_page=5,shortcodes,render-4 924556797 818115620 -11.51%
benchmark old allocs new allocs delta
BenchmarkSiteBuilding/TOML,num_langs=3,num_pages=5000,tags_per_page=5,shortcodes,render-4 4112613 4133787 +0.51%
benchmark old bytes new bytes delta
BenchmarkSiteBuilding/TOML,num_langs=3,num_pages=5000,tags_per_page=5,shortcodes,render-4 426982864 424363832 -0.61%
```
Fixes #5534
2018-12-17 15:03:23 -05:00
|
|
|
|
func (s shortcode) innerString() string {
|
|
|
|
|
var sb strings.Builder
|
|
|
|
|
|
|
|
|
|
for _, inner := range s.inner {
|
|
|
|
|
sb.WriteString(inner.(string))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return sb.String()
|
|
|
|
|
}
|
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
func (sc shortcode) String() string {
|
|
|
|
|
// for testing (mostly), so any change here will break tests!
|
2014-11-18 04:20:52 -05:00
|
|
|
|
var params interface{}
|
|
|
|
|
switch v := sc.params.(type) {
|
|
|
|
|
case map[string]string:
|
|
|
|
|
// sort the keys so test assertions won't fail
|
|
|
|
|
var keys []string
|
|
|
|
|
for k := range v {
|
|
|
|
|
keys = append(keys, k)
|
|
|
|
|
}
|
|
|
|
|
sort.Strings(keys)
|
|
|
|
|
var tmp = make([]string, len(keys))
|
|
|
|
|
|
|
|
|
|
for i, k := range keys {
|
|
|
|
|
tmp[i] = k + ":" + v[k]
|
|
|
|
|
}
|
|
|
|
|
params = tmp
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
// use it as is
|
|
|
|
|
params = sc.params
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return fmt.Sprintf("%s(%q, %t){%s}", sc.name, params, sc.doMarkup, sc.inner)
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
2013-12-06 23:14:54 -05:00
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
// We may have special shortcode templates for AMP etc.
|
|
|
|
|
// Note that in the below, OutputFormat may be empty.
|
|
|
|
|
// We will try to look for the most specific shortcode template available.
|
|
|
|
|
type scKey struct {
|
2017-07-02 04:46:28 -04:00
|
|
|
|
Lang string
|
2017-05-06 14:15:28 -04:00
|
|
|
|
OutputFormat string
|
|
|
|
|
Suffix string
|
|
|
|
|
ShortcodePlaceholder string
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func newScKey(m media.Type, shortcodeplaceholder string) scKey {
|
2018-07-10 05:55:22 -04:00
|
|
|
|
return scKey{Suffix: m.Suffix(), ShortcodePlaceholder: shortcodeplaceholder}
|
2017-05-06 14:15:28 -04:00
|
|
|
|
}
|
|
|
|
|
|
2017-07-02 04:46:28 -04:00
|
|
|
|
func newScKeyFromLangAndOutputFormat(lang string, o output.Format, shortcodeplaceholder string) scKey {
|
2018-07-10 05:55:22 -04:00
|
|
|
|
return scKey{Lang: lang, Suffix: o.MediaType.Suffix(), OutputFormat: o.Name, ShortcodePlaceholder: shortcodeplaceholder}
|
2017-05-06 14:15:28 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func newDefaultScKey(shortcodeplaceholder string) scKey {
|
|
|
|
|
return newScKey(media.HTMLType, shortcodeplaceholder)
|
|
|
|
|
}
|
|
|
|
|
|
2017-03-10 14:54:50 -05:00
|
|
|
|
type shortcodeHandler struct {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
init sync.Once
|
|
|
|
|
|
2018-04-19 12:06:40 -04:00
|
|
|
|
p *PageWithoutContent
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
|
|
|
|
// This is all shortcode rendering funcs for all potential output formats.
|
2018-04-22 08:07:29 -04:00
|
|
|
|
contentShortcodes *orderedMap
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
|
|
|
|
// This map contains the new or changed set of shortcodes that need
|
|
|
|
|
// to be rendered for the current output format.
|
2018-04-22 08:07:29 -04:00
|
|
|
|
contentShortcodesDelta *orderedMap
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
|
|
|
|
// This maps the shorcode placeholders with the rendered content.
|
|
|
|
|
// We will do (potential) partial re-rendering per output format,
|
|
|
|
|
// so keep this for the unchanged.
|
|
|
|
|
renderedShortcodes map[string]string
|
2017-03-10 14:54:50 -05:00
|
|
|
|
|
|
|
|
|
// Maps the shortcodeplaceholder with the actual shortcode.
|
2018-04-22 08:07:29 -04:00
|
|
|
|
shortcodes *orderedMap
|
2017-03-10 14:54:50 -05:00
|
|
|
|
|
|
|
|
|
// All the shortcode names in this set.
|
|
|
|
|
nameSet map[string]bool
|
2018-04-19 12:06:40 -04:00
|
|
|
|
|
|
|
|
|
placeholderID int
|
|
|
|
|
placeholderFunc func() string
|
2018-11-26 05:01:27 -05:00
|
|
|
|
|
|
|
|
|
enableInlineShortcodes bool
|
2018-04-19 12:06:40 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *shortcodeHandler) nextPlaceholderID() int {
|
|
|
|
|
s.placeholderID++
|
|
|
|
|
return s.placeholderID
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *shortcodeHandler) createShortcodePlaceholder() string {
|
2018-10-18 04:21:23 -04:00
|
|
|
|
return s.placeholderFunc()
|
2017-03-10 14:54:50 -05:00
|
|
|
|
}
|
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
func newShortcodeHandler(p *Page) *shortcodeHandler {
|
2018-10-18 04:21:23 -04:00
|
|
|
|
|
|
|
|
|
s := &shortcodeHandler{
|
2018-11-26 05:01:27 -05:00
|
|
|
|
p: p.withoutContent(),
|
|
|
|
|
enableInlineShortcodes: p.s.enableInlineShortcodes,
|
|
|
|
|
contentShortcodes: newOrderedMap(),
|
|
|
|
|
shortcodes: newOrderedMap(),
|
|
|
|
|
nameSet: make(map[string]bool),
|
|
|
|
|
renderedShortcodes: make(map[string]string),
|
2017-03-10 14:54:50 -05:00
|
|
|
|
}
|
2018-10-18 04:21:23 -04:00
|
|
|
|
|
|
|
|
|
placeholderFunc := p.s.shortcodePlaceholderFunc
|
|
|
|
|
if placeholderFunc == nil {
|
|
|
|
|
placeholderFunc = func() string {
|
|
|
|
|
return fmt.Sprintf("HAHA%s-%p-%d-HBHB", shortcodePlaceholderPrefix, p, s.nextPlaceholderID())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
s.placeholderFunc = placeholderFunc
|
|
|
|
|
return s
|
2017-03-10 14:54:50 -05:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TODO(bep) make it non-global
|
2015-01-21 13:13:11 -05:00
|
|
|
|
var isInnerShortcodeCache = struct {
|
|
|
|
|
sync.RWMutex
|
|
|
|
|
m map[string]bool
|
|
|
|
|
}{m: make(map[string]bool)}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
|
|
|
|
// to avoid potential costly look-aheads for closing tags we look inside the template itself
|
|
|
|
|
// we could change the syntax to self-closing tags, but that would make users cry
|
|
|
|
|
// the value found is cached
|
2017-03-27 14:43:49 -04:00
|
|
|
|
func isInnerShortcode(t tpl.TemplateExecutor) (bool, error) {
|
2015-01-21 13:13:11 -05:00
|
|
|
|
isInnerShortcodeCache.RLock()
|
|
|
|
|
m, ok := isInnerShortcodeCache.m[t.Name()]
|
|
|
|
|
isInnerShortcodeCache.RUnlock()
|
|
|
|
|
|
|
|
|
|
if ok {
|
2015-11-21 17:29:58 -05:00
|
|
|
|
return m, nil
|
2014-06-26 16:47:51 -04:00
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
2015-01-21 13:13:11 -05:00
|
|
|
|
isInnerShortcodeCache.Lock()
|
2015-02-20 11:41:37 -05:00
|
|
|
|
defer isInnerShortcodeCache.Unlock()
|
2017-03-27 14:43:49 -04:00
|
|
|
|
match, _ := regexp.MatchString("{{.*?\\.Inner.*?}}", t.Tree())
|
2015-01-21 13:13:11 -05:00
|
|
|
|
isInnerShortcodeCache.m[t.Name()] = match
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
2015-11-21 17:29:58 -05:00
|
|
|
|
return match, nil
|
2013-12-06 23:14:54 -05:00
|
|
|
|
}
|
|
|
|
|
|
2017-03-10 14:54:50 -05:00
|
|
|
|
func clearIsInnerShortcodeCache() {
|
|
|
|
|
isInnerShortcodeCache.Lock()
|
|
|
|
|
defer isInnerShortcodeCache.Unlock()
|
|
|
|
|
isInnerShortcodeCache.m = make(map[string]bool)
|
|
|
|
|
}
|
|
|
|
|
|
Provide (relative) reference funcs & shortcodes.
- `.Ref` and `.RelRef` take a reference (the logical filename for a
page, including extension and/or a document fragment ID) and return
a permalink (or relative permalink) to the referenced document.
- If the reference is a page name (such as `about.md`), the page
will be discovered and the permalink will be returned: `/about/`
- If the reference is a page name with a fragment (such as
`about.md#who`), the page will be discovered and used to add the
`page.UniqueID()` to the resulting fragment and permalink:
`/about/#who:deadbeef`.
- If the reference is a fragment and `.*Ref` has been called from
a `Node` or `SiteInfo`, it will be returned as is: `#who`.
- If the reference is a fragment and `.*Ref` has been called from
a `Page`, it will be returned with the page’s unique ID:
`#who:deadbeef`.
- `.*Ref` can be called from either `Node`, `SiteInfo` (e.g.,
`Node.Site`), `Page` objects, or `ShortcodeWithPage` objects in
templates.
- `.*Ref` cannot be used in content, so two shortcodes have been
created to provide the functionality to content: `ref` and `relref`.
These are intended to be used within markup, like `[Who]({{% ref
about.md#who %}})` or `<a href="{{% ref about.md#who %}}">Who</a>`.
- There are also `ref` and `relref` template functions (used to create
the shortcodes) that expect a `Page` or `Node` object and the
reference string (e.g., `{{ relref . "about.md" }}` or `{{
"about.md" | ref . }}`). It actually looks for `.*Ref` as defined on
`Node` or `Page` objects.
- Shortcode handling had to use a *differently unique* wrapper in
`createShortcodePlaceholder` because of the way that the `ref` and
`relref` are intended to be used in content.
2014-11-24 01:15:34 -05:00
|
|
|
|
const innerNewlineRegexp = "\n"
|
|
|
|
|
const innerCleanupRegexp = `\A<p>(.*)</p>\n\z`
|
|
|
|
|
const innerCleanupExpand = "$1"
|
|
|
|
|
|
2018-11-26 05:01:27 -05:00
|
|
|
|
func (s *shortcodeHandler) prepareShortcodeForPage(placeholder string, sc *shortcode, parent *ShortcodeWithPage, p *PageWithoutContent) map[scKey]func() (string, error) {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
m := make(map[scKey]func() (string, error))
|
2017-07-02 04:46:28 -04:00
|
|
|
|
lang := p.Lang()
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
2018-11-26 05:01:27 -05:00
|
|
|
|
if sc.isInline {
|
|
|
|
|
key := newScKeyFromLangAndOutputFormat(lang, p.outputFormats[0], placeholder)
|
2019-01-31 05:53:21 -05:00
|
|
|
|
m[key] = func() (string, error) {
|
|
|
|
|
return renderShortcode(key, sc, nil, p)
|
|
|
|
|
|
2018-11-26 05:01:27 -05:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return m
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
for _, f := range p.outputFormats {
|
|
|
|
|
// The most specific template will win.
|
2017-07-02 04:46:28 -04:00
|
|
|
|
key := newScKeyFromLangAndOutputFormat(lang, f, placeholder)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
m[key] = func() (string, error) {
|
2018-10-03 08:58:09 -04:00
|
|
|
|
return renderShortcode(key, sc, nil, p)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return m
|
|
|
|
|
}
|
2014-02-25 23:57:31 -05:00
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
func renderShortcode(
|
|
|
|
|
tmplKey scKey,
|
2018-04-22 08:07:29 -04:00
|
|
|
|
sc *shortcode,
|
2017-05-06 14:15:28 -04:00
|
|
|
|
parent *ShortcodeWithPage,
|
2018-10-03 08:58:09 -04:00
|
|
|
|
p *PageWithoutContent) (string, error) {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
2018-11-26 05:01:27 -05:00
|
|
|
|
var tmpl tpl.Template
|
|
|
|
|
|
|
|
|
|
if sc.isInline {
|
2019-01-31 05:53:21 -05:00
|
|
|
|
if !p.s.enableInlineShortcodes {
|
|
|
|
|
return "", nil
|
|
|
|
|
}
|
2018-11-26 05:01:27 -05:00
|
|
|
|
templName := path.Join("_inline_shortcode", p.Path(), sc.name)
|
|
|
|
|
if sc.isClosing {
|
Move the emoji parsing to pageparser
This avoids double parsing the page content when `enableEmoji=true`.
This commit also adds some general improvements to the parser, making it in general much faster:
```bash
benchmark old ns/op new ns/op delta
BenchmarkShortcodeLexer-4 90258 101730 +12.71%
BenchmarkParse-4 148940 15037 -89.90%
benchmark old allocs new allocs delta
BenchmarkShortcodeLexer-4 456 700 +53.51%
BenchmarkParse-4 28 33 +17.86%
benchmark old bytes new bytes delta
BenchmarkShortcodeLexer-4 69875 81014 +15.94%
BenchmarkParse-4 8128 8304 +2.17%
```
Running some site benchmarks with Emoji support turned on:
```bash
benchmark old ns/op new ns/op delta
BenchmarkSiteBuilding/TOML,num_langs=3,num_pages=5000,tags_per_page=5,shortcodes,render-4 924556797 818115620 -11.51%
benchmark old allocs new allocs delta
BenchmarkSiteBuilding/TOML,num_langs=3,num_pages=5000,tags_per_page=5,shortcodes,render-4 4112613 4133787 +0.51%
benchmark old bytes new bytes delta
BenchmarkSiteBuilding/TOML,num_langs=3,num_pages=5000,tags_per_page=5,shortcodes,render-4 426982864 424363832 -0.61%
```
Fixes #5534
2018-12-17 15:03:23 -05:00
|
|
|
|
templStr := sc.innerString()
|
2018-11-26 05:01:27 -05:00
|
|
|
|
|
|
|
|
|
var err error
|
|
|
|
|
tmpl, err = p.s.TextTmpl.Parse(templName, templStr)
|
|
|
|
|
if err != nil {
|
|
|
|
|
fe := herrors.ToFileError("html", err)
|
|
|
|
|
l1, l2 := p.posFromPage(sc.pos).LineNumber, fe.Position().LineNumber
|
|
|
|
|
fe = herrors.ToFileErrorWithLineNumber(fe, l1+l2-1)
|
|
|
|
|
return "", p.errWithFileContext(fe)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} else {
|
|
|
|
|
// Re-use of shortcode defined earlier in the same page.
|
|
|
|
|
var found bool
|
|
|
|
|
tmpl, found = p.s.TextTmpl.Lookup(templName)
|
|
|
|
|
if !found {
|
|
|
|
|
return "", _errors.Errorf("no earlier definition of shortcode %q found", sc.name)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
tmpl = getShortcodeTemplateForTemplateKey(tmplKey, sc.name, p.s.Tmpl)
|
|
|
|
|
}
|
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
if tmpl == nil {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
p.s.Log.ERROR.Printf("Unable to locate template for shortcode %q in page %q", sc.name, p.Path())
|
2018-10-03 08:58:09 -04:00
|
|
|
|
return "", nil
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
2014-02-25 23:57:31 -05:00
|
|
|
|
|
2018-12-21 03:51:15 -05:00
|
|
|
|
data := &ShortcodeWithPage{Ordinal: sc.ordinal, posOffset: sc.pos, Params: sc.params, Page: p, Parent: parent, Name: sc.name}
|
2015-11-20 19:59:54 -05:00
|
|
|
|
if sc.params != nil {
|
|
|
|
|
data.IsNamedParams = reflect.TypeOf(sc.params).Kind() == reflect.Map
|
|
|
|
|
}
|
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
if len(sc.inner) > 0 {
|
|
|
|
|
var inner string
|
|
|
|
|
for _, innerData := range sc.inner {
|
|
|
|
|
switch innerData.(type) {
|
|
|
|
|
case string:
|
|
|
|
|
inner += innerData.(string)
|
2018-04-22 08:07:29 -04:00
|
|
|
|
case *shortcode:
|
2018-10-03 08:58:09 -04:00
|
|
|
|
s, err := renderShortcode(tmplKey, innerData.(*shortcode), data, p)
|
|
|
|
|
if err != nil {
|
|
|
|
|
return "", err
|
|
|
|
|
}
|
|
|
|
|
inner += s
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
default:
|
2017-03-10 14:54:50 -05:00
|
|
|
|
p.s.Log.ERROR.Printf("Illegal state on shortcode rendering of %q in page %q. Illegal type in inner data: %s ",
|
|
|
|
|
sc.name, p.Path(), reflect.TypeOf(innerData))
|
2018-10-03 08:58:09 -04:00
|
|
|
|
return "", nil
|
2014-02-25 23:57:31 -05:00
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if sc.doMarkup {
|
2017-02-04 22:20:06 -05:00
|
|
|
|
newInner := p.s.ContentSpec.RenderBytes(&helpers.RenderingContext{
|
2018-05-04 20:17:16 -04:00
|
|
|
|
Content: []byte(inner),
|
|
|
|
|
PageFmt: p.Markup,
|
2017-02-04 22:20:06 -05:00
|
|
|
|
Cfg: p.Language(),
|
|
|
|
|
DocumentID: p.UniqueID(),
|
|
|
|
|
DocumentName: p.Path(),
|
|
|
|
|
Config: p.getRenderingConfig()})
|
Provide (relative) reference funcs & shortcodes.
- `.Ref` and `.RelRef` take a reference (the logical filename for a
page, including extension and/or a document fragment ID) and return
a permalink (or relative permalink) to the referenced document.
- If the reference is a page name (such as `about.md`), the page
will be discovered and the permalink will be returned: `/about/`
- If the reference is a page name with a fragment (such as
`about.md#who`), the page will be discovered and used to add the
`page.UniqueID()` to the resulting fragment and permalink:
`/about/#who:deadbeef`.
- If the reference is a fragment and `.*Ref` has been called from
a `Node` or `SiteInfo`, it will be returned as is: `#who`.
- If the reference is a fragment and `.*Ref` has been called from
a `Page`, it will be returned with the page’s unique ID:
`#who:deadbeef`.
- `.*Ref` can be called from either `Node`, `SiteInfo` (e.g.,
`Node.Site`), `Page` objects, or `ShortcodeWithPage` objects in
templates.
- `.*Ref` cannot be used in content, so two shortcodes have been
created to provide the functionality to content: `ref` and `relref`.
These are intended to be used within markup, like `[Who]({{% ref
about.md#who %}})` or `<a href="{{% ref about.md#who %}}">Who</a>`.
- There are also `ref` and `relref` template functions (used to create
the shortcodes) that expect a `Page` or `Node` object and the
reference string (e.g., `{{ relref . "about.md" }}` or `{{
"about.md" | ref . }}`). It actually looks for `.*Ref` as defined on
`Node` or `Page` objects.
- Shortcode handling had to use a *differently unique* wrapper in
`createShortcodePlaceholder` because of the way that the `ref` and
`relref` are intended to be used in content.
2014-11-24 01:15:34 -05:00
|
|
|
|
|
|
|
|
|
// If the type is “unknown” or “markdown”, we assume the markdown
|
|
|
|
|
// generation has been performed. Given the input: `a line`, markdown
|
|
|
|
|
// specifies the HTML `<p>a line</p>\n`. When dealing with documents as a
|
|
|
|
|
// whole, this is OK. When dealing with an `{{ .Inner }}` block in Hugo,
|
|
|
|
|
// this is not so good. This code does two things:
|
|
|
|
|
//
|
|
|
|
|
// 1. Check to see if inner has a newline in it. If so, the Inner data is
|
|
|
|
|
// unchanged.
|
|
|
|
|
// 2 If inner does not have a newline, strip the wrapping <p> block and
|
|
|
|
|
// the newline. This was previously tricked out by wrapping shortcode
|
|
|
|
|
// substitutions in <div>HUGOSHORTCODE-1</div> which prevents the
|
|
|
|
|
// generation, but means that you can’t use shortcodes inside of
|
|
|
|
|
// markdown structures itself (e.g., `[foo]({{% ref foo.md %}})`).
|
2018-05-04 20:17:16 -04:00
|
|
|
|
switch p.Markup {
|
Provide (relative) reference funcs & shortcodes.
- `.Ref` and `.RelRef` take a reference (the logical filename for a
page, including extension and/or a document fragment ID) and return
a permalink (or relative permalink) to the referenced document.
- If the reference is a page name (such as `about.md`), the page
will be discovered and the permalink will be returned: `/about/`
- If the reference is a page name with a fragment (such as
`about.md#who`), the page will be discovered and used to add the
`page.UniqueID()` to the resulting fragment and permalink:
`/about/#who:deadbeef`.
- If the reference is a fragment and `.*Ref` has been called from
a `Node` or `SiteInfo`, it will be returned as is: `#who`.
- If the reference is a fragment and `.*Ref` has been called from
a `Page`, it will be returned with the page’s unique ID:
`#who:deadbeef`.
- `.*Ref` can be called from either `Node`, `SiteInfo` (e.g.,
`Node.Site`), `Page` objects, or `ShortcodeWithPage` objects in
templates.
- `.*Ref` cannot be used in content, so two shortcodes have been
created to provide the functionality to content: `ref` and `relref`.
These are intended to be used within markup, like `[Who]({{% ref
about.md#who %}})` or `<a href="{{% ref about.md#who %}}">Who</a>`.
- There are also `ref` and `relref` template functions (used to create
the shortcodes) that expect a `Page` or `Node` object and the
reference string (e.g., `{{ relref . "about.md" }}` or `{{
"about.md" | ref . }}`). It actually looks for `.*Ref` as defined on
`Node` or `Page` objects.
- Shortcode handling had to use a *differently unique* wrapper in
`createShortcodePlaceholder` because of the way that the `ref` and
`relref` are intended to be used in content.
2014-11-24 01:15:34 -05:00
|
|
|
|
case "unknown", "markdown":
|
|
|
|
|
if match, _ := regexp.MatchString(innerNewlineRegexp, inner); !match {
|
|
|
|
|
cleaner, err := regexp.Compile(innerCleanupRegexp)
|
|
|
|
|
|
|
|
|
|
if err == nil {
|
|
|
|
|
newInner = cleaner.ReplaceAll(newInner, []byte(innerCleanupExpand))
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
// TODO(bep) we may have plain text inner templates.
|
Provide (relative) reference funcs & shortcodes.
- `.Ref` and `.RelRef` take a reference (the logical filename for a
page, including extension and/or a document fragment ID) and return
a permalink (or relative permalink) to the referenced document.
- If the reference is a page name (such as `about.md`), the page
will be discovered and the permalink will be returned: `/about/`
- If the reference is a page name with a fragment (such as
`about.md#who`), the page will be discovered and used to add the
`page.UniqueID()` to the resulting fragment and permalink:
`/about/#who:deadbeef`.
- If the reference is a fragment and `.*Ref` has been called from
a `Node` or `SiteInfo`, it will be returned as is: `#who`.
- If the reference is a fragment and `.*Ref` has been called from
a `Page`, it will be returned with the page’s unique ID:
`#who:deadbeef`.
- `.*Ref` can be called from either `Node`, `SiteInfo` (e.g.,
`Node.Site`), `Page` objects, or `ShortcodeWithPage` objects in
templates.
- `.*Ref` cannot be used in content, so two shortcodes have been
created to provide the functionality to content: `ref` and `relref`.
These are intended to be used within markup, like `[Who]({{% ref
about.md#who %}})` or `<a href="{{% ref about.md#who %}}">Who</a>`.
- There are also `ref` and `relref` template functions (used to create
the shortcodes) that expect a `Page` or `Node` object and the
reference string (e.g., `{{ relref . "about.md" }}` or `{{
"about.md" | ref . }}`). It actually looks for `.*Ref` as defined on
`Node` or `Page` objects.
- Shortcode handling had to use a *differently unique* wrapper in
`createShortcodePlaceholder` because of the way that the `ref` and
`relref` are intended to be used in content.
2014-11-24 01:15:34 -05:00
|
|
|
|
data.Inner = template.HTML(newInner)
|
2014-02-25 23:57:31 -05:00
|
|
|
|
} else {
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
data.Inner = template.HTML(inner)
|
2014-02-25 23:57:31 -05:00
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
2014-02-25 23:57:31 -05:00
|
|
|
|
}
|
|
|
|
|
|
2018-11-26 05:01:27 -05:00
|
|
|
|
s, err := renderShortcodeWithPage(tmpl, data)
|
|
|
|
|
|
|
|
|
|
if err != nil && sc.isInline {
|
|
|
|
|
fe := herrors.ToFileError("html", err)
|
|
|
|
|
l1, l2 := p.posFromPage(sc.pos).LineNumber, fe.Position().LineNumber
|
|
|
|
|
fe = herrors.ToFileErrorWithLineNumber(fe, l1+l2-1)
|
|
|
|
|
return "", fe
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return s, err
|
2014-02-25 23:57:31 -05:00
|
|
|
|
}
|
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
// The delta represents new output format-versions of the shortcodes,
|
|
|
|
|
// which, combined with the ones that do not have alternative representations,
|
|
|
|
|
// builds a complete set ready for a full rebuild of the Page content.
|
|
|
|
|
// This method returns false if there are no new shortcode variants in the
|
|
|
|
|
// current rendering context's output format. This mean we can safely reuse
|
|
|
|
|
// the content from the previous output format, if any.
|
|
|
|
|
func (s *shortcodeHandler) updateDelta() bool {
|
|
|
|
|
s.init.Do(func() {
|
2018-11-26 05:01:27 -05:00
|
|
|
|
s.contentShortcodes = s.createShortcodeRenderers(s.p.withoutContent())
|
2017-05-06 14:15:28 -04:00
|
|
|
|
})
|
|
|
|
|
|
2018-04-23 23:57:33 -04:00
|
|
|
|
if !s.p.shouldRenderTo(s.p.s.rc.Format) {
|
|
|
|
|
// TODO(bep) add test for this re translations
|
|
|
|
|
return false
|
|
|
|
|
}
|
|
|
|
|
of := s.p.s.rc.Format
|
|
|
|
|
contentShortcodes := s.contentShortcodesForOutputFormat(of)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
if s.contentShortcodesDelta == nil || s.contentShortcodesDelta.Len() == 0 {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
s.contentShortcodesDelta = contentShortcodes
|
|
|
|
|
return true
|
2014-01-29 17:50:31 -05:00
|
|
|
|
}
|
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
delta := newOrderedMap()
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
for _, k := range contentShortcodes.Keys() {
|
|
|
|
|
if !s.contentShortcodesDelta.Contains(k) {
|
|
|
|
|
v, _ := contentShortcodes.Get(k)
|
|
|
|
|
delta.Add(k, v)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
2016-03-17 10:51:52 -04:00
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
s.contentShortcodesDelta = delta
|
2016-03-17 10:51:52 -04:00
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
return delta.Len() > 0
|
2016-03-17 10:51:52 -04:00
|
|
|
|
}
|
|
|
|
|
|
2018-04-23 23:57:33 -04:00
|
|
|
|
func (s *shortcodeHandler) clearDelta() {
|
|
|
|
|
if s == nil {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
s.contentShortcodesDelta = newOrderedMap()
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
func (s *shortcodeHandler) contentShortcodesForOutputFormat(f output.Format) *orderedMap {
|
|
|
|
|
contentShortcodesForOuputFormat := newOrderedMap()
|
2017-07-02 04:46:28 -04:00
|
|
|
|
lang := s.p.Lang()
|
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
for _, key := range s.shortcodes.Keys() {
|
|
|
|
|
shortcodePlaceholder := key.(string)
|
2016-08-01 17:04:44 -04:00
|
|
|
|
|
2017-07-02 04:46:28 -04:00
|
|
|
|
key := newScKeyFromLangAndOutputFormat(lang, f, shortcodePlaceholder)
|
2018-04-22 08:07:29 -04:00
|
|
|
|
renderFn, found := s.contentShortcodes.Get(key)
|
2016-08-01 17:04:44 -04:00
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
if !found {
|
|
|
|
|
key.OutputFormat = ""
|
2018-04-22 08:07:29 -04:00
|
|
|
|
renderFn, found = s.contentShortcodes.Get(key)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Fall back to HTML
|
|
|
|
|
if !found && key.Suffix != "html" {
|
|
|
|
|
key.Suffix = "html"
|
2018-04-22 08:07:29 -04:00
|
|
|
|
renderFn, found = s.contentShortcodes.Get(key)
|
2019-01-31 05:53:21 -05:00
|
|
|
|
if !found {
|
|
|
|
|
key.OutputFormat = "HTML"
|
|
|
|
|
renderFn, found = s.contentShortcodes.Get(key)
|
|
|
|
|
}
|
2017-05-06 14:15:28 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if !found {
|
|
|
|
|
panic(fmt.Sprintf("Shortcode %q could not be found", shortcodePlaceholder))
|
|
|
|
|
}
|
2018-04-22 08:07:29 -04:00
|
|
|
|
contentShortcodesForOuputFormat.Add(newScKeyFromLangAndOutputFormat(lang, f, shortcodePlaceholder), renderFn)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return contentShortcodesForOuputFormat
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-19 12:06:40 -04:00
|
|
|
|
func (s *shortcodeHandler) executeShortcodesForDelta(p *PageWithoutContent) error {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
for _, k := range s.contentShortcodesDelta.Keys() {
|
|
|
|
|
render := s.contentShortcodesDelta.getShortcodeRenderer(k)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
renderedShortcode, err := render()
|
2016-08-01 17:04:44 -04:00
|
|
|
|
if err != nil {
|
2018-10-21 06:20:21 -04:00
|
|
|
|
sc := s.shortcodes.getShortcode(k.(scKey).ShortcodePlaceholder)
|
|
|
|
|
if sc != nil {
|
2018-11-01 05:39:44 -04:00
|
|
|
|
err = p.errWithFileContext(p.parseError(_errors.Wrapf(err, "failed to render shortcode %q", sc.name), p.source.parsed.Input(), sc.pos))
|
2018-10-21 06:20:21 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
p.s.SendError(err)
|
|
|
|
|
continue
|
2016-08-01 17:04:44 -04:00
|
|
|
|
}
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
s.renderedShortcodes[k.(scKey).ShortcodePlaceholder] = renderedShortcode
|
2016-08-01 17:04:44 -04:00
|
|
|
|
}
|
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
return nil
|
|
|
|
|
|
2016-08-01 17:04:44 -04:00
|
|
|
|
}
|
|
|
|
|
|
2018-11-26 05:01:27 -05:00
|
|
|
|
func (s *shortcodeHandler) createShortcodeRenderers(p *PageWithoutContent) *orderedMap {
|
2017-05-05 03:24:37 -04:00
|
|
|
|
|
2018-04-22 08:07:29 -04:00
|
|
|
|
shortcodeRenderers := newOrderedMap()
|
2016-03-17 10:51:52 -04:00
|
|
|
|
|
2018-11-26 05:01:27 -05:00
|
|
|
|
for _, k := range s.shortcodes.Keys() {
|
|
|
|
|
v := s.shortcodes.getShortcode(k)
|
|
|
|
|
prepared := s.prepareShortcodeForPage(k.(string), v, nil, p)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
for kk, vv := range prepared {
|
2018-04-22 08:07:29 -04:00
|
|
|
|
shortcodeRenderers.Add(kk, vv)
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
2014-01-29 17:50:31 -05:00
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
return shortcodeRenderers
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
|
|
|
|
|
2016-03-24 09:11:04 -04:00
|
|
|
|
var errShortCodeIllegalState = errors.New("Illegal shortcode state")
|
2015-08-07 14:08:23 -04:00
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
// pageTokens state:
|
|
|
|
|
// - before: positioned just before the shortcode start
|
|
|
|
|
// - after: shortcode(s) consumed (plural when they are nested)
|
2018-10-18 04:21:23 -04:00
|
|
|
|
func (s *shortcodeHandler) extractShortcode(ordinal int, pt *pageparser.Iterator, p *Page) (*shortcode, error) {
|
2018-04-23 02:09:56 -04:00
|
|
|
|
sc := &shortcode{ordinal: ordinal}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
var isInner = false
|
|
|
|
|
|
|
|
|
|
var cnt = 0
|
2018-04-23 02:09:56 -04:00
|
|
|
|
var nestedOrdinal = 0
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
2018-10-21 06:20:21 -04:00
|
|
|
|
fail := func(err error, i pageparser.Item) error {
|
2018-11-01 05:39:44 -04:00
|
|
|
|
return p.parseError(err, pt.Input(), i.Pos)
|
2018-10-03 08:58:09 -04:00
|
|
|
|
}
|
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
Loop:
|
|
|
|
|
for {
|
2018-10-17 06:57:09 -04:00
|
|
|
|
currItem := pt.Next()
|
|
|
|
|
switch {
|
|
|
|
|
case currItem.IsLeftShortcodeDelim():
|
2018-11-26 05:01:27 -05:00
|
|
|
|
if sc.pos == 0 {
|
|
|
|
|
sc.pos = currItem.Pos
|
|
|
|
|
}
|
2018-10-17 06:57:09 -04:00
|
|
|
|
next := pt.Peek()
|
|
|
|
|
if next.IsShortcodeClose() {
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
continue
|
2014-01-29 17:50:31 -05:00
|
|
|
|
}
|
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
if cnt > 0 {
|
|
|
|
|
// nested shortcode; append it to inner content
|
2018-10-18 04:21:23 -04:00
|
|
|
|
pt.Backup()
|
2018-04-23 02:09:56 -04:00
|
|
|
|
nested, err := s.extractShortcode(nestedOrdinal, pt, p)
|
|
|
|
|
nestedOrdinal++
|
2017-03-10 14:54:50 -05:00
|
|
|
|
if nested.name != "" {
|
|
|
|
|
s.nameSet[nested.name] = true
|
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
if err == nil {
|
|
|
|
|
sc.inner = append(sc.inner, nested)
|
|
|
|
|
} else {
|
|
|
|
|
return sc, err
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-29 17:50:31 -05:00
|
|
|
|
} else {
|
2018-10-17 06:57:09 -04:00
|
|
|
|
sc.doMarkup = currItem.IsShortcodeMarkupDelimiter()
|
2014-01-29 17:50:31 -05:00
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
|
|
|
|
cnt++
|
|
|
|
|
|
2018-10-17 06:57:09 -04:00
|
|
|
|
case currItem.IsRightShortcodeDelim():
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
// we trust the template on this:
|
|
|
|
|
// if there's no inner, we're done
|
2018-11-26 05:01:27 -05:00
|
|
|
|
if !sc.isInline && !isInner {
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
return sc, nil
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-17 06:57:09 -04:00
|
|
|
|
case currItem.IsShortcodeClose():
|
|
|
|
|
next := pt.Peek()
|
2018-11-26 05:01:27 -05:00
|
|
|
|
if !sc.isInline && !isInner {
|
2018-10-17 06:57:09 -04:00
|
|
|
|
if next.IsError() {
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
// return that error, more specific
|
|
|
|
|
continue
|
|
|
|
|
}
|
2018-10-21 06:20:21 -04:00
|
|
|
|
|
|
|
|
|
return sc, fail(_errors.Errorf("shortcode %q has no .Inner, yet a closing tag was provided", next.Val), next)
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
2018-10-17 06:57:09 -04:00
|
|
|
|
if next.IsRightShortcodeDelim() {
|
2015-03-02 15:23:16 -05:00
|
|
|
|
// self-closing
|
2018-10-17 06:57:09 -04:00
|
|
|
|
pt.Consume(1)
|
2015-03-02 15:23:16 -05:00
|
|
|
|
} else {
|
2018-11-26 05:01:27 -05:00
|
|
|
|
sc.isClosing = true
|
2018-10-17 06:57:09 -04:00
|
|
|
|
pt.Consume(2)
|
2015-03-02 15:23:16 -05:00
|
|
|
|
}
|
|
|
|
|
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
return sc, nil
|
2018-10-17 06:57:09 -04:00
|
|
|
|
case currItem.IsText():
|
2018-10-18 03:47:39 -04:00
|
|
|
|
sc.inner = append(sc.inner, currItem.ValStr())
|
2018-10-17 06:57:09 -04:00
|
|
|
|
case currItem.IsShortcodeName():
|
2018-10-18 03:47:39 -04:00
|
|
|
|
sc.name = currItem.ValStr()
|
2017-05-06 14:15:28 -04:00
|
|
|
|
// We pick the first template for an arbitrary output format
|
|
|
|
|
// if more than one. It is "all inner or no inner".
|
|
|
|
|
tmpl := getShortcodeTemplateForTemplateKey(scKey{}, sc.name, p.s.Tmpl)
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
if tmpl == nil {
|
2018-10-21 06:20:21 -04:00
|
|
|
|
return sc, fail(_errors.Errorf("template for shortcode %q not found", sc.name), currItem)
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
2015-11-21 14:03:18 -05:00
|
|
|
|
|
2015-11-21 17:29:58 -05:00
|
|
|
|
var err error
|
Add Hugo Piper with SCSS support and much more
Before this commit, you would have to use page bundles to do image processing etc. in Hugo.
This commit adds
* A new `/assets` top-level project or theme dir (configurable via `assetDir`)
* A new template func, `resources.Get` which can be used to "get a resource" that can be further processed.
This means that you can now do this in your templates (or shortcodes):
```bash
{{ $sunset := (resources.Get "images/sunset.jpg").Fill "300x200" }}
```
This also adds a new `extended` build tag that enables powerful SCSS/SASS support with source maps. To compile this from source, you will also need a C compiler installed:
```
HUGO_BUILD_TAGS=extended mage install
```
Note that you can use output of the SCSS processing later in a non-SCSSS-enabled Hugo.
The `SCSS` processor is a _Resource transformation step_ and it can be chained with the many others in a pipeline:
```bash
{{ $css := resources.Get "styles.scss" | resources.ToCSS | resources.PostCSS | resources.Minify | resources.Fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
The transformation funcs above have aliases, so it can be shortened to:
```bash
{{ $css := resources.Get "styles.scss" | toCSS | postCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
A quick tip would be to avoid the fingerprinting part, and possibly also the not-superfast `postCSS` when you're doing development, as it allows Hugo to be smarter about the rebuilding.
Documentation will follow, but have a look at the demo repo in https://github.com/bep/hugo-sass-test
New functions to create `Resource` objects:
* `resources.Get` (see above)
* `resources.FromString`: Create a Resource from a string.
New `Resource` transformation funcs:
* `resources.ToCSS`: Compile `SCSS` or `SASS` into `CSS`.
* `resources.PostCSS`: Process your CSS with PostCSS. Config file support (project or theme or passed as an option).
* `resources.Minify`: Currently supports `css`, `js`, `json`, `html`, `svg`, `xml`.
* `resources.Fingerprint`: Creates a fingerprinted version of the given Resource with Subresource Integrity..
* `resources.Concat`: Concatenates a list of Resource objects. Think of this as a poor man's bundler.
* `resources.ExecuteAsTemplate`: Parses and executes the given Resource and data context (e.g. .Site) as a Go template.
Fixes #4381
Fixes #4903
Fixes #4858
2018-02-20 04:02:14 -05:00
|
|
|
|
isInner, err = isInnerShortcode(tmpl.(tpl.TemplateExecutor))
|
2015-11-21 17:29:58 -05:00
|
|
|
|
if err != nil {
|
2018-10-21 06:20:21 -04:00
|
|
|
|
return sc, fail(_errors.Wrapf(err, "failed to handle template for shortcode %q", sc.name), currItem)
|
2015-11-15 14:53:12 -05:00
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
2018-11-26 05:01:27 -05:00
|
|
|
|
case currItem.IsInlineShortcodeName():
|
|
|
|
|
sc.name = currItem.ValStr()
|
|
|
|
|
sc.isInline = true
|
|
|
|
|
|
2018-10-17 06:57:09 -04:00
|
|
|
|
case currItem.IsShortcodeParam():
|
|
|
|
|
if !pt.IsValueNext() {
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
continue
|
2018-10-17 06:57:09 -04:00
|
|
|
|
} else if pt.Peek().IsShortcodeParamVal() {
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
// named params
|
|
|
|
|
if sc.params == nil {
|
|
|
|
|
params := make(map[string]string)
|
2018-10-18 03:47:39 -04:00
|
|
|
|
params[currItem.ValStr()] = pt.Next().ValStr()
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
sc.params = params
|
2014-01-29 17:50:31 -05:00
|
|
|
|
} else {
|
2015-08-07 14:08:23 -04:00
|
|
|
|
if params, ok := sc.params.(map[string]string); ok {
|
2018-10-18 03:47:39 -04:00
|
|
|
|
params[currItem.ValStr()] = pt.Next().ValStr()
|
2015-08-07 14:08:23 -04:00
|
|
|
|
} else {
|
2016-03-24 09:11:04 -04:00
|
|
|
|
return sc, errShortCodeIllegalState
|
2015-08-07 14:08:23 -04:00
|
|
|
|
}
|
|
|
|
|
|
2014-01-29 17:50:31 -05:00
|
|
|
|
}
|
|
|
|
|
} else {
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
// positional params
|
|
|
|
|
if sc.params == nil {
|
|
|
|
|
var params []string
|
2018-10-18 03:47:39 -04:00
|
|
|
|
params = append(params, currItem.ValStr())
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
sc.params = params
|
2014-01-29 17:50:31 -05:00
|
|
|
|
} else {
|
2015-08-07 14:08:23 -04:00
|
|
|
|
if params, ok := sc.params.([]string); ok {
|
2018-10-18 03:47:39 -04:00
|
|
|
|
params = append(params, currItem.ValStr())
|
2015-08-07 14:08:23 -04:00
|
|
|
|
sc.params = params
|
|
|
|
|
} else {
|
2016-03-24 09:11:04 -04:00
|
|
|
|
return sc, errShortCodeIllegalState
|
2015-08-07 14:08:23 -04:00
|
|
|
|
}
|
|
|
|
|
|
2014-01-29 17:50:31 -05:00
|
|
|
|
}
|
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
2018-10-17 06:57:09 -04:00
|
|
|
|
case currItem.IsDone():
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
// handled by caller
|
2018-10-17 06:57:09 -04:00
|
|
|
|
pt.Backup()
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
break Loop
|
|
|
|
|
|
2014-01-29 17:50:31 -05:00
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
|
|
|
|
return sc, nil
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-18 03:47:39 -04:00
|
|
|
|
var shortCodeStart = []byte("{{")
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
|
|
|
|
// Replace prefixed shortcode tokens (HUGOSHORTCODE-1, HUGOSHORTCODE-2) with the real content.
|
2015-10-20 14:35:12 -04:00
|
|
|
|
// Note: This function will rewrite the input slice.
|
2015-06-21 07:08:30 -04:00
|
|
|
|
func replaceShortcodeTokens(source []byte, prefix string, replacements map[string]string) ([]byte, error) {
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
|
2015-06-21 07:08:30 -04:00
|
|
|
|
if len(replacements) == 0 {
|
|
|
|
|
return source, nil
|
2014-01-29 17:50:31 -05:00
|
|
|
|
}
|
|
|
|
|
|
2015-06-21 07:08:30 -04:00
|
|
|
|
start := 0
|
|
|
|
|
|
2016-09-08 15:23:01 -04:00
|
|
|
|
pre := []byte("HAHA" + prefix)
|
|
|
|
|
post := []byte("HBHB")
|
2015-06-21 07:08:30 -04:00
|
|
|
|
pStart := []byte("<p>")
|
|
|
|
|
pEnd := []byte("</p>")
|
|
|
|
|
|
|
|
|
|
k := bytes.Index(source[start:], pre)
|
|
|
|
|
|
|
|
|
|
for k != -1 {
|
|
|
|
|
j := start + k
|
|
|
|
|
postIdx := bytes.Index(source[j:], post)
|
|
|
|
|
if postIdx < 0 {
|
|
|
|
|
// this should never happen, but let the caller decide to panic or not
|
|
|
|
|
return nil, errors.New("illegal state in content; shortcode token missing end delim")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
end := j + postIdx + 4
|
|
|
|
|
|
|
|
|
|
newVal := []byte(replacements[string(source[j:end])])
|
|
|
|
|
|
|
|
|
|
// Issue #1148: Check for wrapping p-tags <p>
|
|
|
|
|
if j >= 3 && bytes.Equal(source[j-3:j], pStart) {
|
2018-08-16 20:17:27 -04:00
|
|
|
|
if (k+4) < len(source) && bytes.Equal(source[end:end+4], pEnd) {
|
2015-06-21 07:08:30 -04:00
|
|
|
|
j -= 3
|
|
|
|
|
end += 4
|
2015-01-28 22:11:41 -05:00
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
Provide (relative) reference funcs & shortcodes.
- `.Ref` and `.RelRef` take a reference (the logical filename for a
page, including extension and/or a document fragment ID) and return
a permalink (or relative permalink) to the referenced document.
- If the reference is a page name (such as `about.md`), the page
will be discovered and the permalink will be returned: `/about/`
- If the reference is a page name with a fragment (such as
`about.md#who`), the page will be discovered and used to add the
`page.UniqueID()` to the resulting fragment and permalink:
`/about/#who:deadbeef`.
- If the reference is a fragment and `.*Ref` has been called from
a `Node` or `SiteInfo`, it will be returned as is: `#who`.
- If the reference is a fragment and `.*Ref` has been called from
a `Page`, it will be returned with the page’s unique ID:
`#who:deadbeef`.
- `.*Ref` can be called from either `Node`, `SiteInfo` (e.g.,
`Node.Site`), `Page` objects, or `ShortcodeWithPage` objects in
templates.
- `.*Ref` cannot be used in content, so two shortcodes have been
created to provide the functionality to content: `ref` and `relref`.
These are intended to be used within markup, like `[Who]({{% ref
about.md#who %}})` or `<a href="{{% ref about.md#who %}}">Who</a>`.
- There are also `ref` and `relref` template functions (used to create
the shortcodes) that expect a `Page` or `Node` object and the
reference string (e.g., `{{ relref . "about.md" }}` or `{{
"about.md" | ref . }}`). It actually looks for `.*Ref` as defined on
`Node` or `Page` objects.
- Shortcode handling had to use a *differently unique* wrapper in
`createShortcodePlaceholder` because of the way that the `ref` and
`relref` are intended to be used in content.
2014-11-24 01:15:34 -05:00
|
|
|
|
|
2015-10-20 14:35:12 -04:00
|
|
|
|
// This and other cool slice tricks: https://github.com/golang/go/wiki/SliceTricks
|
|
|
|
|
source = append(source[:j], append(newVal, source[end:]...)...)
|
2016-02-25 15:31:22 -05:00
|
|
|
|
start = j
|
2015-06-21 07:08:30 -04:00
|
|
|
|
k = bytes.Index(source[start:], pre)
|
2015-06-22 13:40:12 -04:00
|
|
|
|
|
2015-10-20 14:35:12 -04:00
|
|
|
|
}
|
2015-06-22 13:40:12 -04:00
|
|
|
|
|
2015-10-20 14:35:12 -04:00
|
|
|
|
return source, nil
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
2013-07-04 11:32:55 -04:00
|
|
|
|
|
Add Hugo Piper with SCSS support and much more
Before this commit, you would have to use page bundles to do image processing etc. in Hugo.
This commit adds
* A new `/assets` top-level project or theme dir (configurable via `assetDir`)
* A new template func, `resources.Get` which can be used to "get a resource" that can be further processed.
This means that you can now do this in your templates (or shortcodes):
```bash
{{ $sunset := (resources.Get "images/sunset.jpg").Fill "300x200" }}
```
This also adds a new `extended` build tag that enables powerful SCSS/SASS support with source maps. To compile this from source, you will also need a C compiler installed:
```
HUGO_BUILD_TAGS=extended mage install
```
Note that you can use output of the SCSS processing later in a non-SCSSS-enabled Hugo.
The `SCSS` processor is a _Resource transformation step_ and it can be chained with the many others in a pipeline:
```bash
{{ $css := resources.Get "styles.scss" | resources.ToCSS | resources.PostCSS | resources.Minify | resources.Fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
The transformation funcs above have aliases, so it can be shortened to:
```bash
{{ $css := resources.Get "styles.scss" | toCSS | postCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
A quick tip would be to avoid the fingerprinting part, and possibly also the not-superfast `postCSS` when you're doing development, as it allows Hugo to be smarter about the rebuilding.
Documentation will follow, but have a look at the demo repo in https://github.com/bep/hugo-sass-test
New functions to create `Resource` objects:
* `resources.Get` (see above)
* `resources.FromString`: Create a Resource from a string.
New `Resource` transformation funcs:
* `resources.ToCSS`: Compile `SCSS` or `SASS` into `CSS`.
* `resources.PostCSS`: Process your CSS with PostCSS. Config file support (project or theme or passed as an option).
* `resources.Minify`: Currently supports `css`, `js`, `json`, `html`, `svg`, `xml`.
* `resources.Fingerprint`: Creates a fingerprinted version of the given Resource with Subresource Integrity..
* `resources.Concat`: Concatenates a list of Resource objects. Think of this as a poor man's bundler.
* `resources.ExecuteAsTemplate`: Parses and executes the given Resource and data context (e.g. .Site) as a Go template.
Fixes #4381
Fixes #4903
Fixes #4858
2018-02-20 04:02:14 -05:00
|
|
|
|
func getShortcodeTemplateForTemplateKey(key scKey, shortcodeName string, t tpl.TemplateFinder) tpl.Template {
|
2017-03-27 14:43:49 -04:00
|
|
|
|
isInnerShortcodeCache.RLock()
|
|
|
|
|
defer isInnerShortcodeCache.RUnlock()
|
|
|
|
|
|
2017-05-06 14:15:28 -04:00
|
|
|
|
var names []string
|
|
|
|
|
|
|
|
|
|
suffix := strings.ToLower(key.Suffix)
|
|
|
|
|
outFormat := strings.ToLower(key.OutputFormat)
|
2017-07-02 04:46:28 -04:00
|
|
|
|
lang := strings.ToLower(key.Lang)
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
|
|
|
|
if outFormat != "" && suffix != "" {
|
2017-07-02 04:46:28 -04:00
|
|
|
|
if lang != "" {
|
|
|
|
|
names = append(names, fmt.Sprintf("%s.%s.%s.%s", shortcodeName, lang, outFormat, suffix))
|
|
|
|
|
}
|
2017-05-06 14:15:28 -04:00
|
|
|
|
names = append(names, fmt.Sprintf("%s.%s.%s", shortcodeName, outFormat, suffix))
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
2017-05-06 14:15:28 -04:00
|
|
|
|
|
|
|
|
|
if suffix != "" {
|
2017-07-02 04:46:28 -04:00
|
|
|
|
if lang != "" {
|
|
|
|
|
names = append(names, fmt.Sprintf("%s.%s.%s", shortcodeName, lang, suffix))
|
|
|
|
|
}
|
2017-05-06 14:15:28 -04:00
|
|
|
|
names = append(names, fmt.Sprintf("%s.%s", shortcodeName, suffix))
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
names = append(names, shortcodeName)
|
|
|
|
|
|
|
|
|
|
for _, name := range names {
|
|
|
|
|
|
Add Hugo Piper with SCSS support and much more
Before this commit, you would have to use page bundles to do image processing etc. in Hugo.
This commit adds
* A new `/assets` top-level project or theme dir (configurable via `assetDir`)
* A new template func, `resources.Get` which can be used to "get a resource" that can be further processed.
This means that you can now do this in your templates (or shortcodes):
```bash
{{ $sunset := (resources.Get "images/sunset.jpg").Fill "300x200" }}
```
This also adds a new `extended` build tag that enables powerful SCSS/SASS support with source maps. To compile this from source, you will also need a C compiler installed:
```
HUGO_BUILD_TAGS=extended mage install
```
Note that you can use output of the SCSS processing later in a non-SCSSS-enabled Hugo.
The `SCSS` processor is a _Resource transformation step_ and it can be chained with the many others in a pipeline:
```bash
{{ $css := resources.Get "styles.scss" | resources.ToCSS | resources.PostCSS | resources.Minify | resources.Fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
The transformation funcs above have aliases, so it can be shortened to:
```bash
{{ $css := resources.Get "styles.scss" | toCSS | postCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
A quick tip would be to avoid the fingerprinting part, and possibly also the not-superfast `postCSS` when you're doing development, as it allows Hugo to be smarter about the rebuilding.
Documentation will follow, but have a look at the demo repo in https://github.com/bep/hugo-sass-test
New functions to create `Resource` objects:
* `resources.Get` (see above)
* `resources.FromString`: Create a Resource from a string.
New `Resource` transformation funcs:
* `resources.ToCSS`: Compile `SCSS` or `SASS` into `CSS`.
* `resources.PostCSS`: Process your CSS with PostCSS. Config file support (project or theme or passed as an option).
* `resources.Minify`: Currently supports `css`, `js`, `json`, `html`, `svg`, `xml`.
* `resources.Fingerprint`: Creates a fingerprinted version of the given Resource with Subresource Integrity..
* `resources.Concat`: Concatenates a list of Resource objects. Think of this as a poor man's bundler.
* `resources.ExecuteAsTemplate`: Parses and executes the given Resource and data context (e.g. .Site) as a Go template.
Fixes #4381
Fixes #4903
Fixes #4858
2018-02-20 04:02:14 -05:00
|
|
|
|
if x, found := t.Lookup("shortcodes/" + name); found {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
return x
|
|
|
|
|
}
|
Add Hugo Piper with SCSS support and much more
Before this commit, you would have to use page bundles to do image processing etc. in Hugo.
This commit adds
* A new `/assets` top-level project or theme dir (configurable via `assetDir`)
* A new template func, `resources.Get` which can be used to "get a resource" that can be further processed.
This means that you can now do this in your templates (or shortcodes):
```bash
{{ $sunset := (resources.Get "images/sunset.jpg").Fill "300x200" }}
```
This also adds a new `extended` build tag that enables powerful SCSS/SASS support with source maps. To compile this from source, you will also need a C compiler installed:
```
HUGO_BUILD_TAGS=extended mage install
```
Note that you can use output of the SCSS processing later in a non-SCSSS-enabled Hugo.
The `SCSS` processor is a _Resource transformation step_ and it can be chained with the many others in a pipeline:
```bash
{{ $css := resources.Get "styles.scss" | resources.ToCSS | resources.PostCSS | resources.Minify | resources.Fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
The transformation funcs above have aliases, so it can be shortened to:
```bash
{{ $css := resources.Get "styles.scss" | toCSS | postCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
A quick tip would be to avoid the fingerprinting part, and possibly also the not-superfast `postCSS` when you're doing development, as it allows Hugo to be smarter about the rebuilding.
Documentation will follow, but have a look at the demo repo in https://github.com/bep/hugo-sass-test
New functions to create `Resource` objects:
* `resources.Get` (see above)
* `resources.FromString`: Create a Resource from a string.
New `Resource` transformation funcs:
* `resources.ToCSS`: Compile `SCSS` or `SASS` into `CSS`.
* `resources.PostCSS`: Process your CSS with PostCSS. Config file support (project or theme or passed as an option).
* `resources.Minify`: Currently supports `css`, `js`, `json`, `html`, `svg`, `xml`.
* `resources.Fingerprint`: Creates a fingerprinted version of the given Resource with Subresource Integrity..
* `resources.Concat`: Concatenates a list of Resource objects. Think of this as a poor man's bundler.
* `resources.ExecuteAsTemplate`: Parses and executes the given Resource and data context (e.g. .Site) as a Go template.
Fixes #4381
Fixes #4903
Fixes #4858
2018-02-20 04:02:14 -05:00
|
|
|
|
if x, found := t.Lookup("theme/shortcodes/" + name); found {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
return x
|
|
|
|
|
}
|
Add Hugo Piper with SCSS support and much more
Before this commit, you would have to use page bundles to do image processing etc. in Hugo.
This commit adds
* A new `/assets` top-level project or theme dir (configurable via `assetDir`)
* A new template func, `resources.Get` which can be used to "get a resource" that can be further processed.
This means that you can now do this in your templates (or shortcodes):
```bash
{{ $sunset := (resources.Get "images/sunset.jpg").Fill "300x200" }}
```
This also adds a new `extended` build tag that enables powerful SCSS/SASS support with source maps. To compile this from source, you will also need a C compiler installed:
```
HUGO_BUILD_TAGS=extended mage install
```
Note that you can use output of the SCSS processing later in a non-SCSSS-enabled Hugo.
The `SCSS` processor is a _Resource transformation step_ and it can be chained with the many others in a pipeline:
```bash
{{ $css := resources.Get "styles.scss" | resources.ToCSS | resources.PostCSS | resources.Minify | resources.Fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
The transformation funcs above have aliases, so it can be shortened to:
```bash
{{ $css := resources.Get "styles.scss" | toCSS | postCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
A quick tip would be to avoid the fingerprinting part, and possibly also the not-superfast `postCSS` when you're doing development, as it allows Hugo to be smarter about the rebuilding.
Documentation will follow, but have a look at the demo repo in https://github.com/bep/hugo-sass-test
New functions to create `Resource` objects:
* `resources.Get` (see above)
* `resources.FromString`: Create a Resource from a string.
New `Resource` transformation funcs:
* `resources.ToCSS`: Compile `SCSS` or `SASS` into `CSS`.
* `resources.PostCSS`: Process your CSS with PostCSS. Config file support (project or theme or passed as an option).
* `resources.Minify`: Currently supports `css`, `js`, `json`, `html`, `svg`, `xml`.
* `resources.Fingerprint`: Creates a fingerprinted version of the given Resource with Subresource Integrity..
* `resources.Concat`: Concatenates a list of Resource objects. Think of this as a poor man's bundler.
* `resources.ExecuteAsTemplate`: Parses and executes the given Resource and data context (e.g. .Site) as a Go template.
Fixes #4381
Fixes #4903
Fixes #4858
2018-02-20 04:02:14 -05:00
|
|
|
|
if x, found := t.Lookup("_internal/shortcodes/" + name); found {
|
2017-05-06 14:15:28 -04:00
|
|
|
|
return x
|
|
|
|
|
}
|
Shortcode rewrite, take 2
This commit contains a restructuring and partial rewrite of the shortcode handling.
Prior to this commit rendering of the page content was mingled with handling of the shortcodes. This led to several oddities.
The new flow is:
1. Shortcodes are extracted from page and replaced with placeholders.
2. Shortcodes are processed and rendered
3. Page is processed
4. The placeholders are replaced with the rendered shortcodes
The handling of summaries is also made simpler by this.
This commit also introduces some other chenges:
1. distinction between shortcodes that need further processing and those who do not:
* `{{< >}}`: Typically raw HTML. Will not be processed.
* `{{% %}}`: Will be processed by the page's markup engine (Markdown or (infuture) Asciidoctor)
The above also involves a new shortcode-parser, with lexical scanning inspired by Rob Pike's talk called "Lexical Scanning in Go",
which should be easier to understand, give better error messages and perform better.
2. If you want to exclude a shortcode from being processed (for documentation etc.), the inner part of the shorcode must be commented out, i.e. `{{%/* movie 47238zzb */%}}`. See the updated shortcode section in the documentation for further examples.
The new parser supports nested shortcodes. This isn't new, but has two related design choices worth mentioning:
* The shortcodes will be rendered individually, so If both `{{< >}}` and `{{% %}}` are used in the nested hierarchy, one will be passed through the page's markdown processor, the other not.
* To avoid potential costly overhead of always looking far ahead for a possible closing tag, this implementation looks at the template itself, and is branded as a container with inner content if it contains a reference to `.Inner`
Fixes #565
Fixes #480
Fixes #461
And probably some others.
2014-10-27 16:48:30 -04:00
|
|
|
|
}
|
2017-05-06 14:15:28 -04:00
|
|
|
|
return nil
|
2013-07-04 11:32:55 -04:00
|
|
|
|
}
|
|
|
|
|
|
2018-10-03 08:58:09 -04:00
|
|
|
|
func renderShortcodeWithPage(tmpl tpl.Template, data *ShortcodeWithPage) (string, error) {
|
2015-01-30 14:19:46 -05:00
|
|
|
|
buffer := bp.GetBuffer()
|
|
|
|
|
defer bp.PutBuffer(buffer)
|
|
|
|
|
|
2016-04-09 08:25:33 -04:00
|
|
|
|
isInnerShortcodeCache.RLock()
|
2014-01-29 17:50:31 -05:00
|
|
|
|
err := tmpl.Execute(buffer, data)
|
2016-04-09 08:25:33 -04:00
|
|
|
|
isInnerShortcodeCache.RUnlock()
|
2014-01-29 17:50:31 -05:00
|
|
|
|
if err != nil {
|
2018-11-26 05:01:27 -05:00
|
|
|
|
return "", _errors.Wrap(err, "failed to process shortcode")
|
2014-01-29 17:50:31 -05:00
|
|
|
|
}
|
2018-10-03 08:58:09 -04:00
|
|
|
|
return buffer.String(), nil
|
2013-07-04 11:32:55 -04:00
|
|
|
|
}
|