my-website/
out/
source/
render/
(also documents/
, for backwards compatibility)static/
(also files/
, for backwards compatibility)layouts/
docpad.coffee
package.json
out
Directorysource
directory will be found here after being rendered and written by DocPad. However any files that are deleted from the source
directory will not be deleted from the out
directory by DocPad, you have to delete them manually. So if you remove a file and it's still there remember to delete it manually. ;-)source
Directorysource
can have the following folders:layouts
directoryrender
directory (also documents
, for backwards compatibility, for backwards compatibility))static
directory (also files
render
and documents
directories, and the static
and files
directories, are merged; files appearing in either are rendered or copied to the output. However, you should use the former names rather than the latter to conform with the latest naming conventions.render
, in that they are rendered and they support meta data. Unlike the files in render
, however, they are not output to the out
directory, as they only exist to wrap files in render
and other layouts within themselves. Layouts work in a nested fashion, with the desired layout being defined by the layout
meta data property within the child layout/document.content
template data variable. For instance, the code to use the content variable with the Eco templating engine via the Eco DocPad plugin would be <%- @content %>
.source/render/hello.ext1.ext2.ext3
is rendered from ext3
to ext2
, then from ext2
to ext1
, resulting in the file out/hello.ext1
. More common examples of this are rendering CoffeeScript to JavaScript with the document source/render/script.js.coffee
to out/script.js
or writing a blog post that renders from Markdown to HTML with the document source/render/blog/hello.html.md
to out/blog/hello.html
.script.coffee
to script.js
is that such a convention would eliminate the ability to combine extension renderings, also because ambiguity between extensions that can be rendered in multiple ways. For instance the coffee
extension could be rendered using CoffeeScript to JavaScript or using CoffeeKup to HTML. However, if you really want to use just a single extension, such a thing is supported by the renderSingleExtensions
meta property.render
is that they support meta data. Meta data goes at the top of a document and defines information about that particular document. For instance, its title, date and layout are good examples. Meta data is not restricted to particular values, meaning you can define whatever meta data you want against a document. There are some special meta data properties, however, that perform certain functions (e.g., layout
is used to specify the layout that should be used to wrap the document). You can find the complete listing of special meta data properties on the Meta Data page.render
, are output to the out
directory. The difference lies in that they are not rendered and do not support meta data. This is where you should put everything that doesn't need to be rendered or need meta data. For example, images, vendor files, plain stylesheet and JavaScript files, etc.docpad.coffee
filedocpad.coffee
file can have several different extensions. It defines DocPad's settings. You can find full documentation on the Configuration docs page.package.json
Filepackage.json
files on this page of our Hands on Node Training.