_g WordPress Theme
- Clone the repository from Github into the
themesdirectory or download the repository and unpack it into the
- Delete the
composer installin the theme directory or
composer install -d path/to/themes/directoryfrom your project root if you have composer setup there too.
npm installin 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:
npm run build/
gulp buildin your CI/CD. Then you only deploy the built assets in
assetsto production server and not
srcfolder with source assets to pr
- Deploy assets with sourcemaps only in staging and testing environments
composer install --no-devin your CI/CD or on your production server (
vendordirectory should not be deployed per se).
- Other files to exclude/not deploy:
- Direct Access to
vendordirectory should be forbidden/disabled (via
.htaccessor NGINX configuration)
ESLint & StyleLint Configuration
.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.
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.
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.