# Overview

### Standard Project Structure <a href="#standard-project-structure" id="standard-project-structure"></a>

Here is the standard project structure you'll see in DocPad projects:

* `my-website/`
  * `out/`
  * `source/`
    * `render/` (also `documents/`, for backwards compatibility)
    * `static/` (also `files/`, for backwards compatibility)
    * `layouts/`
  * `docpad.coffee`
  * `package.json`

#### The `out` Directory <a href="#the-out-directory" id="the-out-directory"></a>

This directory contains anything that DocPad generates. Any new files added to the `source` 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. ;-)

#### The `source` Directory <a href="#the-src-directory" id="the-src-directory"></a>

This directory contains your website's source files. It contains your layouts, files to be rendered and be in the output and files that are not to be rendered but will still be in the output. The `source` can have the following folders:

* The `layouts` directory
* The `render` directory (also `documents`, for backwards compatibility, for backwards compatibility))
* The `static` directory (also `files`

The `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.

**The layouts Directory**

Layouts work in a very similar way to files in `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.

Layouts should include child content, which is done using the `content` [template data](/core/template-data.md) variable. For instance, the code to use the content variable with the [Eco](https://github.com/sstephenson/eco/) templating engine via the [Eco DocPad plugin](https://github.com/docpad/docpad-plugin-eco) would be `<%- @content %>`.

**The render Directory**

These are files that we would like to render. Rendering occurs extension to extension in the same way the Ruby on Rails asset pipeline works. This means the document `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](http://coffeescript.org/) to JavaScript with the document `source/render/script.js.coffee` to `out/script.js` or writing a blog post that renders from [Markdown](http://daringfireball.net/projects/markdown/) to HTML with the document `source/render/blog/hello.html.md` to `out/blog/hello.html`.

The reason we do not support direct rendering from `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](http://coffeescript.org/) to JavaScript or using [CoffeeKup](http://coffeekup.org/) to HTML. However, if you really want to use just a single extension, such a thing is supported by the `renderSingleExtensions` meta property.

The other important aspect of files in `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](/core/meta-data.md).

**The static Directory**

Files in this folder, like those in `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.

#### The `docpad.coffee` file <a href="#the-docpad-coffee-file" id="the-docpad-coffee-file"></a>

The `docpad.coffee` file can have several different extensions. It defines DocPad's settings. You can find full documentation on the [Configuration docs page](/core/config.md).

#### The `package.json` File <a href="#the-package-json-file" id="the-package-json-file"></a>

This file is needed for every Node.js application. It defines the dependencies that your application requires, such as the DocPad version that your site is developed with and the plugins you are running. You can learn more about `package.json` files on [this page](https://learn.bevry.me/node/ecosystem) of our [Hands on Node Training](https://learn.bevry.me/node/preface).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docpad.bevry.me/start/overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.