jnordberg / wintersmith Goto Github PK
View Code? Open in Web Editor NEWA flexible static site generator
Home Page: http://wintersmith.io/
License: MIT License
A flexible static site generator
Home Page: http://wintersmith.io/
License: MIT License
As instructed, I tried installing globally but ran into this:
$ npm install wintersmith -g
npm ERR! Doesn't exist: git://github.com/jnordberg/marked.git
npm ERR! error installing [email protected] Error: ENOENT, No such file or directory 'git://github.com/jnordberg/marked.git'
npm ERR! Error: ENOENT, No such file or directory 'git://github.com/jnordberg/marked.git'
Odd, considering git://github.com/jnordberg/marked.git
is a valid public-facing git repo.
Probably an npm settings on my end I must have screwed up somewhere - any idea?
I'm getting a cryptic error when running wintersmith build
or after attempting to load content from the preview server.
events.js:66
throw arguments[1]; // Unhandled 'error' event
^
Error: write EPIPE
at errnoException (net.js:768:11)
at Object.afterWrite (net.js:592:19)
This is with wintersmith 1.1.1 and node 0.8.7 on NetBSD. It could be an issue with my node installation (node is still experimental on NetBSD) but I haven't had any other issues with it yet. Any thoughts on this one?
Based on issue #9, I thought I might be able to override the default MarkdownPage rendering with a plugin. However, this doesn't do anything:
module.exports = (wintersmith, callback) ->
class PandocPage extends wintersmith.defaultPlugins.MarkdownPage
getHtml: (base) ->
return '<p>Pandoc-formatted content here.</p>'
wintersmith.registerContentPlugin 'pages', '**/*.*(markdown|md)', PandocPage
callback()
Is there a way to modify markdown rendering behavior without modifying Wintersmith's core?
I've put together a Pandoc content plugin (see https://github.com/lhagan/wintersmith-pandoc), but it's quite a bit of a hack due to the asynchronous nature of the Pandoc library - if I call Pandoc within getHtml
, wintersmith renders the page before Pandoc has finished. I'm currently working around this by calling Pandoc as part of fromFile
to take advantage of its existing callback function, but this is pretty inefficient. Is there better way to handle this?
There needs to be a better way to process the content tree before rendering it. Currently it has to be done in templates. This works well with templating languages like jade that support inline javascript, but for something like mustache you can only create very simple sites without creating a custom plugin.
I propose to introduce a new plugin type, a view plugin. The view takes over the responsibility of rendering from the content plugin. It will basically be the ContentPlugin's current render
method.
Quick outline of the new structure:
A helper will load all js/coffeescript files in ./views
as view plugins but you should also be able to register global view plugins.
And to provide backwards compatibility a default "template" view is available that just renders with the template defined by the content.
It would be great to get some input from you awesome people writing plugins for wintersmith: @smebberson @joefiorini @sfrdmn @mnmly @imothee @jnwng @lhagan @ajpiano @stephenallred @vitch (i hope i didn't miss anyone :)
In preview mode there is a bug in src/server.coffee (line ~40)...
async.detect ContentTree.flatten(contents), (item, callback) ->
callback (uri is item.url)
, (result) ->
...fails because item.url come out with backward slashes (at least under windows, nodejs 0.6.14) and uri uses forward slashes. This change...
async.detect ContentTree.flatten(contents), (item, callback) ->
callback (uri is item.url.replace(new RegExp(/\\/g),"/"))
, (result) ->
...fixes the issue for me, but I'm not sure if it breaks anything in linux (probably paths with escaped characters?).
So far as I can tell, there's presently no way to load custom plugins if you're invoking wintersmith from within a script. If you pass them in as options, they are simply ignored, as the code to handle loading plugins only exists/is invoked within the cli interface. I'll be putting something together to attempt to make this work in the next few hours and will send a PR assuming I do!
Everytime I try to use the wintersmith preview command I keep getting this error
wintersmith preview
starting preview server
path.exists is now called fs.exists
.
using config file: /Users/maxmarze/sandbox/node.js/wintersmith/beta/config.json
server running on: http://localhost:8080/
events.js:66
throw arguments[1]; // Unhandled 'error' event
^
Error: listen EADDRINUSE
at errnoException (net.js:769:11)
at Server._listen2 (net.js:909:14)
at listen (net.js:936:10)
at Server.listen (net.js:985:5)
at run (/usr/local/lib/node_modules/wintersmith/lib/server.js:123:14)
at Object.async.forEach (/usr/local/lib/node_modules/wintersmith/node_modules/async/lib/async.js:82:20)
at loadPlugins (/usr/local/lib/node_modules/wintersmith/lib/index.js:38:16)
at async.apply (/usr/local/lib/node_modules/wintersmith/node_modules/async/lib/async.js:532:23)
at async.iterator.fn (/usr/local/lib/node_modules/wintersmith/node_modules/async/lib/async.js:517:34)
at async.waterfall.wrapIterator (/usr/local/lib/node_modules/wintersmith/node_modules/async/lib/async.js:441:34)
Do you have any thoughts on a good way to separate the theme (css, js, and templates) from the content (markdown, json)? I'd like to be able to manage the site content and theme using independent git repositories, but this is currently a bit messy with templates located separately from the css & js.
My idea would involve specifying multiple folders to scan for contents, something like `contents: ['./contents', './theme']. Is there a simpler way to do this? I suppose this could be done by just putting the theme repo inside contents as a submodule, but I don't think this is quite as clean.
├── config.json site configuration and metadata
├── contents
│ ├── archive.md
│ ├── articles each article is a subfolder of articles
│ │ ├── another-test
│ │ │ └── index.md
│ │ └── red-herring
│ │ ├── banana.jpg
│ │ └── index.md
│ ├── authors if an author is set in an articles metadata it
│ │ ├── baker.json will be read from here
│ │ └── the-wintersmith.json
│ ├── feed.json json page that renders the rss feed to feed.xml
│ └── index.json
└── theme
├── css renders to ./build/css
│ ├── github.css
│ └── main.css
├── js renders to ./build/js
│ ├── jquery.js
│ └── script.coffee
└── templates templates folder is ignored on build
├── archive.jade
├── article.jade
├── author.jade
├── feed.jade
├── index.jade
└── layout.jade
Is it somehow possible to concat files with a plugin, e.g. for minification?
As for issue #32 I spent a lot of time to understand why my config:
{
"locals": {
"url": "http://localhost:3000",
"name": "The Wintersmith's blog",
"owner": "The Wintersmith",
"description": "-32°C ain't no problems!",
"index_articles": 3,
"plugins": ["wintersmith-stylus", "wintersmith-coffee"]
}
}
Produces this:
^CDAddYE:foo wintersmith preview -v -P
starting preview server
resolving options - work directory: /private/tmp/foo
path.exists is now called `fs.exists`.
using config file: /private/tmp/foo/config.json
options: {"locals":{"url":"http://localhost:3000","name":"The Wintersmith's blog","owner":"The Wintersmith","description":"-32°C ain't no problems!","index_articles":3,"plugins":["wintersmith-stylus","wintersmith-coffee"]}}
resolved options: {"locals":{"url":"http://localhost:3000","name":"The Wintersmith's blog","owner":"The Wintersmith","description":"-32°C ain't no problems!","index_articles":3,"plugins":["wintersmith-stylus","wintersmith-coffee"]},"config":"/private/tmp/foo/config.json","contents":"/private/tmp/foo/contents","templates":"/private/tmp/foo/templates","chdir":null,"require":[],"plugins":[],"v":true,"verbose":true,"P":true,"port":8080,"p":8080,"c":"./config.json","i":"./contents","t":"./templates","L":{},"C":null}
validating paths
server running on: http://localhost:8080/
So, why wintersmith doesn't read correctly my config? As you can see if the port is wrong and I haven't any plugin loaded.
I'm running into an issue with larger sites (and slow plugins) where it can take several seconds to render each page. This can make navigating the site in preview
mode frustratingly slow. In some situations, you could just run wintersmith build
and browse the rendered html from disk, but this won't work in other cases:
/about
How about a wintersmith preview --static
or wintersmith build --serve
option that simply runs build
then serves static content from the build folder?
Can someone share a snippet how to implement a minimal pager for posts in Wintersmith?
Previewing the newly created site raises the following error:
starting preview server
using config file: /opt/contrib/groovematic/config.json
server running on: http://localhost:5000/
node.js:134
throw e; // process.nextTick error, or 'error' event on first tick
^
TypeError: Object #<Object> has no method 'relative'
at /home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/lib/content.js:173:31
at Object.contents (/home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/node_modules/async/lib/async.js:532:23)
at /home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/node_modules/async/lib/async.js:467:24
at /home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/node_modules/async/lib/async.js:86:13
at Array.forEach (native)
at /home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/node_modules/async/lib/async.js:26:24
at Object.forEach (/home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/node_modules/async/lib/async.js:85:9)
at Object.parallel (/home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/node_modules/async/lib/async.js:466:19)
at /home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/lib/server.js:44:22
at /home/iromli/.nvm/v0.4.12/lib/node_modules/wintersmith/node_modules/async/lib/async.js:517:34
Hi,
Is it possible to tell Wintersmith to ignore a folder on build?
I'm using Compass and wish for WS to ignore my 'sass-src' folder so it's not copied and placed in the build dir.
cheers
I've been creating a new ContentPlugin for Jade. You can view the source here on github, https://github.com/smebberson/wintersmith-jade.
The basic idea was that I wanted to use Jade to render content pages, rather than only using markdown. The reason being, is that I wanted to define more structure in my content (i.e. html5 section tags) than what markdown afforded me (no ability to define tags).
My plugin is essentially working, however, I've had to edit some core code, being the ContentTree constructor so that it would recognise index.jade files as indexes. You can view my changes to wintersmith core here, smebberson@ee44c94.
Is there a better way to do this?
When specifying filename: /foo/bar/
, it should auto-expand to /foo/bar/index.html
Hi,
Can you advise if I can assign the '``` element a class from within index.jade or even article.jade ?
Thanks
Any way to require other node modules to make template functionality easier?
For example...
wintersmith preview --require moment
p.date= moment(article.date).something();
(for parsing/printing dates)
Is there a way to deploy the website under a relative path instead of a webserver's root ?
This would be very useful in lots of scenarios like deploying to dropbox or an intranet where the root's context is already taken.
when installing via npm, I don't have the ../lib/ folder where I assume you want to compile the ../src/ folder to. Did it myself and everything works fine :)
I plan on using wintersmith to build a GitHub Pages site, where I can specify a custom 404 page. It would be fantastic to be able to preview this and have it operate as it would on GitHub or maybe even S3 (they allow custom 404 pages there too).
Let's say I have an index.md file and I want to point it to my FAQ page:
Go see my [FAQ](faq.md).
The problem is that this link is broken in the preview, but it can work just fine if you have a markdown-enabled browser of some sort.
I would like for the markdown version of my files to link to other markdown files and the HTML versions to link to HTML. Would you add the feature so the file extension is checked against what content plugins would parse and use the resulting file extension from after parsing?
Metadata section of *.md gets rendered to the page as if it was valid content
I think this line split_idx = content.indexOf '\n\n' # should probably make this a bit more robust
is responsible for it in file wintersmith / src / plugins / markdown-page.coffee :(37)
Hi,
is there any way to format the output of an articles date?
title: Hello World
date: 2012-01-31 15:00
Currently, this date outputs to : Tue Jan 31 2012 15:00:00 GMT+1100 (EST)
I would like to have it formatted as '31 Jan 2012'.
I know I could just create another custom metadata item like "myDate: 31 Jan 2012", but it would
be cool to have it automatically formatted so I dont need to worry about updating it.
The parser for the metadata converts all keys to lowercase, but this is undocumented to users. Since metadata is accessed through JS code, users may try to camelCase for multi-word key names, as is the convention.
I'd suggest either removing the conversion to lowercase (it's unclear why it's necessary), or adding a note in the documentation. I'm happy to fork and submit either change, but wanted to check which was preferred.
when in preview mode navigating to localhost:8080/
renders index.html
, however navigating to localhost:8080/index.html
returns 404 not found..
Hi!
you have any idea why is so slow serving static assets?
200 /assets/js/main.js 2159ms
200 /articles/bamboo-cutter/Taketori_Monogatari.jpg 2167ms
200 /assets/css/main.css 2290ms
Can't access the output directory via the plugin infrastructure. I ended up using a workaround like:
MyTemplate.fromFile = (filename, base, callback) ->
outputDir = base.replace /\/templates$/, '/build'
This won't work if the user configures a custom output directory.
Or any other way to implement comments?
Is there a way to prevent the JADE templates from being compressed when they are compiled? The source view of compiled templates is ugly as hell and i'd like to keep them pretty :)
Hi,
I've noticed an issue with image paths in 3 separate installations of WS.
All my image url paths are missing a forward slash in the http:// path.
Even though I have set my URL of 'http://local.blog.com' in the config.json, its still out putting http:/local.blog.com.
See http://cl.ly/1p3h2R3j3D0j1D3O0P45
Cheers
The date parsing feature may not be strict enough:
However with a bogus date string I noticed an odd behaviour:
I really hoped the date parsing would do some validity checks for me (e.g. check against the length specified in the format and check for numbers vs. strings).
Is this the desired behaviour or a bug?
Also: moment("") and moment(null) both result in null being returned. For an empty string should that be null or Invalid Date?
Ive been reading though the documentation and I've been trying to find a way to create a blog. All you'd really need is the ability to list out "posts". So I'm assuming it would be a plugin or some sort.
If you can point me in the right direction I should be able to get something working :)
Do you have any plan on exposing default plugins?
I have a case where I just wanted to add moment.js to local context, but I ended up copy&paste-ing JadeTemplate
, as it's not exposed to wintersmith
….
It would be great if I can have an access to it, so that I can write this instead:
moment = require 'moment'
module.exports = (wintersmith, callback) ->
class JadeMomentTemplate extends wintersmith.TemplatePlugin.jade
render: (locals, callback) ->
locals.moment = moment
super
wintersmith.registerTemplatePlugin '**/*.jade', JadeMomentTemplate
callback()
Let me know your opinion of adding external modules to local context, if you have solved this case somewhere already :)
Firstly, thanks for wintersmith - it looks like a really nice approach to the static site generation problem.
I'm trying to use wintersmith and the swig plugin to build a blog. However it seems like on the default generated site the logic to gather the articles for the homepage and archive page is included in the .jade
templates. I can't see how I could replicate this with a swig template.
Should I be creating a content plugin which somehow massages the data into a format which can be output by a logic-less templating language? Or is there some other way to make it so that the index/archive templates are passed just the data they need already sorted/ filtered?
I'm trying to work on a plugin, and have come across this odd issue, where my coffee script file won't compile. I'm using the TextPlugin example code from the readme page and this is the error being returned:
/Users/smebberson/Sites/scottmebberson/myplugin.coffee:1
th, callback) ->
^
error Unexpected token >
This is the contents of the myplugin.coffee file:
module.exports = (wintersmith, callback) ->
class TextPlugin extends wintersmith.ContentPlugin
constructor: (@_filename, @_text) ->
getFilename: ->
@_filename
render: (locals, contents, templates, callback) ->
# do something with the text!
callback null, new Buffer @_text
TextPlugin.fromFile = (filename, base, callback) ->
fs.readFile path.join(base, filename), (error, buffer) ->
if error
callback error
else
callback null, new TextPlugin filename, buffer.toString()
wintersmith.registerContentPlugin 'text', '**/*.txt', TextPlugin
callback() # tell the plugin manager we are done
I've tested on node 0.8.1 and 0.6.12. I'm running Mac OS X, Lion. I can also compile the file with straight coffee-script cli no worries...
Any ideas?
path.exists is now called fs.exists
Switch default templating plugin to nunjucks
http://nunjucks.jlongster.com/
https://github.com/jbuck/wintersmith-nunjucks
Wintersmith currently doesn't generate the folder hierarchy of a file, so when explicitly specifying a build filename with filename: /foo/bar/baz.html
, and when the directory /foo/bar/
doesn't exist yet, Wintersmith errors with Error: ENOENT, open '/Users/kkaefer/Sites/example.com/build/foo/bar/index.html'
I've created a plugin for Wintersmith that allows you to use Jade as a content plugin, not just a template plugin (I like a little bit more control over my HTML sometimes than what Markdown affords me).
You can see the plugin here, https://github.com/smebberson/wintersmith-jade
I've had to modify wintersmith however (smebberson@ee44c94) so that it can accept an index with a different extension.
What would be the best approach to making this a part of wintersmith? Should the wintersmith.registerContentPlugin accept a list of index filenames that it needs to be aware of?
I ran npm install -g wintersmith
then ./bin/dev/compile_coffee
, but this failed because ./node_modules/.bin/coffee
is not present, although I do have coffee-script installed. The suggested fix, npm install --dev
, just produced a lot of errors. I'm fairly new to node/npm, so maybe this is due to a problem with my config.
Instead, I just ran coffee -o ./lib -b -c ./src
, which then threw the following error:
SyntaxError: In src/content.coffee, reserved word "private" on line 89
I just did a find and replace in content.coffee to change private
to privatea
and everything seems to be working.
Any way I can get the directory names off the content tree? E.g. item._.directories[0].name or something?
See the variable another_summary
in the content metadata and the corresponding variable in the generated ContentTree. The ending period (.
) is missing. : (
Content
---
title: Some Title
date: 2012-10-14
template: note.jade
summary: Some Short summary.
another_summary: Let's see if this works.
---
Generated JSON from ContentTree
{ title: 'Some Title',
date: Sun Oct 14 2012 05:30:00 GMT+0530 (IST),
template: 'note.jade',
summary: 'Some Short summary.',
another_summary: 'Let\'s see if this works' }
Also, if I write the last element of the metadata in quotes, it shows error (just 'error' :D ) in console.
Example
---
title: Some Title
date: 2012-10-14
template: note.jade
summary: Some Short summary.
another_summary: "Let's see if this works."
---
The Markdown page parser splits metadata based on '\n\n', and the value of each metadata extends to the '\n'. Windows uses \r\n as EOL terminator, so metadata can't be found and if it were, it would include a spurious \r. Can be fixed chaining a .replace(/\r\n/g, '\n') right after reading the file converting the buffer to a string with buffer.toString()
Workaround for now is obviously to save such files with Unix EOL.
Please leverage a changelog file, even if you toss it in npmignore. It allows us users to see what changes we need to make to our own code when we're updating wintersmith itself.
I'm using the wintersmith-stylus plugin to compile a bunch of modularised stylus files. This is working well in preview mode but fails during a build since each file is compiled in isolation. For example, given the following:
├── bootstrap
│ ├── accordion.styl
│ ...
├── page.styl
├── site.styl
└── variables.styl
... each file is compiled into CSS in turn until page.styl
where it fails due to an undefined variable error. This is to be expected since site.styl
defines the overall style (using imports) and hence should be the only file that gets compiled.
What's needed is a way to explicitly list which files should be compiled by plugins. Unless I've overlooked it, this doesn't seem possible at the moment.
I would like to add tags per article, I'll put them in the metadata section.
And I would like to generate an aditional page per tag. How could I do that ? By a plugin?
Hi,
I've just installed wintersmith and attempted to build the new site and am getting this error :
wintersmith build
building site
using config file: /Users/chris/Sites/wintersmith/config.json
fs.js:356
binding.mkdir(path, modeNum(mode), callback || noop);
^
TypeError: Bad argument
at Object.mkdir (fs.js:356:11)
at /usr/lib/node_modules/wintersmith/lib/cli/build.js:47:25
at path.js:292:19
and thus, the build/
directory isn't created.
I removed & recreated the same demo site, and I also tried reinstalling wintersmith again, which is successful, however same issue again.
wintersmith preview
works fine, it's just wintersmith build
.
Any help is appreciated.
http://localhost:8080/ shows the (implicit) index.html file, but an explicit URL of http://localhost:8080/index.html fails with 404
The final build contains the correct index.html file.
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 is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
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.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.