GithubHelp home page GithubHelp logo

jnordberg / wintersmith Goto Github PK

View Code? Open in Web Editor NEW
3.5K 89.0 333.0 1.61 MB

A flexible static site generator

Home Page: http://wintersmith.io/

License: MIT License

JavaScript 1.48% CoffeeScript 98.52%
static-site-generator nodejs wintersmith

wintersmith's Introduction

#Wintersmith

Wintersmith is a simple yet flexible static site generator. It takes contents (markdown, less, scripts, etc), transforms them using plugins and outputs a static website (html, css, images, etc) that you can host anywhere.

It ships with plugins for markdown and pug templates, if you need something else check the plugin listing or write your own!

Resources

Quick-start

First install wintersmith using npm:

$ npm install wintersmith -g

This will install wintersmith globally on your system so that you can access the wintersmith command from anywhere. Once that is complete run:

$ wintersmith new <path>

Where <path> is the location you want the site to be generated. This creates a skeleton site with a basic set of templates and some articles, while not strictly needed it's a good starting point.

Now enter the directory and start the preview server:

$ cd <path>
$ wintersmith preview

At this point you are ready to start customizing your site. Point your browser to http://localhost:8080 and start editing templates and articles.

When done run:

$ wintersmith build

This generates your site and places it in the build/ directory - all ready to be copied to your web server!

And remember to give the old --help a look :-)

Overview

A wintersmith site is built up of three main components: contents, views and templates.

Contents is a directory where all the sites raw material goes (markdown files, images, javascript etc). This directory is then scanned to produce what's internally called a ContentTree.

The ContentTree is a nested object built up of ContentPlugins and looks something like this:

{
  "myfile.md": {MarkdownPlugin} // plugin instance, subclass of ContentPlugin
  "some-dir/": { // another ContentTree instance
    "image.jpg": {StaticPlugin}
    "random.file": {StaticPlugin}
  }
}

Wintersmith

This content tree is provided in full to the views when rendering. This gives you a lot of flexibility when writing plugins, you could for example write a plugin that generates a mosaic using images located in a specific directory.

Wintersmith comes with a default Page plugin that renders markdown content using templates. This plugin takes markdown (combined with some metadata, more on this later) compiles it and provides it to a template along with the content tree and some utility functions.

This brings us to the second component, the template directory. All templates found in this directory are loaded and are also passed to the content plugins when rendering.

By default only .pug templates are loaded, but you can easily add template plugins to use a template engine of your choosing.

Check the examples/ directory for some inspiration on how you can use wintersmith or the showcase to see what others are doing.

Configuration

Configuration can be done with command-line options, a config file or both. The config file will be looked for as config.json in the root of your site (you can set a custom path using --config).

Options

Name Default Description
contents ./contents contents directory location
templates ./templates templates directory location
views null views directory location, optional
locals {} global site variables, can also be a path to a json file
require {} modules to load and add to locals. e.g. if you want underscore as _ you would say {"_": "underscore"}
plugins [] list of plugins to load
ignore [] list of files or pattern to ignore
output ./build output directory, this is where the generated site is output when building
filenameTemplate :file.html outputs filenames and paths according to a template. (documentation)
introCutoffs ['<span class="more', '<h2', '<hr'] list of strings to search for when determining if a page has an intro
baseUrl / base url that site lives on, e.g. /blog/.
hostname null hostname to bind preview server to, null = INADDR_ANY
port 8080 port preview server listens on

All paths can either be relative or absolute. Relative paths will be resolved from the working directory or --chdir if set.

Content Plugins

ContentPlugins transform content, each item in the content tree is represented by a ContentPlugin instance. Content plugins can be created from files matching a glob pattern or by generators.

The ContentPlugin class is that all content plugins inherit from. Subclasses have to implement the getFilename and getView instance methods and the fromFile class method - more info in the plugin guide.

All content plugins have the following properties (a property in wintersmith is simply a shortcut to a getter. i.e. item.filename is the same as calling item.getFilename())

Property Getter signature Description
filename getFilename() filename content will be rendered to
view getView() function used to render the plugin, e.g. the page plugin uses a view that passes the plugin and locals to a template
url getUrl(base) url for the content. base is from where this url will be resolved and defaults to config.baseUrl. for example you can call content.getUrl('http://myiste.com') to get a permalink to that content

The Page plugin

Wintersmith ships with a page plugin. This plugin is what the markdown page and many other content plugins build upon.

Model

The Page model (inherits from ContentPlugin)

Properties:

Name Description
metadata object containing the pages metadata
title metadata.title or Untitled
date Date object created from metadata.date if set, unix epoch time if not
rfc822date a rfc-822 formatted string made from date
body markdown source
html parsed markdown as html

A MarkdownPage is either a markdown file with metadata on top or a json file located in the contents directory.

---
title: My first post
date: 2012-12-12 12:12
author: John Hjort <[email protected]>
template: article.pug
----

# Hello friends!

Life is wonderful, isn't it?

or use json to simply pass metadata to a template:

{
  "template": "template.pug",
  "stuff": {
  	"things": 123,
  	"moar": [1, 2, 3]
  }
}

Pages are by default rendered using the template view. This view passes the page to the template provided in the metadata. Omitting the template key or setting it to none will cause the page not to be rendered.

Links

All relative links in the markdown will be resolved correctly when rendering. This means you can just place image.png in the same directory and simply include it in your markdown as ![my image](image.png)

This is especially convenient when using a markdown editor (read Mou if you're on a mac).

Metadata

Metadata is parsed using js-yaml and will be accessible in the template as page.metadata.

There are two special metadata keys, The first one is template which specifies what template to render the page with. If the key is omitted or set to none the page will not be rendered (but still available in the content tree).

The second one is filename which can be used to override the output filename of the page. See filename templating for advanced usage.

Templates

When a page is rendered to a template the page instance is available as page in the template context. The content tree is also available as contents and config.locals is the root object.

Plugins

A plugin is a function that's called with the wintersmith environment and a callback.

Plugins are loaded by adding a "require id" to config.plugins. This can be a path, local- or global module. It works just like you would expect a require() call to.

Plugin example:

fs = require 'fs'

module.exports = (env, callback) ->

  class SimonSays extends env.ContentPlugin

    constructor: (@filepath, text) ->
      @text = "Simon says: #{ text }"

    getFilename: -> @filepath.relative # relative to content directory

    getView: -> (env, locals, contents, templates, callback) ->
      callback null, new Buffer @text

  SimonSays.fromFile = (filepath, callback) ->
    fs.readFile filepath.full, (error, buffer) ->
      if error
        callback error
      else
        callback null, new SimonSays filepath, buffer.toString()

  env.registerContentPlugin 'text', '**/*.txt', SimonSays
  callback() # tell the plugin manager we are done

See the plugin guide for more info.

Using wintersmith programmatically

example:

var wintersmith = require('wintersmith');

// create the sites environment, can also be called with a config object. e.g.
// {contents: '/some/contents', locals: {powerLevel: 10}}, ..}
var env = wintersmith('/path/to/my/config.json');

// build site
env.build(function(error) {
  if (error) throw error;
  console.log('Done!');
});

// preview
env.preview(function(error, server) {
  if (error) throw error;
  console.log('Server running!');
});

// do something with the content tree
env.load(function(error, result) {
  if (error) throw error;
  console.log('Contents loaded!');
});

Check the source or api docs for a full list of methods.

Contributing

To run a development that compiles the coffee script files on the fly use the ./bin/dev/cli command. The chdir -C <path> flag is handy for pointing it to a test project to experiment with.

About

Wintersmith is written by Johan Nordberg using CoffeeScript and licensed under the MIT-license.

The name is a nod to blacksmith which inspired this project.

wintersmith's People

Contributors

acdlite avatar alexnormand avatar alexzeitler avatar andreypopp avatar benjie avatar daddye avatar daiz avatar dashed avatar davecturner avatar davidsivocha avatar dwabyick avatar edrex avatar eshacker avatar hamoid avatar hindol avatar jeromew avatar jiggak avatar jnordberg avatar kierdugan avatar lhagan avatar louh avatar lukaszklis avatar m90 avatar mazdermind avatar mnewt avatar tacomanator avatar tlvince avatar tusharmath avatar uvcrew avatar varikin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

wintersmith's Issues

Override MarkdownPage?

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?

Leverage Other Node Modules

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)

Move the "blog listing logic" out of index.jade

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?

Issue with building site

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.

Prevent compressing compiled JADE templates?

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

Plugins cannot be loaded if using wintersmith programmatically

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!

Needed to edit ContentTree constructor, to create a new ContentPlugin

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?

Custom 404 pages

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

Weird behavior by the last metadata element

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

---

Only lowercase keys allowed in page metadata

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.

leverage changelog

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.

Directory Names

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

Static preview option?

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?

Deploy to relative path

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.

Links to .md should translate to .html

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?

unable to install

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?

Node 0.4.x support

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

pager support?

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

Formatting Article Date

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.

Plugins problem

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.

Ignore folder(s) on build.

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

Support for asynchronous content plugins?

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?

Warnings

path.exists is now called fs.exists

Parsing validation may not be strict enough

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?

Includes list for build option

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.

Tag management

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?

Generate folder hierarchy when specifying filenames

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'

Unable to complete plugin, due to index file names being hardcoded

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?

Trouble with md files using Windows EOL format

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.

Move view logic out of templates

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

Compiled ../lib/ not in npm

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

Creating a blog

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

Access to default plugins

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

wintersmith preview not working

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)

Error on build & preview

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?

Separate theme from content?

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

Make output directory accessible to plugin

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.

Only 404's on windows in "preview".

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

Slow servering assets

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

Plugin won't compile

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?

Issues installing wintersmith

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.