This is a system to create a git-ified WordPress installation. The end result is that the entire WordPress installation is in git, with the following exceptions:
- WordPress itself is a submodule (see Note (2));
- the config file is included but the DB creds are not; they are stored in a separate file.
- anything in the root folder that is not related to this install is excluded;
- anything in wp-content is excluded except for
- themes/
- plugins/
- mu-plugins/
This results in a setup where WP can be set to any arbirary version, nothing extra generated by plugins is captured (such as a cache folder). It is fully WP-CLI compatible too.
SITE
├── .git
│ └── ...
├── .gitignore
├── README.md
├── git-update-wp.sh (1)
├── index.php
├── wordpress/ (2)
│ ├── wp-admin/
│ │ └── ...
│ ├── wp-content/ (3)
│ │ └── ...
│ └── wp-includes/
│ └── ...
├── wp-config-local.php (4)
├── wp-config.php (5)
└── wp-content/ (6)
├── index.php
├── mu-plugins/ (7)
│ ├── cnmd-site-core-functionality
│ └── cnmd-site-core-functionality-loader.php
├── plugins/ (8)
│ └── ...
└── themes/ (9)
├── genesis/
├── index.php
├── starter/
└── twentyfourteen/
(1) This is a helper script to update the WordPress submodule. View the source to see what it does, it's pretty straightforward.
(2) WordPress is a submodule. This means that only a reference to WordPress is in the site git repo, not the WP code itself. By using a submodule, you can test with basically any version of WordPress by simply checking out the appropriate version using git tags. Defaults to what is current. The source for it is the official release, git-ified for just this purpose, found here
(3) wp-content/ is moved out from under wordpress/ because a) Wordpress itself is a submodule that we want to treat as read-only and b) we want to keep the plugins and themes in our repo and doing this allows that.
(4) This file contains the DB creds, prefix and other site-specific settings. Excluded from the repo.
(5) The general config file is included in the repo, and loads wp-config-*.php as appropriate. This allows easy migration between development, staging and live without having to manage DB creds. View the contents of this file for more info on how it works.
(6) This is the wp-content/ that is actually used by the installation, and is referenced from wp-config.php
(7) mu-plugins/ is not created by default, so I add it and then optionally put my core functionality plugin in there.
(8) various plugins are optionally installed. The list of which ones is defined in addwpinstall.sh
(9) optionally install genesis and my starter theme, and delete everything but twentyfourteen/ of the default themes.
sources:
Managing and Deploying WordPress with git