Skip to content
A WordPress boilerplate theme making use of Timber, Gulp, SCSS, Babel etc - used in my other boilerplates.
PHP JavaScript HTML CSS
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
assets
includes
languages
src
templates
.babelrc
.eslintignore
.eslintrc.json
.gitignore
.stylelintignore
.stylelintrc.json
404.php
LICENSE
README.md
archive.php
author.php
composer.json
composer.lock
footer.php
functions.php
gulp.config.js
gulpfile.babel.js
header.php
index.php
package-lock.json
package.json
page.php
phpcs.xml
search.php
sidebar.php
single.php
style.css

README.md

_g WordPress Theme

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

This boilerplate is also used in my UnderscoreG WP and Cobblestone boilerplates. You can find more information there.

Installation

  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).

Deployment

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)

Why [...]?

ESLint & StyleLint Configuration

I use Prettier for (S)CSS and Airbnb Javascript Style Guide in combination with Prettier in JavaScript. I think Prettier defines some sane guidelines and I just really like the Airbnb Javascript Style Guide. 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.

PHP CS

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.

OOP

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.

Actions / Filters / Hooks

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.

Twig / Timber

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

Directory Structure

Most of the times I work with WordPress I build complete sites. Therefore for a longe time all dependencies (npm, composer) were managed at the root level of the project (one level above document root). I still think this is a very good way, but since I manage two kinds of WordPress boilerplates (Vanilla WP and Cobblestone WP) for different requirements (eg possibility to install dependencies outside of document root is not given with some hosters) I had to manage the boilerplate theme in two places. Now my boilerplate theme lives here and is used in both WordPress site boilerpaltes. In sites/projects managed with composer/Cobblestone/Bedrock I pull out the theme dependencies into the root directory. Also all development utils (ESLint, StyleLint, Gulp) are in the document root.

You can’t perform that action at this time.