How should I structure a WP website project using git and updating from WP dashboard?

by

For months I’ve been trying to plan out a good project structure for using git version control for WordPress website development that doesn’t sacrifice the ability to update core and plugins through the WP dashboard, doesn’t require an unconventional directory structure (wp-content outside of the WP parent folder) and that is easy to manage and deploy whole websites. I’ve read about submodules, subtrees, nested repos, etc, and I’m still having a hard time fitting it all together and choosing the right strategy.

Here’s what I’m thinking right now, with my thoughts for how I would handle git repos in parenthesis.

root (main project repo)
|-- wordpress (public git repo added as subtree)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo added as subtree)
|    |    |    |-- other-plugin-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-plugin-without-git-repo (ignored/untracked)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo added as subtree)
|    |    |    |-- other-theme-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-theme-without-git-repo (ignored/untracked)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

This leaves me with several problems/questions;

  • Automatic updates; I love the new auto updates feature, it could potentially save a lot of time and effort in keeping my sites updated and secure, but it seems that it throws a wrench in tracking code changes with git. Is there any way to track my code changes while still allowing WordPress core to auto update?

  • Does having subtrees under the WordPress core repo prevent me from using git to merge in new core updates or pushing out my changes back to the WordPress core repo (if I ever decide I’d like to be a core contributor)?

  • For plugins that don’t have a public git repo, completely ignoring them creates the problem of not being able to quickly clone the entire site on a new server without manually copying files over to the server. It also causes a problem if I want to make changes to that plugin’s code those changes aren’t tracked and could easily be lost in a plugin upgrade.

So, to summarize, what is a good git+WordPress setup that avoids these problems? I would appreciate your feedback on my proposed project structure. Any way that you can help me improve this, would be much appreciated!

PS, if there is a better forum for this discussion, please point me there.

5

From my perspective there are two issues with your plan – Git and “conventional” structure. So basically everything. 🙂

  1. Git (and version control in general) is a poor tool for whole site stacks. Been there, done that, it hurt a lot.

  2. What you call an “unconventional” structure with content separated from core has been a very conventional and robust choice for any serious site for a while.

  3. There are pretty much no turn-key ways to combine whole site stack with native updates. It just doesn’t go well together since it tries to achieve different goals in projects of different levels (developer in control vs end user in control).

If you ask me the best bet for whole site WordPress stack is currently Composer, however opinions may wary. 🙂

On your specific concerns:

  1. As above – native updates (more so auto) don’t play well with tightly controlled stacks.

  2. WordPress core isn’t developed in Git and doesn’t accept pull requests, all contributions are (so far) via patch files to Subversion.

  3. You’ll likely have to commit such plugins into your repo. Or go with another approach like Composer.

Leave a Comment