A boilerplate child-theme for GeneratePress making usage of Gulp with LibSass, Babel, PostCSS etc. Perfect for custom developed themes and working with GenerateBlocks and Advanced Custom Fields.
✅ Use SCSS
✅ Use React to build custom Gutenberg blocks
✅ Use modern JavaScript (ES6) which get's transpriled
✅ Use GeneratePress and GenerateBlocks for fast site building
✅ Combine GeneratePress, GenerateBlocks and Gutenberg styles (colors, typography)
✅ Use ACF for custom blocks
- Clone the repository from Github into the
themes
directory or download the repository and unpack it into thethemes
folder. - Delete the
.git
folder. - 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
andnpm run build
/gulp build
in your CI/CD. Then you only deploy the built assets inassets
to production server and not- The
src
folder with source assets package.json
,package-lock.json
,node_moduels
gulpfile.babel.js
andgulp.config.js
- The
- 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 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.
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.