This commit adds a `GitInfo` object to `Page` if `EnableGitInfo` is set.
It then also sets `Lastmod` for the given `Page` to the author date provided by Git.
The Git integrations should be fairly performant, but it adds "some time" to the build, somewhat depending on the Git history size.
If you want, you can run without during development and turn it on when deploying to the live server: `hugo --enableGitInfo`.
Fixes#2102
- removed comma on line 16 to avoid confusion between clauses
- added period to line 24 for consistency
- clarified "read on" on line 30 to follow style above it while
also verbally writing what the author seems to intend
- removed "You probably know what to do." on line 30 due to wordiness
that could lead to confusion and a drag in reading speed
- changed preposition into intended infinitive for syntactical clarity
- removed "easily" as it doesn't describe anything technical and is
confusing (which is why the author may have used a preposition)
All config variables starts with low-case and uses camelCase.
If there is abbreviation at the beginning of the name, the whole
abbreviation will be written in low-case.
If there is abbreviation at the end of the name, the
whole abbreviation will be written in upper-case.
For example, rssURI.
This change adds a canonical alias.html template that is used for page
redirects, and passes the page as data to the template under .Page
Fixes#2533Closes#2576
Organize CSS and Javascript files into directories, separating vendor
source code from home-grown.
Separate new properties and selectors in Bootstrap CSS (already edited
for Hugo) from:
1. Original property values; and
2. Changed property values.
For the home page:
1. Clarify the English text;
2. Add some element names to classes in CSS selectors (to speed loading);
3. Document the Owl Carousel and Highlight.js versions;
4. Add Owl Carousel's license;
5. Restore HTML comments to browser source views;
6. Make the beginning GitHub button transparent on focus (like the others);
7. For the final, colored Twitter and Github buttons:
a. Remove the dotted box on focus; and
b. Color them green on active.
8. To increase (layout/) source readability:
a. Place `class` attributes before `href` attributes;
b. In `class` attributes, place more-specific class names before
less-specific; and
c. Comment the beginnings and ends of Bootstrap rows.
9. To increase understandability during development:
a. Document the meaning of CSS file, `HPstyles` by renaming it to
`home-page-style`;
b. Move inline styling to CSS stylesheets;
c. Separate @media queries to a file;
d. Separate the inline Owl Carousel custom Javascript to a file;
e. Use regular Owl Carousel CSS files instead of minified ones; and
f. Rename the wide, landscape desk background image filename from
`desk-long` to `desk-wide`.
There were some breaking changes etc. that is too late to fix for 0.17.
Let us think this through and add proper author support for Hugo 0.18.
Fixes#2464
Revert "docs: Add documentation for author profiles"
This reverts commit b6673e5309.
Revert "Add First Class Author Support"
This reverts commit cf978c0649.
* Fall back to default language on missing translation file
* Add a i18n-warnings build flag
* If that flag is set, print a parseable and greppable string on missing translation strings
See #2303
The current "rendering language" is needed outside of Site. This commit moves the Language type to the helpers package, and then used to get correct correct language configuration in the markdownify template func.
This commit also adds two new template funcs: relLangURL and absLangURL.
See #2309
And in the same go adjusted some minor parts of the language API:
Add LanguagePrefix alias to Node and rename the Multilingual config section to Languages.
See #2309
Implements:
* support to render:
* content/post/whatever.en.md to /en/2015/12/22/whatever/index.html
* content/post/whatever.fr.md to /fr/2015/12/22/whatever/index.html
* gets enabled when `Multilingual:` is specified in config.
* support having language switchers in templates, that know
where the translated page is (with .Page.Translations)
(when you're on /en/about/, you can have a "Francais" link pointing to
/fr/a-propos/)
* all translations are in the `.Page.Translations` map, including the current one.
* easily tweak themes to support Multilingual mode
* renders in a single swift, no need for two config files.
Adds a couple of variables useful for multilingual sites
Adds documentation (content/multilingual.md)
Added language prefixing for all URL generation/permalinking see in the
code base.
Implements i18n. Leverages the great github.com/nicksnyder/go-i18n lib.. thanks Nick.
* Adds "i18n" and "T" template functions..
Highlight.js has evolved quite a bit since it this doc was written. Updating the example to the latest 9.6 version of Highlight JS hosted by cloudflare
i.e., "The PATH entry should be the folder where Hugo lives, not the binary."
Fixes#2280.
Also fix a rendering issue with list entries that consist of multiple
paragraphs by using four spaces instead of two. Special thanks to
@shurcooL for the insight! (Fixes#2285)
Also made a few minor formatting tweaks.
These functions allow trivial escaping and unescaping of HTML entities,
and make it far easier to compose other functions for the creation of
parameterised URLs.
Add logic to tpl.humanize such that it understands input of int literals
or strings which represent an integer. When tpl.humanize sees this type
of input, it will use inflect.Ordinalize as opposed to the standard
inflect.Humanize.
Fixes#1886
The install tutorial instructed users to rename the *.exe file to
hugo.exe because it used to have a big long name.
In Hugo 0.16 the file is already named hugo.exe, so the tutorial
made no sense on that point. Edited out those instructions.
A couple of internal links use `#toc_4` to attempt to locate a document
element within another document page. In both of these instances, there
is no element on the linked to pages with the id `#toc_4`. This commit
updates those links with the document elements which were the original
intended links, meaning these links now take you directly to the
intended element.
Signed-off-by: mattjmcnaughton <mattjmcnaughton@gmail.com>
Returns true if a given field value that is a slice / array of strings, integers or floats contains elements in common with the matching value. It follows the same rules as the intersect function.
Closes#1945
The procedure Start button --> Settings --> About was missing a step. Corrected it to: Start --> Settings --> System --> About. Also replaced ASCII arrows (-->) with Unicode right arrow character (U+2192).
We should get some new ones in there.
Also shuffle the order. This also means no merging into 0.15-docs ...
Which also means we should get a release out there ... soon!
See #2055
Also See https://github.com/BurntSushi/toml/issues/129 for an explanation to the little bit ugly dates.
Meny people, including me, have a custom robots.txt in static.
Also remove that option from the command line; it doesn't feel
important enough.
Fixes ##2049
This disables highlighting for fenced code blocks without explicitly specified language. It also introduces a new `PygmentsCodeFencesGuessSyntax` config option (defaulting to false).
To enable syntax guessing again, add the following to your config file: `PygmentsCodeFencesGuessSyntax = true`
This is a breaking change.
This also includes a refactor of the hugofs package and its usage.
The motivation for that is:
The Afero filesystems are brilliant. Hugo's way of adding a dozen of global variables for the different filesystems was a mistake. In readFile (and also in some other places in Hugo today) we need a way to restrict the access inside the working dir. We could use ioutil.ReadFile and implement the path checking, checking the base path and the dots ("..") etc. But it is obviously better to use an Afero BasePathFs combined witha ReadOnlyFs. We could create a use-once-filesystem and handle the initialization ourselves, but since this is also useful to others and the initialization depends on some other global state (which would mean to create a new file system on every invocation), we might as well do it properly and encapsulate the predefined set of filesystems. This change also leads the way, if needed, to encapsulate the file systems in a struct, making it possible to have several file system sets in action at once (parallel multilanguage site building? With Moore's law and all...)
Fixes#1551
To strip away any HTML. May be useful for the .Title in head etc.
People may shoot themself in the foot with this, maybe ...
The replacement function is pretty fast.
- updated the instructions to account for Windows 10 path editor
- linked to third-party editors for pre-10 Windows
- separated instructions for technical and non-technical users changed
D drive paths to C drive since D is the default optical drive on most
Windows systems
- cut the assumption about 64-bit Windows since 32-bit binary is also available
- cut the assumption about command line since we're giving GUI instructions
to non-technical users
- cut a bug in the doc where we had people typing D: at the command prompt
*after* submitting `cd D:\Hugo\Sites.` Recommend snipping 386 and AMD from
ZIP file names, since they don't add useful info and will just confuse novices.
This uses the Emoji map from https://github.com/kyokomi/emoji -- but with a custom replacement implementation.
The built-in are fine for most use cases, but in Hugo we do care about pure speed.
The benchmarks below are skewed in Hugo's direction as the source and result is a byte slice,
Kyokomi's implementation works best with strings.
Curious: The easy-to-use `strings.Replacer` is also plenty fast.
```
BenchmarkEmojiKyokomiFprint-4 20000 86038 ns/op 33960 B/op 117 allocs/op
BenchmarkEmojiKyokomiSprint-4 20000 83252 ns/op 38232 B/op 122 allocs/op
BenchmarkEmojiStringsReplacer-4 100000 21092 ns/op 17248 B/op 25 allocs/op
BenchmarkHugoEmoji-4 500000 5728 ns/op 624 B/op 13 allocs/op
```
Fixes#1891
This commit fixes a few things:
1. `given` is now a variadic parameter so that piping works properly
2. add separate template tests to make sure piping works
3. support time values
4. add more tests of the dfault function
The original image was 2055px × 1252px, which was oversized
and did not fit the required dimension of 600px × 400px
(3:2 aspect ratio).
To fix, the image was cropped and resized to the required dimension,
and was further optimized:
$ pngquant --nofs -v --speed 1 --quality 65-80 shelan-tn.png
$ optipng -o7 -zm1-9 shelan-tn-or8.png
$ mv shelan-tn-or8.png shelan-tn.png
reducing its filesize from 334125 bytes to 26929 bytes.
See #1831
Add humanize (inflect.Humanize) to the template funcMap. Documentation and
tests are included.
Various code cleanups of the template funcs:
- Break pluralize and singularize out into stand-alone funcs.
- Sort the list of funcMap entries.
- Add some minimal godoc comments to all public funcs.
- Fix some issues found by golint and grind.
Fixed a path in a Page Params example to reflect real directory
structure, removed extra quotes from sample code, and fixed link to
Archetypes which read "cross-references" before.
See #1805
Expanded on the use of Page Params in the templates/variables.md
documentation. Added sample code for something that keeps coming up on
discuss.github.io
Remind user to always run "brew update" first in order to avoid
repeated bug reports from users who didn't do that.
See #824, #1067, #1537, #1633 and #1749
with the following added languages in anticipation of document expansion:
apache dockerfile dos less php powershell python tex yaml
To reproduce docs/static/js/highlight.pack.js on Debian/Ubuntu:
$ sudo apt-get install nodejs npm
$ wget https://github.com/isagalaev/highlight.js/archive/9.0.0.tar.gz
$ tar xzf 9.0.0.tar.gz
$ cd highlight.js-9.0.0/
$ npm install
$ nodejs tools/build.js markdown asciidoc xml css javascript \
ini yaml json go bash diff dockerfile dos powershell makefile \
apache nginx tex http php python ruby django haml handlebars \
scss less coffeescript
Then, copy the resulting build/highlight.pack.js as well as
src/styles/monokai-sublime.css to the appropriate Hugo docs directories.
because our bootstrap-theme.css was originally a customized
core bootstrap.css file from Bootstrap v3.0.0.
This rename helps to avoid confusion with Bootstrap’s official
bootstrap-theme.css files.
The GitHub octicons fonts, which, in our case, came with GitHub:buttons,
are not actually used on gohugo.io. Rather, the icons inside the GitHub
buttons are actually glyphs from Font Awesome.
The GitHub:buttons JavaScript code docs/static/js/buttons.js
from https://github.com/ntkme/github-buttons was referenced
in docs/layouts/partials/footer.html but never used.
Apparently, the actual code for the GitHub buttons on the upper-left
corner of gohugo.io documentation was written by @spf13 in
docs/static/js/scripts.js.
The `gh` shortcode has two modes: users and issues. For user mode, pass a list
of `@username` arguments. For the issues/PR mode, pass a list of issue or PR
numbers. PRs link to the "issues/" URL since Github redirects to the correct
URL.
Thanks to @ryanclarke for suggesting an improved template.
Also add a note saying that these blackfriday flags are
very case-sensitive as of Hugo v0.15.
Thanks to @ryanclarke for noticing the change in behaviour.
See also spf13/hugo@5838420
using pngquant and OptiPNG. Result:
arresteddevops-tn.png 154734 bytes → 47184 bytes
maximeguitare-tn.png 95571 bytes → 24183 bytes
ridingbytes-tn.png 262222 bytes → 66491 bytes
And a small one to an even smaller one too:
goin5minutes-tn.png 26220 bytes → 9297 bytes
Prevent some frequently occurring problems
* Ensure version number is between quotes
* Ensure git and SSH are installed for the deployment step
* Focus extra attention on the wercker.yml verification site
To allow the end users to disable any form of smart dashes
(LaTeX-style or not) while keeping the rest of Blackfriday
SmartyPants features.
Depends on https://github.com/russross/blackfriday/pull/190
"Add HTML_SMARTYPANTS_DASHES for toggling smart dashes"
to be accepted by Blackfriday developers.
Increases clarity on the different between `section` and `type`.
The current `section` information here is wrong (sections can *not* be specified in front matter). This caused quite the headache. This change fixes this and also adds `type`, since it *can* be specified in front matter.
Some of the thumbnails in Showcase were out of place
because of several irregularly sized thumbnails,
and some of them almost 300KB in filesize.
Resize them all to 600x400 (pixels), and use the `-tn.png`
suffix.
When necessary, the website snapshot is re-captured using
gnome-web-photo. Then, the following commands (or a combination
thereof) are used to crop and resize the image into a thumbnail,
and to reduce its filesize:
$ convert example.png -crop 900x600+0+0 \
-filter Lanczos2Sharp -distort Resize 600x400 \
example-tn.png
$ pngquant --nofs -v --speed 1 --quality 65-80 example-tn.png
$ optipng -o7 -zm1-9 example-tn-or8.png
$ mv example-tn-or8.png example-tn.png
To prevent "Showcase" from becoming "Showcases",
also to have the RSS feed display correct titles,
i.e. "Showcase on gohugo.io" rather than "Showcase on ".
As Hugo now supports more formats thanks to the new "external helpers"
feature recently introduced, and as requested by some people, I added
some lines in the doc:
* basically confirming it actually exists
* how to use it
The documentation for the RSS templating is a little unclear.
http://gohugo.io/templates/rss/
Some users may attempt to look for a ```__internal``` directory rather than assume that's the aforementioned "Hugo own template."
Here's my suggestion.
This information was previously scattered around in the forums and
mailing list. Add it to the official docs to make things easier for new
users.
Fixes#1167
Taxonomy Term pages have variables in addition to those on "node"
pages. Documenting these variables with all the other node variables
makes them easier to find.
Fixes: #1155
Added clarification for RSS doc page.
* a little formatting to make key words jump out
* emphasize that you can create your own
* add how to link to the feed in <head>
* add what .RSSlink does
* added point that a link to an RSS feed should be of type application/rss+xml
Fleshed out aliases section, loading the "redirect" keyword so that it's easier to find. Specifically added a "how aliases work" section.
Added Discourse to comments section.
Fleshed out themes/customizing, because it seems to be the source of a lot of questions on the forum.
Added a bunch of clarifying narrative, looking at the discussion forum for what people are asking about, and what I myself was confused about.
* clearer separation of advantage of each style - server or client side - at the top
* inconsistent newlines (different column widths) so I just removed them from obvious paragraphs
* added that the highlight shortcode is not used for the client-side javascripts
* Hugo is taking crap for Pygments being slow, so tried to emphasize that's it's in Pygment's lap. I got your back, Hugo.
* On client-side added prism example
* More clarity on how the css and js needs to be added to your templates
* Explained how the client-side scripts work
Added bit about how the 404.html page has to be set to load automatically - auto on Github but needs config on other web servers.
Also tweaked the text a little to emphasize it's a node type, and explain a little more about where the 404 template should be saved.
Related to @bjornerik 's answer in this discussion: http://discuss.gohugo.io/t/inserting-data-from-data-file-into-content-file-newbie-question/1002/3 ... I figured I'd make myself useful and add the reference to the index function, on the go template primer page.
Also, I moved the reference links to the bottom.
A general comment: as good as these docs are, the primer at this point makes some assumptions about audience knowledge, so some might find it lacking. Once I understand better, I might make some more clarifying edits.
A couple of edits to clarify that the layout/partials folder can contain arbitrarily-named subfolders, since I found the examples using ``{{ partial "post/tag/list" . }}`` confusing. Some folders are named specifically to work a certain way with hugo, but although the examples use key functional section and taxonomy names like post and tag, it does not matter what they are called. Hopefully this will help other newbs.
One of the first things that new users have to understand is the
difference between Hugo as a web server and Hugo as a web site
generator. Issue #852 asked for documentation to make that clear.
This patch updates the overview page with that information. It will
seem repetitive to users that understand the difference. Weigh that
against the needs of those that don't.
Reference #852
Adds step-by-step instructions for installing from both brew and
the official tarball. Not sure if steps for installing from source
belong here, so left them out.
Fixes#1005
The `hugo help` output as shown in http://gohugo.io/overview/usage/
was not yet updated for v0.13. Thanks to @alebaffa for the heads up!
Also:
- Clarify that, after using `hugo server`, the bare `hugo` command
need to be run before deployment.
- Add a section on running `hugo` as production web server,
and add links to two blog posts of two Hugo users sharing
their experience.
Partially fixes: #852 and #937
See https://github.com/spf13/hugo/releases
What a pleasant surprise indeed!
How come I have never noticed them before?
And even `.deb` files are provided! How amazing!
Quote from @spf13: "I also think it's the better default
and should continue to be the case going forward."
Also mention the use of `hugo config` to check the current value
of `canonifyurls`, thanks to suggestion by @bep.
Fixes#802
- Clarify that Hugo may be built wherever Go is available;
- Add links to Git, Mercurial and Go;
- Unlist Bazaar: No libraries that Hugo depends on use it any more;
- Suggest the user to simply run `make` to build `hugo`
to get `hugo version` to display the commit hash.
Some variables are currently not documented and others are explained
across the document. So, I tried to pull an overview from the source.
Pls double check. I am not 100% sure, what the purpose of some variables
is or whether they are only relevant for previous versions. Thanks
* Add meta author, description and generator tags
* Add Hugo version beside the logo and in the footer
* Suggest the user to run `go get -u -v` to update dependencies
* Requires Go 1.3+ rather than Go 1.1+
* Improve rendering/formatting in some places
* Add trailing slash to URLs where appropriate
* GitHub redirects all http requests to https, update accordingly
Make Blackfriday's `HTML_SMARTYPANTS_FRACTIONS` option
user-configurable. Defaults to `true` as before. See
discussions at:
http://discuss.gohugo.io/t/any-way-to-disable-smart-fractions/328
Thanks to @bjornerik and @spf13 for laying the groundwork
making it easy to expose Blackfriday's underlying configurable
options.
canonifyUrls=true, RelPermalink and baseUrl with sub-path did not work.
This fixes that by adding a check for canonifyUrl=trues=true in RelPermalink().
So given
- baseUrl "http://somehost.com/sub/"
- the path "some-path/file.html"
For canonifyUrls=false RelPermalink() returns "/sub/some-path/file.html"
For canonifyUrls=true RelPermalink() returns "/some-path/file.html"
In the last case, the Url will be made absolute and clickable in a later step.
This commit also makes the menu urls defined in site config releative. To make them work with canonifying of urls, the context root is prepended if canonifying is turned off.
Fixes#519Fixes#711
- Add `safeUrl` template function (Fixes#347)
- Add TestSafeUrl() fashioned after @tatsushid great examples
- Disable `safeHtmlAttr` pending further discussions on its other
use cases because `safeUrl` is a cleaner solution to #347.
(There are also `safeJs` and `safeJsStr` that we could implement
if there are legitimate demands for them.)
- Rename `safeCSS` to `safeCss` (to follow the convention of `safeHtml`)
- Add/expand documentation on `safeHtml`, `safeCss` and `safeUrl`
Found on @spf13's Twitter. :-)
Prevent the testimonial dates from wrapping.
Also fix a few minor problems to get the home page
to validate as proper HTML5.
Extracted from https://www.freebsd.org/logo/logo-simple.svg
for temporary use until a future Font Awesome release adds
the `fa-freebsd` glyph (github/FortAwesome/Font-Awesome#1116) :-)
Make .fa `display: inline` to prevent unwanted line-wrapping
Also make the menu item "Issue & Help" line up with the others.
Hopefully making them more semantic and easier to read,
though it is raw HTML so it is slightly more work to maintain.
Also made minor revisions to some of the variable descriptions
to be more informative, e.g. `:monthname` in permalinks use
full English names ("January" etc.)
Added Version, CommitHash and BuildDate to hugolib/hugo.go and used it in build
Removed commitHash and buildDate from commands/version.go and used hugolib vars
Removed getDateFormat function from commands/version.go
Conflicts:
README.md
docs/content/templates/variables.md
* Add link to https://travis-ci.org/spf13/hugo
* Correct heading levels in docs/content/community/mailing-list.md
* Mention RFC 3339 as the `date` format set by `hugo new`
* Mention that `hugo new` does not add `draft = true` when the user
provides an archetype
* List short examples of TOML and YAML side by side
* Compact the Math template functions into a table
* Put some notes into a blockquote
Make the sidebar menu slightly wider so the arrow
does not get pushed to the next line.
Also remove `text-transform: capitalize;` so we can have,
e.g., "Table of Contents" rather than "Table Of Contents".
General revisions to (hopefully) make the documentation
easier to understand and more comprehensive.
Revise "Strange EOF error" troubleshooting page to say that
a fix is in place for the upcoming Hugo v0.13.
Also add more external links, and cute icons from Font Awesome.
While following the github pages tutorial I found some issues. These are
the commands I ran that worked.
Added site variables to the docs from the code.
- Change "livereload" and "live reload" to "LiveReload";
- Add a `$ ` prompt before example command lines
(not exhaustive, work in progress);
- Remove unnecessary whitespace from partials;
- Revise the blackfriday options table in overview/configuration.md
to make it narrower.
- Manually set the language for highlight.js where appropriate
- Rename "404" to "Custom 404 page", and remove incorrect reference
to "homepage"
- Credit the author of tutorials/github_pages_blog.md
(Similar notes are necessary for other contributed pages where
"I" am not spf13 to avoid reader confusion.)
- Add CSS for `kbd` and `table` etc. to css/style.css;
- etc.
With two entries of frequently encountered or obscured troubles so far:
- "Categories with accented characters" Unicode NFC/NFD mismatch
on Mac OS X (See #739)
- `hugo new` aborts with cryptic EOF error (See #776)
I was initially confused about how to use summaries. The only example code I found in the docs was on the page for list nodes, but that uses `Render "summary"`, which is for views, not an article summary. I thought a little example here might clarify the issue for future users.
It allows to use `where` template function like SQL `where` clause.
For example,
{{ range where .Data.Pages "Type" "!=" "post" }}
{{ .Content }}
{{ end }}
Now these operators are implemented:
=, ==, eq, !=, <>, ne, >=, ge, >, gt, <=, le, <, lt, in, not in
It also fixes `TestWhere` more readable
'where' template function used to accept only each element's struct
field name, method name and map key name as its second argument. This
extends it to accept dot chaining key like 'Params.foo.bar' as the
argument. It evaluates sub elements of each array elements and checks it
matches the third argument value.
Typical use case would be for filtering Pages by user defined front
matter value. For example, to filter pages which have 'Params.foo.bar'
and its value is 'baz', it is used like
{{ range where .Data.Pages "Params.foo.bar" "baz" }}
{{ .Content }}
{{ end }}
It ignores all leading and trailing dots so it can also be used with
".Params.foo.bar"
- Rejigged the weight of the extras/ content for the new crossreferences
page.
- Used the new {{</*…*/>}} format for documenting highlighting and to
prevent a warning about the missing `fig` shortcode.
- Correct some typos
- Add backticks and commas where necessary
- Use fenced code blocks specifying "bash" as the language
to avoid weird highlighting
- Place commas outside of quotation marks surroundingn codes
to avoid possible confusion
- Suggest users to use the discussion forum rather than the
mailing list
The whole article should maybe be rewriten to have a better content flow (maybe adding a table of content), to introduce both possible strategies. But at least, the technical steps are there!
This small function feels important enough to maybe deserve more than these three lines, but this will have to do for now.
This assumes that #652 gets merged.
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#565Fixes#480Fixes#461
And probably some others.
