Be able to inhibit AbsURL canonicalization of content, on a site
configuration basis. Advantages of being able to inhibit this include
making it easier to rendering on other hostnames, and being able to
include resources on http or https depending on how this page was
retrieved, avoiding mixed-mode client complaints without adding latency
for plain http.
A sample config.yaml for a site might contain:
```yaml
permalinks:
post: /:year/:month/:title/
```
Then, any article in the `post` section, will have the canonical URL
formed via the permalink specification given.
Signed-off-by: Noah Campbell <noahcampbell@gmail.com>
* Add `.Truncated` bool to each page; will be set true if the
`.Summary` is truncated and it's worth showing a "more" link of some
kind.
* Add `Params` to the site config, defining `.Site.Params` accessible
to each page; this lets the site maintainer associate arbitrary data
with names, on a site-wide basis.
* Provide a `First` function to templates:
* Use-case: `{{range First 5 .Site.Recent}}` or anything else which
is a simple iterable provided by hugolib
* Tests by me for `.Truncated` and `First`
Also @noahcampbell contributed towards this:
* Add UnitTest for `.Site.Params`:
> Digging into this test case a bit more, I'm realizing that we need
> to create a param test case to ensure that for each type we render
> (page, index, homepage, rss, etc.) that the proper fields are
> represented. This will help us refactor without fear in the
> future.
Sample config.yaml:
```yaml
title: "Test site"
params:
Subtitle: "More tests always good"
AuthorName: "John Doe"
SidebarRecentLimit: 5
```
Signed-off-by: Noah Campbell <noahcampbell@gmail.com>
Remove the hugo-nav since it relied on a slow library. The current
build reimplements the absurl functionality based on string replace.
Discovered that my prior implementation missed the requirement for
making absolute paths (/path) absolute with the host, whereas a relative
path is left untouched. Updated the test cases to support this if this
is reimplemented.
Checks to make sure the xml document starts with <?xml. Previously, the
html translate package would write additional details into the document
that caused it to fail.
50% speedup. Fix#91
to run the benchmark:
go test -test.run=NONE -bench=".*" -test.benchmem=true ./transform/ > new.txt
to compare the results:
/usr/local/go/misc/benchcmp baseline.txt new.txt
Speedup and memory improvements
benchmark old ns/op new ns/op delta
BenchmarkChain 101219 50453 -50.15%
BenchmarkTransform 51625 45531 -11.80%
benchmark old allocs new allocs delta
BenchmarkChain 222 103 -53.60%
BenchmarkTransform 135 106 -21.48%
benchmark old bytes new bytes delta
BenchmarkChain 23919 10998 -54.02%
BenchmarkTransform 11858 10665 -10.06%
Removed these checks so a single file in content can generate a site.
For example, given a site with a content directory and an index.html,
running hugo -s dir will generate a project without any more input.
The render code path would use a fallback if there was an exception.
This change instead relies on explicit declaration of the layout to use
and includes a check to see if the layout indeed exists before
attempting to render it.
If a file named index.html exists in a directory, or root, it will be
rendered as if ugly urls are turned on. This allows for top level
content to not need a supporting layout file and content in content.
This change should not affect anyone who is using the perscribed way.
I also cleaned up a bunch of one off functions in site.go.
Allow content that is not markdown and does not need to be rendered to
exists in the content directory. Currently any valid html or xml
document can exist. Templates are applied to these documents as well.
If you need to have content that doesn't have templates or AbsUrlify
like operations, then continue to put this content in static and it will
be copied over.
I want to move all logic to writing aliases to target so I can pave the
way for writing aliases specific to other runtimes (like .htaccess for
apache or a script for updating AWS or symlinking on a filesystem).
filepath was used inconsistently throughout the hugolib. With the
introduction of source and target modules, all path are normalized to
"/". This simplifies the processing of paths. It does mean that
contributors need to be aware of using path/filepath in any module other
than source or target is not recommended. The current exception is
hugolib/config.go
It started with wanting to move templates in template bundles and the
rest followed. I did my best to start grouping related functions
together, but there are some that I missed. There is also the method
Urlize that seems to be a special function used in both worlds. I'll
need to revisit this method.
Introducing the target module in hugo. This provides the simple
interface for writing content given a label (filename) and a io.Reader
containing the content to be written.
If site.Target is not set, it defaults back to the original behavior of
writing to file system.
In hugolib/site_url_test.go I have an InMemoryTarget for testing
purposes and use it to see if the final output of a render matches.
Provide unit test support RenderThing.
One observation is that creating the site.Tmpl variable is a one time
event. site.Tmpl doesn't like additional templates with the same name.
This means that updating a template while in --watch mode requires
throwing away the entire Site object and creating a new one. Not that
this is a bad idea, but it is something I discovered while working on
these unit tests.
