PHP CSS JavaScript
Failed to load latest commit information.
.github Update issues template Sep 18, 2017
languages Update it_IT.po Oct 5, 2017
library Var name change and formatting. Oct 12, 2017
page-templates Remove template hooks. Oct 5, 2017
src/assets Target section instead of article in footer Oct 5, 2017
template-parts Merge pull request #1102 from JPOak/remove-template-hooks Oct 6, 2017
.babelrc Introduce webpack and restructure assets Aug 3, 2017
.editorconfig Add an .editorconfig file Jul 8, 2016
.gitignore Reintroduced WordPress Coding Standards for local Code Sniffing Oct 15, 2017
404.php Initial changes. Oct 2, 2017 Update changelog Oct 11, 2017
MIT-LICENSE.txt Remove executable permissions for files Jul 18, 2016 Updated README with package task information Oct 13, 2017
archive.php Remove role. Oct 3, 2017
codesniffer.ruleset.xml Reintroduced WordPress Coding Standards for local Code Sniffing Oct 15, 2017
comments.php Sync with Master Breadcrumb May 23, 2017
composer.json Remove executable permissions for files Jul 18, 2016
composer.lock Remove executable permissions for files Jul 18, 2016
config-default.yml Reintroduced WordPress Coding Standards for local Code Sniffing Oct 15, 2017
footer.php Remove data attribute for sticky footer Oct 11, 2017
functions.php Fix Travis CI Build Errors Mar 14, 2017
gulpfile.babel.js Reintroduced WordPress Coding Standards for local Code Sniffing Oct 15, 2017
header.php Remove template hooks. Oct 5, 2017
index.php Initial changes. Oct 2, 2017
package-lock.json Added missing dateformat package Oct 16, 2017
package.json Added missing dateformat package Oct 16, 2017
page.php Remove template hooks. Oct 5, 2017
screenshot.png Remove executable permissions for files Jul 18, 2016
search.php Remove template hooks. Oct 5, 2017
searchform.php Remove template hooks. Oct 5, 2017
sidebar.php Remove template hooks. Oct 5, 2017
single.php Remove template hooks. Oct 5, 2017
style.css Bump version number Oct 11, 2017
webpack.config.js Update inclusion and usage of dependencies Aug 3, 2017
woocommerce.php Initial changes. Oct 2, 2017


Gitter GitHub version license Buy Me a Coffee at

This is a starter-theme for WordPress based on Zurb's Foundation for Sites 6, the most advanced responsive (mobile-first) framework in the world. The purpose of FoundationPress, is to act as a small and handy toolbox that contains the essentials needed to build any design. FoundationPress is meant to be a starting point, not the final product.

Please fork, copy, modify, delete, share or do whatever you like with this.

All contributions are welcome!


This project requires Node.js v4.x.x to v6.11.x to be installed on your machine. Please be aware that you might encounter problems with the installation if you are using the most current Node version (bleeding edge) with all the latest features.

FoundationPress uses Sass (CSS with superpowers). In short, Sass is a CSS pre-processor that allows you to write styles more effectively and tidy.

The Sass is compiled using libsass, which requires the GCC to be installed on your machine. Windows users can install it through MinGW, and Mac users can install it through the Xcode Command-line Tools.

If you have not worked with a Sass-based workflow before, I would recommend reading FoundationPress for beginners, a short blog post that explains what you need to know.


1. Clone the repository and install with npm

$ cd my-wordpress-folder/wp-content/themes/
$ git clone
$ cd FoundationPress
$ npm install

2. Configuration

YAML config file

FoundationPress includes a config-default.yml file. To make changes to the configuration, make a copy of config-default.yml and name it config.yml and make changes to that file. The config.yml file is ignored by git so that each environment can use a different configuration with the same git repo.

At the start of the build process a check is done to see if a config.yml file exists. If config.yml exists, the configuration will be loaded from config.yml. If config.yml does not exist, config-default.yml will be used as a fallback.

Browsersync setup

If you want to take advantage of Browsersync (automatic browser refresh when a file is saved), simply open your config.yml file after creating it in the previous step, and put your local dev-server address and port (e.g http://localhost:8888) in the url property under the BROWSERSYNC object.

Static asset hashing / cache breaker

If you want to make sure your users see the latest changes after re-deploying your theme, you can enable static asset hashing. In your config.yml, set REVISIONING: true;. Hashing will work on the npm run build and npm run dev commands. It will not be applied on the start command with browsersync. This is by design. Hashing will only change if there are actual changes in the files.

3. Get started

$ npm start

4. Compile assets for production

When building for production, the CSS and JS will be minified. To minify the assets in your /dist folder, run

$ npm run build

To create a .zip file of your theme, run:

$ npm run package

Running this command will build and minify the theme's assets and place a .zip archive of the theme in the packaged directory. This excludes the developer files/directories from your theme like /node_modules, /src, etc. to keep the theme lightweight for transferring the theme to a staging or production server.

Project structure

In the /src folder you will the working files for all your assets. Every time you make a change to a file that is watched by Gulp, the output will be saved to the /dist folder. The contents of this folder is the compiled code that you should not touch (unless you have a good reason for it).

The /page-templates folder contains templates that can be selected in the Pages section of the WordPress admin panel. To create a new page-template, simply create a new file in this folder and make sure to give it a template name.

I guess the rest is quite self explanatory. Feel free to ask if you feel stuck.

Styles and Sass Compilation

  • style.css: Do not worry about this file. (For some reason) it's required by WordPress. All styling are handled in the Sass files described below

  • src/assets/scss/app.scss: Make imports for all your styles here

  • src/assets/scss/global/*.scss: Global settings

  • src/assets/scss/components/*.scss: Buttons etc.

  • src/assets/scss/modules/*.scss: Topbar, footer etc.

  • src/assets/scss/templates/*.scss: Page template styling

  • dist/assets/css/app.css: This file is loaded in the <head> section of your document, and contains the compiled styles for your project.

If you're new to Sass, please note that you need to have Gulp running in the background (npm start), for any changes in your scss files to be compiled to app.css.

JavaScript Compilation

All JavaScript files, including Foundation's modules, are imported through the src/assets/js/app.js file. The files are imported using module dependency with webpack as the module bundler.

If you're unfamiliar with modules and module bundling, check out this resource for node style require/exports and this resource to understand ES6 modules.

Foundation modules are loaded in the src/assets/js/app.js file. By default all components are loaded. You can also pick and choose which modules to include. Just follow the instructions in the file.

If you need to output additional JavaScript files separate from app.js, do the following:

  • Create new custom.js file in src/assets/js/. If you will be using jQuery, add import $ from 'jquery'; at the top of the file.
  • In config.yml, add src/assets/js/custom.js to PATHS.entries.
  • Build (npm start)
  • You will now have a custom.js file outputted to the dist/assets/js/ directory.


Local Development

We recommend using one of the following setups for local WordPress development:





Credit goes to all the brilliant designers and developers out there. Have you made a site that should be on this list? Please let me know


Here are ways to get involved:

  1. Star the project!
  2. Answer questions that come through GitHub issues
  3. Report a bug that you find
  4. Share a theme you've built on top of FoundationPress
  5. Tweet and blog your experience of FoundationPress.

Pull Requests

Pull requests are highly appreciated. Please follow these guidelines:

  1. Solve a problem. Features are great, but even better is cleaning-up and fixing issues in the code that you discover
  2. Make sure that your code is bug-free and does not introduce new bugs
  3. Create a pull request
  4. Verify that all the Travis-CI build checks have passed