A boilerplate theme based on Timber making usage of Gulp with LibSass, Babel, PostCSS etc. Perfect for custom developed themes and working with Advanced Custom Fields.

This boilerplate is also used in my Vanilla WP boilerplate. You can find more information there.

1. Clone the repository from Github into the themes directory or download the repository and unpack it into the themes folder.
2. Delete the .git folder.
3. Run composer install in the theme directory or composer install -d path/to/themes/directory from your project root if you have composer setup there too.
4. Run npm install in the theme directory.

This theme serves as a boilerplate so there's no sense in keeping it as a git-submodule (except in other boilerplates).

Only files needed for production should be deployed to the production server. Here are some tips:

• Run npm install and npm run build/gulp build in your CI/CD. Then you only deploy the built assets in assets to production server and not
  • The src folder with source assets to pr
  • package.json, package-lock.json, node_moduels
  • gulpfile.babel.js and gulp.config.js
• Deploy assets with sourcemaps only in staging and testing environments
• Run composer install --no-dev in your CI/CD or on your production server (vendor directory should not be deployed per se).
• Other files to exclude/not deploy:
  • LICENSE
  • phpcs.xml
  • README.md
  • .babelrc
  • .eslintignore
  • .eslintrc.json
  • .gitignore
  • .stylelintignore
  • .stylelintrc.json
• Direct Access to vendor directory should be forbidden/disabled (via .htaccess or NGINX configuration)

I use Prettier for (S)CSS and JavaScript. I think Prettier defines some sane guidelines. The WordPress Coding Standards do not really work for me for multiple reasons (and I use Prettier + Airbnb in other Projects too). You can always change ESLint (.eslintrc.json) and StyleLint (.stylelintrc.json) configurtion to fit your personal preferences. Personally I think if you don't develop for core you should always use modern coding style guides.

WordPress Coding Standards do not use modern PHP. I use PSR2 because they are the most common in PHP projects. Personally I think if you don't develop for core you should always use modern coding style guides.

I don't like forcing things into classes/objects if they are not really objects. I thinks namespaces are a perfect way to organize code and avoid polluting the global namespace / prefixing every function/class.

I don't like the idea of using a single "registry" class per theme/plugin to register all hooks. Instead in namespaced files functions are added to hooks directly after defining them - in classes I think it's best to do this in the constructors.

Because seperating logic and view makes life easier. Also Timber provides some very useful helper.