A metalsmith plugin to render files with templates.
Note: this plugin is deprecated, and was split into two simpler plugins:
Check out those to repositories!
I am not 100% sure what is going on, but I think there is some kind of interference between metalsmith-templates and metalsmith-collections.
I have a simple site with the following directory structure:
root
|-------films
| |-------film1.md
| |-------film2.md
|-------templates
|-------film-template.html
And my metalsmith.json looks like this
{
"metadata": {
"title": "A title",
"description": ""
},
"plugins": {
"metalsmith-markdown": {},
"metalsmith-permalinks": {
"pattern": ":title"
},
"metalsmith-templates": {
"engine": "handlebars"
},
"metalsmith-collections" : {
"films": {
"pattern": "src/films/*.md",
"sortBy": "title"
}
}
}
}
When I run metalsmith, I get the following error message
/ASite/node_modules/metalsmith-templates/node_modules/async/lib/async.js:22
if (called) throw new Error("Callback was already called.");
^
Error: Callback was already called.
at /ASite/node_modules/metalsmith-templates/node_modules/async/lib/async.js:22:31
at /ASite/node_modules/metalsmith-templates/lib/index.js:46:25
at Function.exports.handlebars.render (/ASite/node_modules/metalsmith-templates/node_modules/consolidate/lib/consolidate.js:499:5)
at /ASite/node_modules/metalsmith-templates/node_modules/consolidate/lib/consolidate.js:146:25
at /ASite/node_modules/metalsmith-templates/node_modules/consolidate/lib/consolidate.js:99:5
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
I am not sure if I am doing something wrong with the configuration or if this is a genuine bug. Additionally, I am not sure if this is a problem with the plugin or metalsmith proper.
This feature is meant for templating languages that support inheritance and the idea came from my previous version of site that was generated by Hyde.
Hyde treats content files as templates themselves, which in templating language with block style inheritance can be used to append other data into different parts of the templates. For example:
src/index.html
---
title: Welcome!
extends: base.html
---
{% block css %}
{% parent %}
<link rel="stylesheet" type="text/css" href="/media/index.css"/>
{% endblock %}
{% block content %}
<h1>Welcome!</h1>
{% endblock %}
src/page.html
---
title: Normal page
extends: base.html
---
<h1>A regular page</h1>
templates/base.html
<html>
<head>
<title>{{ title }}</title>
{% block css %}
<link rel="stylesheet" type="text/css" href="/media/common.css"/>
{% endblock %}
</head>
<body>
{% block content %}{% end block %}
</body>
</html>
This method avoids having to write templates or partials that are specific to individual content files, and instead can have the content files drive specific portions of a more generic template. This also keeps content with it's requirement for special treatment together in one place.
For simple cases, like the page.html above, nothing special has to be done in the content file, as defaults can be specified when setting up the templating engine/plugin.
I wrote a sample implementation in mayo@43a2d0d. It's a bit rough around the corners, especially with having to specify some of the language specific patterns manually, but there is no common way of defining blocks or auto detecting this from the template languages. Maybe potentially a shim library that would define these for common templating libraries, or something akin to consolidate.js for template engines with inheritance.
Any feedback, ideas, or opinions welcome.
According to swig's documentation partials should work with:
{% include "./partial.html" %}
and the extending of templates should be possible with:
{% extends 'layout.html' %}
Both extends and include should work with relative paths from what I understand. I assume that this is different for metalsmith-templates when using swig (I'm using it with gulpsmith), but I don't really understand why.
Should these tags work with metalsmith-templates? If so, how? It wasn't really clear from the documentation.
Seems like several useful pull requests have been left unmerged for quite some time...any reason they haven't been merged or closed?
Maybe I am missing something here, but I have tried a bunch of things and cannot make template inheritance work with this plugin. I was wondering if anyone had or if it's supported.
Example:
/templates/
default.html
/src/
index.html
build.js
default.html:
<html stuff>
{% block foo %}
default content
{% endblock %}
<more html stuff>index.html:
---
title: My Page
template: default.html
---
(% block foo %}
new content to over-ride the default
{% endblock %}I am not sure how I would pass those blocks over to default.html. As far as I can see, the data in the yaml front matter is passed automatically, but I can't see how I would pass the block... or extend default.html either. The blocks are of sufficient size and complexity that they would be hard to pass in the yaml front matter.
Am I missing something here?
See metalsmith/metalsmith#60. As soon as I've removed template from my build.js the images became fine.
A template starting with the following HTML markup:
<!doctype html>
<html lang="en">
<head>comes out as:
<p><!doctype html></p>
<html lang="en">
<head>while using the latest release of metalsmith and metalsmith-templates, and tried with mustache, handlebars, and swig.
These are configured via metalsmith.json, that looks like:
{
"source": "stories",
"destination": "public_html",
"plugins": {
"metalsmith-templates": {
"engine": "swig",
"directory": "./templates",
"default": "index.html"
},
"metalsmith-markdown": {
"smartypants": true,
"gfm": true,
"tables": true
}
}
}I'm using gulpsmith/metalsmith to compile my handlebars templates, and everything is working as expected, with the exception of the https://github.com/shannonmoeller/handlebars-layouts library. All other bits of handlebars functionality seem to be working (partials, custom helpers, etc.), but handlebars-layouts' {{#extend}} block helper isn't processed at all. It turns up untouched in the output (without any errors or exceptions logged):
<!-- example excerpt from dist/index.html -->
{{#extend "footer"}}{{/extend}}After opening an issue with shannonmoeller/handlebars-layouts#9 and after that pjeby/gulpsmith#6, @pjeby suggested that there might be an error emitted by metalsmith (or consolidate.js) that isn't being handled correctly somewhere:
If you definitely have an error there, the only other possible culprit is the async chaining library Metalsmith uses to chain plugins together: it was recently updated to support synchronous plugins, and it might be that its error trapping semantics have changed.
Might it be that this is the case? I've created a reduced test case that illustrates what's going wrong from my side: https://github.com/superwolff/cape/tree/handlebars-layouts. Could this possibly be a metalsmith/consolidate issue?
I'd like to use handlebars syntax in my source files (the files in ./src) as well as in my template files (in `./templates). Right now, this doesn't seem to be working for me.
For example:
./src/index.html
and ./templates/default.html
Is processed to ./dist/index.html:
<h1>Template contents</h1>
<h2>Partials</h2>
<h2>Header</h2>
<h2>Footer</h2>
<h1>Page contents</h1>
<h2>Partials</h2>
{{> header }}
{{> footer }}Is it normal for metalsmith not to process the files in src (other than applying the template to them)? And if so, would it be possible for metalsmith to do so?
My source code is here: https://github.com/superwolff/cape/tree/handlebars-layouts
And I don't think this issue is related to issue 24, but correct me if I'm wrong
this code
Object.keys(files).forEach(function(file){
debug('stringifying file: %s', file);
var data = files[file];
data.contents = data.contents.toString();
});
"destroys" binary contents like JPEG, additionally the code seems not to be necessary, works for me without
seems like a change is breaking in 0.6:
/home/vagrant/dev/segmentio/site-blog/node_modules/metalsmith-templates/lib/index.js:77
str = metalsmith.path(dir, data.template || def);
^
TypeError: Object #<Metalsmith> has no method 'path'
at convert (/home/vagrant/dev/segmentio/site-blog/node_modules/metalsmith-templates/lib/index.js:77:26)
at /home/vagrant/dev/segmentio/site-blog/node_modules/metalsmith-templates/node_modules/async/lib/async.js:111:13
at Array.forEach (native)
at _each (/home/vagrant/dev/segmentio/site-blog/node_modules/metalsmith-templates/node_modules/async/lib/async.js:32:24)
at async.each (/home/vagrant/dev/segmentio/site-blog/node_modules/metalsmith-templates/node_modules/async/lib/async.js:110:9)
at /home/vagrant/dev/segmentio/site-blog/node_modules/metalsmith-templates/lib/index.js:63:5
at Object.next [as _onImmediate] (/home/vagrant/dev/segmentio/site-blog/node_modules/metalsmith/node_modules/ware/lib/index.js:68:8)
at processImmediate [as _immediateCallback] (timers.js:330:15)
Proposal: add ability to specify parent templates
As a user, I want to be able to specify parent templates for other templates. This is not the same as partials. This functionality already comes as standard in Jeykull as I would expect to have this built-in to templates module.
Example:
src/post1.md:
---
title: My post
template: post.hbs
---
Hellotemplates/post.hbs:
---
template: html.hbs
---
<h1>{{title}}</h1>
<p>{{contents}}</p>templates/html.hbs:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>{{title}}</title>
</head>
<body>
{{{contents}}}
</body>
</html>Expected output:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>My post</title>
</head>
<body>
<h1>My post</h1>
<p>Hello</p>
</body>
</html>Hi,
I seem unable to register a handlebars helper in a json. Although the helper is registered it does not call the specified function, it only prints the "function name".
This is the syntax I am using :
"metalsmith-templates": {
"engine": "handlebars",
"helpers" : { "<helper_name>" : "<function_name>" }
}
I've tried to support multiple template engines by just .useing different sets of options, like so:
metalsmith
.use(templates({ engine: "jade", pattern: "*.jade" })
.use(templates({ engine: "haml", pattern: "*.haml" })You can probably guess where this is going. I thought the pattern option specified which engine to use to process the template specified in the file (or the default file), but instead it seems to test against the source file (in the tests it differentiates between .md and .html).
That doesn't strike me as particularly useful, especially if it's used in conjunction with metalsmith-markdown, which converts all of your markdown into .html files anyway.
Am I trying to do something this plugin wasn't intended for? Or is there some reason to want to pattern match the source file instead of the template file?
right now the code runs through all files, even .jpg or .mp3
a check on "binary type" would be nice or a simple "just run templating on files with extension s [.abc, .xyz](provided by user)"
I have no idea which plugin is at fault (metalsmith-templates, consolidate.js, or toffee itself), but something is wrong heh.
With the following files:
// build.js
var metalsmith = require('metalsmith')
, markdown = require('metalsmith-markdown')
, templates = require('metalsmith-templates')
metalsmith(__dirname)
.use(markdown())
.use(templates('toffee'))
.build()// templates/index.toffee
<html>
<body>
#{contents}
</body>
</html>
---
template: index.toffee
---
Content, from Index.mdWhen running node build.js the above code "hangs". It doesn't return, and has to be killed. Oddly enough, it does render the layout properly. Infact, everything seems to work perfectly.. it just doesn't exit.
As an example:
leeolayvar@me ~/toffee-test> ls -l
total 8
-rw-r--r-- 1 leeolayvar staff 214 Apr 30 15:24 build.js
drwxr-xr-x 7 leeolayvar staff 238 Apr 30 15:24 node_modules
drwxr-xr-x 3 leeolayvar staff 102 Apr 30 15:22 src
drwxr-xr-x 3 leeolayvar staff 102 Apr 30 15:25 templates
leeolayvar@walterwhite ~/toffee-test> node build.js
^C⏎
leeolayvar@me ~/toffee-test> ls -l
total 8
drwxr-xr-x 3 leeolayvar staff 102 Apr 30 15:38 build
-rw-r--r-- 1 leeolayvar staff 214 Apr 30 15:24 build.js
drwxr-xr-x 7 leeolayvar staff 238 Apr 30 15:24 node_modules
drwxr-xr-x 3 leeolayvar staff 102 Apr 30 15:22 src
drwxr-xr-x 3 leeolayvar staff 102 Apr 30 15:25 templates
leeolayvar@me ~/toffee-test> cat build/index.html
<html>
<body>
<p>Content, from Index.md</p>
</body>
</html>
leeolayvar@me ~/toffee-test>
Anyone have any thoughts as to why this must be? A similar test with Handlebars works perfectly, and i've been logging through the metalsmith/templates codebase with no luck figuring out the spot where this goes wrong.
I get a bunch of mkdir errors trying to npm install v0.5.0, all related to deeply nested internal deps of lodash. Possibly due to running on a virtualbox / windows file system hitting some limit. I don't get the same errors on npm install lodash itself.
I know the source of the issue probably isn't this repo but is lodash absolutely needed for just the omit function, that could be written in like 10 lines? It also slows down the install by like 10x because of the ridiculous amount of requests lodash needs to install. </rant>
So I get this error message
...\node_modules\metalsmith-templates\lib\index.js:77
str = metalsmith.path(dir, data.template || def);
^
TypeError: Object #<Metalsmith> has no method 'path'
at convert (...\node_modules\metalsmith-templates\lib\index.js:77:26)
I fixed it by changing line 77 to:
str = metalsmith.join(dir, data.template || def);
Anybody else has this issue?
Consolidate.js supports partials for hogan, mustache, handlebars, and ractive. It also appears to support helpers for handlebars.
Does this plugin expose any of that functionality? Would be very nice 🍪
Nevermind! I had a stupid mistake, too sleepy.
I've seen a couple of issues and pull requests that all relate to processing the templating language in content files, in one way or another: #21, #24, #22, #27, #26.
I'm opening this issue to focus discussion on what I think is actually at the core of these issues and prs, to hopefully reach a solution more quickly and eliminate any confusion. Let me briefly summarize (and reiterate what I said in #21):
inPlace), but still want to apply the template as defined in the front-matter (which inPlace does not do)Extending
As I said in #21 (and as others have said as well), extending templates is more a functionality of the templating language, and does not have to be added to metalsmith-templates (in my opinion). It's already possible.
Process contents
So that leaves the second bulletpoint: processing the templating language in content files, whilst still applying the template as defined in the files front-matter. I think solving that would basically directly or indirectly address all issues and prs mentioned above.
So what would be the best solution to address that? A new option, or modify inPlace (if this corresponds to what it was originally meant to do)? @ianstormtaylor , what do you think?
The readme shows how to configure options, but what are the values if you don't?
Hey there! I'm very new to the world of Metalsmith. I'm getting this error:
Error: Cannot extend "layout.html" because current template has no filename.
Here's my build file and my source files.
I have gone through the docs for Metalsmith, Metalsmith-templates, Consolidate.js, Swig; and cannot see what I'm doing wrong.
I have, however, found a temporary solution for my problem in changing line 55 of this plugin to:
var tmpl = file;Any ideas what I might be doing wrong? Or have I stumbled onto a bug? Thanks!
There is metalsmith-templates, metalsmith-in-place and metalsmith-layouts that seem to do very similar things.
This could be well-confusing for the users.
Propose to deprecate either this one or (metalsmith-in-place and metalsmith-layouts).
Related: #35
I'm using Metalsmith as a gulp plugin, with Swig as my templating engine. I have gulp.watch set to check for changes to the templates and .md files using the following:
gulp.watch(['lib/content/**/*.md'], ['metalsmith']);
gulp.watch(['lib/templates/**/*'], ['metalsmith']);
When I make changes to the markdown files, the built html updates just fine. However, when I save a template or partial, it says that the metalsmith task ran successfully, but the html doesn't update and I have to kill the gulp watch process and restart it manually. My gulpsmith task can be found below:
gulp.task('metalsmith', function() {
gulp.src(['lib/content/**/*.md'])
.pipe(plugins.frontMatter()).on("data", function(file) {
assign(file, file.frontMatter);
delete file.frontMatter;
})
.pipe(plugins.gulpsmith()
.use(plugins.metalsmithCollections({
pages: { pattern: content_src + '/pages/*.md' },
projects: { pattern: content_src + '/projects/*.md' },
posts: {
pattern: content_src + '/posts/*.md',
sortBy: 'date',
reverse: true
}
}))
.use(plugins.metalsmithMarkdown())
.use(plugins.metalsmithPermalinks({
pattern: build_root + '/:collection/:title'
}))
.use(plugins.metalsmithTemplates({
engine: 'swig',
directory: template_src
}))
)
.pipe(gulp.dest(build_root));
});
This looks to me like consolidate.js has some sort of template caching system that isn't clearing, since the watch task is still running. Can you think of any way of clearing this? (or fixing it some other way)
Using nunjucks template engine with metalsmith causes 2 issues:
nunjucks.config(dir) (http://mozilla.github.io/nunjucks/api.html). For now setting "directory": "./templates" in metalsmith.json does nothing - templates still need full path in extend {% extend "./templates/base.html" %}Hey there,
I was having difficulties with creating a blog that has it's templates with .hbs extension.
Namely I have the following directory structure and code :
{
"source": "./pages",
"plugins": {
"metalsmith-templates": {
"engine": "handlebars"
},
"metalsmith-permalinks": {
"pattern": ":title"
}
}
}
files :
pages/index.hbs
The final output is :
build/index.hbs
which IMHO is a bit wrong.
Don't you think there should be a configuration property, specifying the destination extension name?
I believe it's far better if your templates have .hbs extension than .html.
Thanks.
I don't think there are a lot of templating engines that support this but it would be cool if it had this.
Basically let's say post.md has a template post.html, and that post.html has it's own header that also defines a template. At this point it puts a template within a template, allowing you to have one template with footer and header (which usually stay the same throught the website) and the rest of the templates can sort of inherit from it, allowing very advanced templates.
This is just an idea that I've seen in DocPad and I can say it's super useful. Maybe it can be optional? :)
not sure what's going on with this error after running make build
node_modules/.bin/metalsmith
Metalsmith · Object #<Metalsmith> has no method 'join'
TypeError: Object #<Metalsmith> has no method 'join'
at convert (/Users/charles/Desktop/new-metalsmith-blog/node_modules/metalsmith-templates/lib/index.js:42:29)
at /Users/charles/Desktop/new-metalsmith-blog/node_modules/metalsmith-templates/node_modules/async/lib/async.js:111:13
at Array.forEach (native)
at _each (/Users/charles/Desktop/new-metalsmith-blog/node_modules/metalsmith-templates/node_modules/async/lib/async.js:32:24)
at async.each (/Users/charles/Desktop/new-metalsmith-blog/node_modules/metalsmith-templates/node_modules/async/lib/async.js:110:9)
at Ware.<anonymous> (/Users/charles/Desktop/new-metalsmith-blog/node_modules/metalsmith-templates/lib/index.js:33:5)
at Ware.<anonymous> (/Users/charles/Desktop/new-metalsmith-blog/node_modules/metalsmith/node_modules/ware/node_modules/wrap-fn/index.js:45:19)
at Object.next (/Users/charles/Desktop/new-metalsmith-blog/node_modules/metalsmith/node_modules/ware/lib/index.js:75:20)
at Object._onImmediate (/Users/charles/Desktop/new-metalsmith-blog/node_modules/metalsmith/node_modules/ware/node_modules/wrap-fn/index.js:121:18)
at processImmediate [as _immediateCallback] (timers.js:354:15)
make: *** [build] Error 1
I've been using handlebars partials as described in this issue: #3. I'm passing a partials object to metalsmith-templates, and building works just fine.
However, when watching the partials folder for changes, any change triggers the following error:
/home/ismay/Github/cape/node_modules/gulp/node_modules/vinyl-fs/lib/dest/index.js:40
var writePath = path.resolve(basePath, file.relative);
^
TypeError: Cannot read property 'relative' of undefined
at DestroyableTransform.saveFile [as _transform] (/home/ismay/Github/cape/node_modules/gulp/node_modules/vinyl-fs/lib/dest/index.js:40:48)
at DestroyableTransform.Transform._read (/home/ismay/Github/cape/node_modules/gulp/node_modules/vinyl-fs/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:184:10)
at DestroyableTransform.Transform._write (/home/ismay/Github/cape/node_modules/gulp/node_modules/vinyl-fs/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:172:12)
at doWrite (/home/ismay/Github/cape/node_modules/gulp/node_modules/vinyl-fs/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:237:10)
at writeOrBuffer (/home/ismay/Github/cape/node_modules/gulp/node_modules/vinyl-fs/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:227:5)
at DestroyableTransform.Writable.write (/home/ismay/Github/cape/node_modules/gulp/node_modules/vinyl-fs/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:194:11)
at Stream.ondata (stream.js:51:26)
at Stream.emit (events.js:95:17)
at Stream.reemit (/home/ismay/Github/cape/node_modules/lazypipe/node_modules/stream-combiner/node_modules/duplexer/index.js:70:25)
at Stream.emit (events.js:95:17)I've narrowed it down to it being a change in the partials (and the subsequent build process that this triggers), but what's weird is that the build process shouldn't be different when triggered from a watch event (the pipeline is exactly the same for a regular build, and that does work).
Is this a bug in metalsmith-templates, or should I be looking elsewhere?
Edit: forgot to point to my source code, it can be found here:
The watch event that triggers the error is from:
// Watch partials
gulp.watch('./templates/partials/*.html', function () {
gulp.src('./src/**/*.html')
.pipe(buildHtml())
.pipe(gulp.dest('./tmp/'))
.pipe(reload(config.reload));
});An advantage of Metalsmith is that it looks at every file, and the developer is free with structure.
However, this plugin does not make that possible (and therefore limits Metalsmith) because it only looks in a single defined directory. In some case the user is forced to make a template per page in the 'templates' folder, rather than a genral layout template and further page templates in an 'src' folder (and including markdown as partials). So far this seems standard in other static site generators I've tried.
I don't really see the point in having the directory option. Why not enable the user to put templates wherever, and continue the Metalsmith trend of freedom with structure? (and I realise this plugin is developed by the Metalsmith developer, which makes this a surprising choice of function)
Shame as this just brought my use of Metalsmith to a stop, and all was going great before that.
Within Jade templates, if you name a block content, the build will fail, ie:
extends layout
block content
h2 Test
p Hello
This is pretty basic Jade stuff (see the Jade docs for examples). It will work, however, if I use any other name for the block however, including contents.
I haven't had a chance to look into the source code, and if it is required I may fork the repo myself to fix the problem and do a PR.
Is it possible to make an option for the templating engine, for example I need setting "pretty" for "jade" ...
Thank you!
At the moment it doesn't appear possible to set custom settings on the consolidated engine, as it creates the engine based on the string you give it. It would be good if it could detect if you passed it a function and use that instead of creating the engine.
For example:
Currently only allows the below (which causes issues in not being able to e.g. add ejs filters)
.use(templates({ engine: 'ejs' });
It might be possible to do something like the below (though this looks messy, is there a better alternative?)
var consolidate = require('consolidate');
consolidate.requires.ejs = require('ejs');
consolidate.requires.ejs.filters.url = function() { };
.use(templates({ engine: consolidate.requires.ejs });
Update it doesn't look like the above example would be possible as consolidate doesn't expose the requires -- I'm not sure there is any way around this?
As metalsmith-templates makes use of consolidate.js I thought it should work with react.js as that's officially supported:
https://www.npmjs.com/package/consolidate
However I can't get it to work, and get a TypeError on build:
TypeError: undefined is not a function
Has anyone got this working? I know there are separate projects for react (https://github.com/coodoo/metalsmith-reactjs & https://github.com/yeojz/metalsmith-react-templates) but I've found both of them out of date with the latest versions of react (>0.13).
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.