If you've followed the chapters this far and set your first project with all the classes from the
wp boilerplate setup_theme command, you saw that you have an
src folder in the root of your project.
In that root folder, you have a bunch of folders with classes. We like to structure our projects by features, so for example, all
custom post type registrations will be located in the
Using the WP-CLI commands, you follow our folder structure so that all of your projects will have the same layout. This helps us with onboarding new developers to the project. They can know where things are from the start.
Here is a small tip from us: "Organize your projects by functionality".
As we already mentioned, try to be consistent and organized with your project. Here is the structure list generated by the libs. We will explain to you why and how we use all of these files:
Blocks are used, as the name implies, for the block editor. You can read about blocks in more detail in Blocks chapter.
This class is used to define all the configuration methods for your project like
rest routes namespace, and much more.
You can define your project's needs in this class as a static method that you can quickly use.
This class contains all the custom meta hooks for your project.
This class contains all the custom post type hooks for your project. We created a preset for you, so this class looks the same on all the projects.
This class contains all the custom taxonomy hooks for your project. Like custom post type, we created a preset for you, so this class looks the same on all the projects.
- Admin - Used in the admin (not block editor) part of your project. You can find the files inside the
assetsfolder with the
- Blocks - Used in the block editor part of your project. You can find the files inside the
src/Blocks/assetsfolder. As blocks are complicated, we have files loaded only in the admin-editor part of the project, those files have an
-editorsuffix. The rest of the files with no suffix load on the admin-editor part and the project's front end.
- Theme - Used in the theme (frontend) part of your project. You can find the files inside the
assetsfolder with no suffix. You would use these files for stuff related to your project that is not associated with components and blocks. (To be honest, we barely use these files.)
The usage of any of these classes is optional, and you can use only what you need. Eightshift Boilerplate
setup_theme command comes with all three classes already implemented. Keep in mind that enqueue classes work in combination with the Webpack build of your project.
We named all our files with
application in prefix. If you don't like the name, you can change it by providing the project overrides for constants used in the Eightshift-Libs. If you change the file names, you must make changes to the Webpack build process as well. For modifying the Webpack part you can check in the Webpack chapter.
This class is used to define all hooks related to the languages and translations for your project.
We use this file to change the logo link on the login page, but you can use it however you seem fit.
This is the main entry point file for all your classes. It implements DI container and autowiring with the main action that loads everything in your project inside the WordPress ecosystem. You can provide manual service classes here as well. We covered this in the autowiring chapter.
This class provides
manifest.json file location and helpers to return the full path for a specific asset. We will cover this in more detail in the manifest chapter.
This class is used to add all custom project implementation for media like adding custom image size, enabling SVG image, etc.
This class is used to change admin appearance. We use it to change the admin color palette depending on the environment.
These classes will handle the rest fields and routes for your project. We will cover this in more detail in the rest chapter.
This class is used to add admin menu options and configurations for theme options and settings.
This class is used to add filters used in escaping unsafe tags in the
This folder contains all of the files necessary to run the storybook in your project. Read more about it on this link.
As the name implies, this file is used to provide restrictions for files that will not be added to the git structure. Read more about it on this link.
This file provides similar restrictions but this time for files/folders that will not be checked with the eslint.
This file provides all the definitions used for linting Style (SCSS/CSS) files. Read more about it on this link.
This file contains all the vendor packages you are using in your project. They are added to your project using the
composer install command. Read more about it on this link.
Lock files are used to set the package version to the exact release. This ensures that everyone gets the same package version when doing the installation.
The same as
composer.lock but for node_modules.
This file contains all the node_modules packages you are using in your project. They are added to your project using the
npm install command. Read more about it on this link.
This file provides all the definitions used for linting PHP files. Read more about it on this link.
Postcss works in correlation with Webpack, and it defines what additional plugins you are going to use when building your css files. Read more about it on this link.
Readme is always good to have. You should always define here how to set up a new project and make project switching a breeze.