<commit_before># Punchcard Demo [![Deploy](https://www.herokucdn.com/deploy/button.svg)](https://heroku.com/deploy?template=https://github.com/punchcard-cms/demo)

[![Build Status](https://travis-ci.org/punchcard-cms/demo.svg?branch=master)](https://travis-ci.org/punchcard-cms/demo) [![Coverage Status](https://coveralls.io/repos/github/punchcard-cms/demo/badge.svg?branch=master)](https://coveralls.io/github/punchcard-cms/demo?branch=master)

Quickly deploy [Punchcard CMS](https://github.com/punchcard-cms/punchcard) to Heroku, or use this repository as an example to deploy Punchcard anywhere.

## Requirements

Punchcard is a [Node.js](https://nodejs.org/) based headless Content Management System that uses [PostgreSQL](https://www.postgresql.org/) as its database. It requires the following at a minimum to run:

* Node.js - **6.0 or greater**
* PostgreSQL - **9.5 or greater**

In addition, it is recommended that [Yarn](https://yarnpkg.com/) is used for package management. This repository does so as an example. All relevant commands will be using Yarn, but the relevant NPM commands can be found in Yarn's [migration documentation](https://yarnpkg.com/en/docs/migrating-from-npm). For `run` commands (like `yarn run build`), substitute `npm` for `yarn`.

## Running Locally

Ensure that PostgreSQL is available on the command line and accessible via the `postgres` command. Create a user that has a password `<PASSWORD>` and ensure that there is a `punchcard` database created.

If working on a Mac, [Homebrew](http://brew.sh/) is a convenient way to install PostgreSQL up and running. After installing Homebrew, do the following:

1. Update Homebrew - `brew update`
2. Install PostgreSQL - `brew install postgres`
3. Start the PostgreSQL Server - `postgres -D /user/local/var/postgres`
4. In a new terminal window or tab, create a new PostgreSQL user and set the password to `<PASSWORD>` when prompted - `createuser punchcard -P`
5. Create a local database - `createdb -0 punchcard punchcard`

### Local Development Commands

When working locally, there are two things that need to run: the database and the server. There are a number of helper scripts that ship with this repository to help with that:

* `yarn run dev:database` - Runs PostgreSQL, assuming it's been installed via Homebrew
* `yarn run dev:start` - Runs [Gulp](http://gulpjs.com/) default task, as defined in the [Punchcard Runner](https://github.com/punchcard-cms/runner)
* `yarn run dev` - Runs `dev:database` and `dev:start`
* `yarn run lint` - Runs the Gulp `lint` task, as defined in the Punchcard Runner
* `yarn run build` - Runs the Gulp `build` task, as defined in the Punchcard Runner
* `yarn test` - Runs `lint`, then [tests](#testing), then `build`

## Testing

Canonically, Punchcard uses [AVA](https://github.com/avajs/ava) for testing (both as a runner and as an assertion library) and [nyc](https://github.com/istanbuljs/nyc) for code coverage. Due to [outstanding issues in later versions](https://github.com/punchcard-cms/punchcard/pull/480#issuecomment-252640369), nyc is pegged to v6. JavaScript is [linted](http://snugug.github.io/linting-for-fun-and-profit/#/) using [ESLint Config Punchcard](https://github.com/punchcard-cms/eslint-config-punchcard), using the relevant configurations (`node`, `ava`, or `browser`). Sass is linted using [Sass Lint](https://www.npmjs.com/package/sass-lint).

The basic test that ships with this repository checks to ensure that Punchcard can run with any modifications an end-user may want to make to the application coming from Punchcard. Custom input plugins are tested using [Punchcard Shared Tests](https://github.com/punchcard-cms/shared-tests).

## Punchcard Boilerplate

The following files and folders represent a fairly basic example of Punchcard Boilerplate to get Punchcard up and running. They are divided in to [server](#server-boilerplate), [browser](#browser-boilerplate), [test](#test-boilerplate), and [config](#config-boilerplate). There are also generated files that can be mostly ignored.

### Server Boilerplate

Server boilerplate are required (marked with `*`) and optional files and folders to get Punchcard running. All files and folders are relative to the running root of the application.

* `index.js`* - The main file to actually run. The file presented is the bare minimum file recommended to make Punchcard both run and be testable. Punchcard is a Promise that returns a configured Express application that can be extended as if it were a local Express application.
* `config`* - Punchcard [config](https://www.npmjs.com/package/config) configuration files
  * `config/default.js`* - Default configuration to be shared regardless of environment. Extends the core Punchcard config to provide all default configuration. Without this configuration extension, Punchcard will not run.
  * `config/test.js` - Configuration to be used when the Node Environment is `test`. Recommended to use `sqlite3` for testing as it's faster than a full PostgreSQL database. Options present here override the default config and fall back to the default if not present.
  * `config/production.js` - Configuration to be used the Node Environment is `production`. Recommend for production environments, with Environment Variables used to hold keys and other secrets. Options present here override the default config and fall back to the default if not present.
* `content-types`* - The folder to hold [Content Types](https://github.com/punchcard-cms/content-types#defining-a-content-type) for use with Punchcard. Punchcard extends the Content Type definition with a top-level attribute `workflow` that should be set to an ID of a provided workflow (below).
* `workflows`* -The folder to hold [workflows](https://github.com/punchcard-cms/punchcard/tree/master/workflows) for use with defined content types. Workflows can be set for a given content type by adding `workflow: ID` in a Content Type, with `ID` replaced by the ID of the approval workflow.
* `input-plugins` - The folder to hold custom [Input Plugins](https://github.com/punchcard-cms?utf8=%E2%9C%93&query=input-plugin) for use in Punchcard. A sample input plugin is provided.
* `views` - [Nunjucks](https://mozilla.github.io/nunjucks/) templates to be made available to Punchcard. Putting an identically named template at the identical relative path to a template in the core Punchcard module will overwrite the core template with the provided one
  * `views/content/add.html` - Template override for the Content Add template from Punchcard. Changes the URL of the provided browser JavaScript to the compiled one for the custom implementation.

### Browser Boilerplate

Browser boilerplate is based on the default source and destination targets using [Punchcard Runner](https://github.com/punchcard-cms/runner). These can be modified, and methods for compiling can be changed, as long as settings are updated as appropriate for Punchcard Runner.

* `src` - The folder to hold static files that will be served to the browser. Compiled versions will be made available in the `public` folder.
  * `src/images` - Images to be available in the browser. Will render to `public/images` and available in the `/images` folder from the browser
  * `src/js` - JavaScript files to be available in the browser. Will render to `public/js` and available in the `/js` folder from the browser
  * `src/sass` - Sass files to be rendered to CSS and available in the browser. Will render to `public/css` and available in the `/css` folder from the browser
    * `src/sass/style.scss` - Sass file that imports the Punchcard styling as an [eyeglass](https://github.com/sass-eyeglass/eyeglass) module. Will render to `public/css/style.css` and available at `/css/style.css` from the browser
* `Gulpfile.js` - Gulp task running file. The `application`, `server`, and `tasks.nodemon` configurations are for the server, whereas `tasks.build` is for the browser files. The two additional tasks, `punchcard:js` and `punchcard:images`, bring Punchcard provided JavaScript and Images in to this application's compiled `public` folder.

### Test Boilerplate

[Tests](#testing), while not required to run Punchcard, are recommended in order to ensure Punchcard runs and is extended as expected.

**AVA Tests**
* `tests` - Folder to run all tests
  * `tests/server.js` - Basic test using [SuperTest](https://www.npmjs.com/package/supertest) to ensure Punchcard is able to start

**Linting**
* `.eslintrc.yml` - [ESLint](https://www.npmjs.com/package/eslint) configuration for all Node code
* `.sass-lint.yml` - [Sass Lint](https://www.npmjs.com/package/sass-lint) configuration for all Sass code
* `src/js/.eslintrc.yml` - ESLint configuration for all Browser code
* `tests/.eslintrc.yml` - ESLint configuration for all Test code

### Config Boilerplate

There is a handful of general configuration files. Files that are required are marked with `*`.

* `.editorconfig` - [EditorConfig](http://editorconfig.org/) to hint to text editors how to behave
* `.gitignore` - Files and file patterns for Git to ignore
* `.nvmrc` - Node version for [Node Version Manager](https://github.com/creationix/nvm) to use. Helps ensure that the correct version of Node is being used given multiple versions of Node available on a system
* `.slugignore` - Files and file patterns to be ignored when Heroku (or Heroku-compatible system) builds the server deployment
* `.travis.yml` - Configuration file for [Travis](https://travis-ci.org/) Continuous Integration. Configures Travis to use Node 6, cache `node_modules` and Yarn's cache, install Yarn, run tests, and on success send code coverage to [Coveralls](https://coveralls.io/), create a new [semantic release](https://github.com/punchcard-cms/punchcard/blob/master/CONTRIBUTING.md#creating-a-release), update labels using [Reparo](https://reparo.herokuapp.com/), and deploy to Heroku after successful tests are run on the `master` branch, all while ignoring running any CI on release branches
* `Procfile` - Configuration file to tell Heroku (or Heroku-compatible system) what command to run for different contexts. Configures Heroku to run `yarn start` (the `start` script in `package.json`) when in a `web` context
* `app.json` - Heroku (or Heroku-compatible system) [application manifest](https://blog.heroku.com/introducing_the_app_json_application_manifest)
* `package.json`* - [Node configuration](https://docs.npmjs.com/files/package.json). In a production environment where deploys can happen from a Continuous Integration server, `gulp`, `gulp-concat`, `gulp-imagemin`, `gulp-uglify`, and `punchcard-runner` should all `devDependencies` and the `prestart` script should not exist
* `yarn.lock` - Generated [Yarn lock](https://yarnpkg.com/en/docs/yarn-lock)
<commit_msg>:memo: Fix missed 'be'<commit_after># Punchcard Demo [![Deploy](https://www.herokucdn.com/deploy/button.svg)](https://heroku.com/deploy?template=https://github.com/punchcard-cms/demo)

[![Build Status](https://travis-ci.org/punchcard-cms/demo.svg?branch=master)](https://travis-ci.org/punchcard-cms/demo) [![Coverage Status](https://coveralls.io/repos/github/punchcard-cms/demo/badge.svg?branch=master)](https://coveralls.io/github/punchcard-cms/demo?branch=master)

Quickly deploy [Punchcard CMS](https://github.com/punchcard-cms/punchcard) to Heroku, or use this repository as an example to deploy Punchcard anywhere.

## Requirements

Punchcard is a [Node.js](https://nodejs.org/) based headless Content Management System that uses [PostgreSQL](https://www.postgresql.org/) as its database. It requires the following at a minimum to run:

* Node.js - **6.0 or greater**
* PostgreSQL - **9.5 or greater**

In addition, it is recommended that [Yarn](https://yarnpkg.com/) is used for package management. This repository does so as an example. All relevant commands will be using Yarn, but the relevant NPM commands can be found in Yarn's [migration documentation](https://yarnpkg.com/en/docs/migrating-from-npm). For `run` commands (like `yarn run build`), substitute `npm` for `yarn`.

## Running Locally

Ensure that PostgreSQL is available on the command line and accessible via the `postgres` command. Create a user that has a password `<PASSWORD>` and ensure that there is a `punchcard` database created.

If working on a Mac, [Homebrew](http://brew.sh/) is a convenient way to install PostgreSQL up and running. After installing Homebrew, do the following:

1. Update Homebrew - `brew update`
2. Install PostgreSQL - `brew install postgres`
3. Start the PostgreSQL Server - `postgres -D /user/local/var/postgres`
4. In a new terminal window or tab, create a new PostgreSQL user and set the password to `<PASSWORD>` when prompted - `createuser punchcard -P`
5. Create a local database - `createdb -0 punchcard punchcard`

### Local Development Commands

When working locally, there are two things that need to run: the database and the server. There are a number of helper scripts that ship with this repository to help with that:

* `yarn run dev:database` - Runs PostgreSQL, assuming it's been installed via Homebrew
* `yarn run dev:start` - Runs [Gulp](http://gulpjs.com/) default task, as defined in the [Punchcard Runner](https://github.com/punchcard-cms/runner)
* `yarn run dev` - Runs `dev:database` and `dev:start`
* `yarn run lint` - Runs the Gulp `lint` task, as defined in the Punchcard Runner
* `yarn run build` - Runs the Gulp `build` task, as defined in the Punchcard Runner
* `yarn test` - Runs `lint`, then [tests](#testing), then `build`

## Testing

Canonically, Punchcard uses [AVA](https://github.com/avajs/ava) for testing (both as a runner and as an assertion library) and [nyc](https://github.com/istanbuljs/nyc) for code coverage. Due to [outstanding issues in later versions](https://github.com/punchcard-cms/punchcard/pull/480#issuecomment-252640369), nyc is pegged to v6. JavaScript is [linted](http://snugug.github.io/linting-for-fun-and-profit/#/) using [ESLint Config Punchcard](https://github.com/punchcard-cms/eslint-config-punchcard), using the relevant configurations (`node`, `ava`, or `browser`). Sass is linted using [Sass Lint](https://www.npmjs.com/package/sass-lint).

The basic test that ships with this repository checks to ensure that Punchcard can run with any modifications an end-user may want to make to the application coming from Punchcard. Custom input plugins are tested using [Punchcard Shared Tests](https://github.com/punchcard-cms/shared-tests).

## Punchcard Boilerplate

The following files and folders represent a fairly basic example of Punchcard Boilerplate to get Punchcard up and running. They are divided in to [server](#server-boilerplate), [browser](#browser-boilerplate), [test](#test-boilerplate), and [config](#config-boilerplate). There are also generated files that can be mostly ignored.

### Server Boilerplate

Server boilerplate are required (marked with `*`) and optional files and folders to get Punchcard running. All files and folders are relative to the running root of the application.

* `index.js`* - The main file to actually run. The file presented is the bare minimum file recommended to make Punchcard both run and be testable. Punchcard is a Promise that returns a configured Express application that can be extended as if it were a local Express application.
* `config`* - Punchcard [config](https://www.npmjs.com/package/config) configuration files
  * `config/default.js`* - Default configuration to be shared regardless of environment. Extends the core Punchcard config to provide all default configuration. Without this configuration extension, Punchcard will not run.
  * `config/test.js` - Configuration to be used when the Node Environment is `test`. Recommended to use `sqlite3` for testing as it's faster than a full PostgreSQL database. Options present here override the default config and fall back to the default if not present.
  * `config/production.js` - Configuration to be used the Node Environment is `production`. Recommend for production environments, with Environment Variables used to hold keys and other secrets. Options present here override the default config and fall back to the default if not present.
* `content-types`* - The folder to hold [Content Types](https://github.com/punchcard-cms/content-types#defining-a-content-type) for use with Punchcard. Punchcard extends the Content Type definition with a top-level attribute `workflow` that should be set to an ID of a provided workflow (below).
* `workflows`* -The folder to hold [workflows](https://github.com/punchcard-cms/punchcard/tree/master/workflows) for use with defined content types. Workflows can be set for a given content type by adding `workflow: ID` in a Content Type, with `ID` replaced by the ID of the approval workflow.
* `input-plugins` - The folder to hold custom [Input Plugins](https://github.com/punchcard-cms?utf8=%E2%9C%93&query=input-plugin) for use in Punchcard. A sample input plugin is provided.
* `views` - [Nunjucks](https://mozilla.github.io/nunjucks/) templates to be made available to Punchcard. Putting an identically named template at the identical relative path to a template in the core Punchcard module will overwrite the core template with the provided one
  * `views/content/add.html` - Template override for the Content Add template from Punchcard. Changes the URL of the provided browser JavaScript to the compiled one for the custom implementation.

### Browser Boilerplate

Browser boilerplate is based on the default source and destination targets using [Punchcard Runner](https://github.com/punchcard-cms/runner). These can be modified, and methods for compiling can be changed, as long as settings are updated as appropriate for Punchcard Runner.

* `src` - The folder to hold static files that will be served to the browser. Compiled versions will be made available in the `public` folder.
  * `src/images` - Images to be available in the browser. Will render to `public/images` and available in the `/images` folder from the browser
  * `src/js` - JavaScript files to be available in the browser. Will render to `public/js` and available in the `/js` folder from the browser
  * `src/sass` - Sass files to be rendered to CSS and available in the browser. Will render to `public/css` and available in the `/css` folder from the browser
    * `src/sass/style.scss` - Sass file that imports the Punchcard styling as an [eyeglass](https://github.com/sass-eyeglass/eyeglass) module. Will render to `public/css/style.css` and available at `/css/style.css` from the browser
* `Gulpfile.js` - Gulp task running file. The `application`, `server`, and `tasks.nodemon` configurations are for the server, whereas `tasks.build` is for the browser files. The two additional tasks, `punchcard:js` and `punchcard:images`, bring Punchcard provided JavaScript and Images in to this application's compiled `public` folder.

### Test Boilerplate

[Tests](#testing), while not required to run Punchcard, are recommended in order to ensure Punchcard runs and is extended as expected.

**AVA Tests**
* `tests` - Folder to run all tests
  * `tests/server.js` - Basic test using [SuperTest](https://www.npmjs.com/package/supertest) to ensure Punchcard is able to start

**Linting**
* `.eslintrc.yml` - [ESLint](https://www.npmjs.com/package/eslint) configuration for all Node code
* `.sass-lint.yml` - [Sass Lint](https://www.npmjs.com/package/sass-lint) configuration for all Sass code
* `src/js/.eslintrc.yml` - ESLint configuration for all Browser code
* `tests/.eslintrc.yml` - ESLint configuration for all Test code

### Config Boilerplate

There is a handful of general configuration files. Files that are required are marked with `*`.

* `.editorconfig` - [EditorConfig](http://editorconfig.org/) to hint to text editors how to behave
* `.gitignore` - Files and file patterns for Git to ignore
* `.nvmrc` - Node version for [Node Version Manager](https://github.com/creationix/nvm) to use. Helps ensure that the correct version of Node is being used given multiple versions of Node available on a system
* `.slugignore` - Files and file patterns to be ignored when Heroku (or Heroku-compatible system) builds the server deployment
* `.travis.yml` - Configuration file for [Travis](https://travis-ci.org/) Continuous Integration. Configures Travis to use Node 6, cache `node_modules` and Yarn's cache, install Yarn, run tests, and on success send code coverage to [Coveralls](https://coveralls.io/), create a new [semantic release](https://github.com/punchcard-cms/punchcard/blob/master/CONTRIBUTING.md#creating-a-release), update labels using [Reparo](https://reparo.herokuapp.com/), and deploy to Heroku after successful tests are run on the `master` branch, all while ignoring running any CI on release branches
* `Procfile` - Configuration file to tell Heroku (or Heroku-compatible system) what command to run for different contexts. Configures Heroku to run `yarn start` (the `start` script in `package.json`) when in a `web` context
* `app.json` - Heroku (or Heroku-compatible system) [application manifest](https://blog.heroku.com/introducing_the_app_json_application_manifest)
* `package.json`* - [Node configuration](https://docs.npmjs.com/files/package.json). In a production environment where deploys can happen from a Continuous Integration server, `gulp`, `gulp-concat`, `gulp-imagemin`, `gulp-uglify`, and `punchcard-runner` should all be `devDependencies` and the `prestart` script should not exist
* `yarn.lock` - Generated [Yarn lock](https://yarnpkg.com/en/docs/yarn-lock)

{'fraction_non_alphanumeric': 0.09970348406226835, 'fraction_numerical': 0.0027798369162342477, 'mean_word_length': 4.742218675179569, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 74, 'lorem ipsum': 0, 'www.': 14, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '432408', 'n_tokens_mistral': 6235, 'n_tokens_neox': 6002, 'n_words': 2562}