jnordberg / wintersmith Goto Github PK

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?

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).

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.

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.

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?

Hi,
Can you advise if I can assign the '``` element a class from within index.jade or even article.jade ?

Thanks

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?

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?

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?

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:

• ContentPlugin
  loads and preprocesses content
  provides a 'view' property to tell ws what view to pass it to
• ViewPlugin
  called with a content plugin instance to render
  should call back with a read stream and a filename to write to
• TemplatePlugin
  helper plugin passed to the view plugin when rendering

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 :)

when in preview mode navigating to localhost:8080/ renders index.html, however navigating to localhost:8080/index.html returns 404 not found..

Is it somehow possible to concat files with a plugin, e.g. for minification?

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 :)

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.

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 :)

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.

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)

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.

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

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

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?

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 :)

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'

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?

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)

The date parsing feature may not be strict enough:

• moment("20120101") gives Invalid Date (probably it would understand it as unix time?)
• moment("2012-01-01") parses the date correctly
• moment("20120101", "YYYYMMDD") parses it correctly as well

However with a bogus date string I noticed an odd behaviour:

• moment("a") correctly gives Invalid Date
• moment("a", "YYYYMMDD") on the other hand results in: Sat Jan 01 0 00:00:00 GMT+0000 (GMT)

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?

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?

Any way I can get the directory names off the content tree? E.g. item._.directories[0].name or something?

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?

When specifying filename: /foo/bar/, it should auto-expand to /foo/bar/index.html

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

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.

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?

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?).

Or any other way to implement comments?

Switch default templating plugin to nunjucks

http://nunjucks.jlongster.com/
https://github.com/jbuck/wintersmith-nunjucks

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.

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.

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:

1. If the site uses absolute links, such as /about
2. When using Chrome with a site that that downloads resources via AJAX (Chrome blocks AJAX calls from pages loaded from disk).

How about a wintersmith preview --static or wintersmith build --serve option that simply runs build then serves static content from the build folder?

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.

path.exists is now called fs.exists

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

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

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.

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."

---

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!

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.

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 :)

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)

Can someone share a snippet how to implement a minimal pager for posts in Wintersmith?