Skip to main content
To keep things nice and consistent across all the different projects we’re working on, it’s helpful to follow the same general structure across projects. However, older projects may not follow this structure, and it’s not always possible to update them. If you’re working on an older project, you should still try to follow the same principles, but you may need to make some exceptions.

​
General Structure

We typically use the VIP Go Skeleton structure or a modified version of it, with the following top-level files and directories:

​
VIP Projects

Skeleton repository: WP VIP Skeleton You may see additional folders or files in the skeleton repository, but the following are the most important: .devcontainer/ - Configuration for Visual Studio Code’s Remote Development extension. client-mu-plugins/ - Must-use plugins for the site.
docs/ - Documentation for the project.
plugins/ - Plugins for the site.
themes/ - Themes for the site.
vip-config/ - VIP-specific configuration files.
.editorconfig - Editor configuration file.
.gitignore - Git ignore file.
.phpcs.xml.dist - PHP CodeSniffer configuration file.
README.md - Project readme. Use the readme creator to get a nice-looking readme.
composer.json - Composer configuration file.

​
Non-VIP Projects

Skeleton repository: TK’s fork of WP VIP Skeleton This is a fork of the VIP Go Skeleton that provides a simpler structure that is meant to be used outside of the WP VIP platform. mu-plugins/ - Must-use plugins for the site.
docs/ - Documentation for the project.
plugins/ - Plugins for the site.
themes/ - Themes for the site.
.editorconfig - Editor configuration file.
.gitignore - Git ignore file.
.phpcs.xml.dist - PHP CodeSniffer configuration file.
README.md - Project readme. Use the readme creator to get a nice-looking readme.
composer.json - Composer configuration file.

​
Code Location

When adding new code to a project, it is important to figure out its proper place. Generally, code falls into one of three categories: must-use plugins, plugins, or themes. Keep in mind, the term “plugins” might refer to both must-use plugins and regular plugins. Typically, code in themes should contain only code related to the frontend. This includes obvious things like HTML output, enqueueing static assets, etc. In most projects, backend code that must be available at all times should live inside mu-plugins as separate modules. Using mu-plugins means the code can assume the whole codebase is active, and ensures that code can be separated as desired by developers. Each mu-plugin directory should contain a main plugin file with a plugin comment header, just like regular plugins. These directories should typically be named {project}-{module name}, as you may also want to add common libraries. The mu-plugin main file needs to be loaded manually by adding the file to mu-plugins/plugin-loader.php’s array: 
$tk_mu_plugins = [
    'project-some-module/plugin.php',
    'project-other-module/plugin.php',
];
On most projects, the plugins directory only contains third-party plugins. For multisite projects, it should also contain per-site functionality that may need to be enabled only for certain sites. Plugins should be generally focussed on single, modular pieces of functionality. For example, rather than a plugin containing all your rewrite rules, you should have rewrite functionality in each feature’s plugin. You might also want to have helper functionality in a central place, but this should be structured as a library and do nothing independently.

​
Plugin Structure

Plugins should follow a consistent file structure:
Coming soon…

​
Theme Structure

Depending on what project you look at this structure will be slightly different.
  • .vscode/ - Configuration and extension suggestion for Visual Studio Code.
  • acf-json/ - ACF JSON files.
  • inc/ - Houses the asset enqueueing file and the hooks file. Can also contain other files for additional functionality.
  • parts/ - Common template parts.
  • specs/ - Playwright tests go in this folder.
  • src/ - Houses the source code for the theme.
    • fonts/ - Font files.
    • images/ - Image files.
    • js/ - JavaScript files.
    • scss/ - SCSS files.
  • templates/ - Houses the page templates.
  • patterns/ - Houses the block patterns.
  • .gitignore - Git ignore file.
  • .stylelintrc - Stylelint configuration file.
  • composer.json - Composer configuration file.
  • composer.lock - Composer lock file.
  • functions.php - The main theme file.
  • package-lock.json - NPM lock file.
  • package.json - NPM configuration file.
  • postcss.config.js - PostCSS configuration file.
  • prettier.config.js - Prettier configuration file.
  • readme.txt - Theme readme, if desired.
  • screenshot.png - Theme screenshot.
  • style.css - The required css file for the theme.
  • tailwind.config.js - Tailwind configuration file.
  • theme.json - Theme configuration file for WordPress 5.8 and up.
  • tsconfig.json - TypeScript configuration file.
  • webpack.config.js - Webpack configuration file.

​
style.css

Your main style.css file should contain the theme’s header comment.
This file only contains theme information but no actual styles.
Styling is done in src/scss or handled by TailwindCSS.
TailwindCSS classes are always preferred but you can use @apply when needed.