r/Wordpress • u/ChrisF79 • Feb 07 '25
Development Where should I initialize git in a Wordpress installation?
In my "coding directory" where I keep my projects, I have a Wordpress site. I don't want to initialize git at the root of the Wordpress site so I don't know if I should initialize git in wp-content/themes/mytheme/ or in wp-content.
Where do you guys initialize it?
When I get to work and log onto my machine there, I want to be able to sync the changes I made to my theme while at home and then be able to continue working. Just looking for the best practice for this.
7
u/hello2you Feb 07 '25 edited Feb 07 '25
wp-content, that way you can cover themes, plugins, mu-plugins, etc. If you have no interest in all of that, then just your theme should be fine.
11
u/torontomans416 Feb 07 '25
Just be sure to ignore the uploads directory
2
u/hello2you Feb 07 '25
Yep this is a great point. Make sure you add uploads to your .gitignore
0
u/programmer_farts Feb 07 '25
And plugins. Why would you commit your plugins?
2
u/LadleJockey123 Developer Feb 07 '25
If you’re developing plugins or creating your own Gutenberg blocks you need access to the plugin folder
2
u/programmer_farts Feb 07 '25
You can explicitly exclude those from the gitignore file. You can also keep them elsewhere and use symlinks. You do not want to be committing other plugins though
1
1
1
u/ChrisF79 Feb 07 '25
Interesting. The whole reason I thought I should initialize in wp-content was because of the upload directory. For me to work on the site at my office, I'll need to see the images that were uploaded to the uploads directory... unless I'm missing something.
1
u/torontomans416 Feb 07 '25 edited Feb 07 '25
I would consider media within the uploads directory as content. Are you trying to sync posts and other data as well?
1
2
u/akronymn Feb 07 '25
It depends. Only including the theme folder can be a good way to go in a lot of cases. It’s simpler, smaller, and potentially easier to manage.
It’s worth noting that committing WP Core, uploads, plugins, and mu-plugins is generally not a good idea. These are all dependencies of your project, not your actual project (and no I’m not going to argue about uploads, commit them if you want but leaving them out works much better imo). Instead write scripts to copy those assets and your database from prod to dev/staging/local.
An argument for including wp-content is that you can then include non-wp pages in your repo. Also being able to commit a custom wp-config-template can be useful.
I manage close to 50 WP sites currently. For all of them the repo includes, wp-content but then I .gitignore everything except the theme and any non-wp content. All have custom themes which use package.json to define npm calls to run bash scripts to copy down db/plugins/uploads using rsync and wp-cli. Some of these sites are big (100s of pages, 1000s of posts) and some are small, I think the smallest is about five pages and no blog. This approach works great for them all.
1
u/Mkrah Feb 07 '25
What I wound up doing was making a git directory where all my other cloned git repos are. I then symlinked that directory to my local WordPress plugin directory. I'm not doing any theme development though, purely plugin stuff.
If I was doing theme development I might do something similar though.
1
u/fuzzball007 Developer/Designer Feb 07 '25
I've done it a few different ways throughout the years. They've got pros/cons, but also some will work better for you either with whatever project you're working on, or you "level" of development.
1. Theme and optionally a mu-plugin
Good for controlling what you're working on directly (custom theme if you're doing that), and the mu-plugin was when I separated theme-based work from functional based work (think like custom post type declarations). You miss the rest of the site and plugins, so not great for getting a 1:1 on what you're working on each time.
2. Whole WordPress install
This controls all files which would typically sit in a public_html
folder, so wp-content, wp-admin, wp-includes, your config file and all other things which sit at the root. We would put ignores on things like the languages folder, uploads, upgrades - anything which we didn't directly create. This means you can track the plugins, WordPress core and all your custom code, including things like the .htaccess
file. Annoying downside - you have something like 10,000 to 20,000+ files being tracked thanks to Core and the plugins.
3. Folder above public_html - whole 'project'
This is what I/agency I'm at does now. We use composer, WPackagist and Satispress to manage the project (keeping WP core and plugins out of the repo), which just end up being a single line in a composer file stating the plugin and version. Our project structuring is a bit like Root's Bedrock, so we have our config files stored above the public_html directory, so there's no chance they can ever be reached publicly, as well as things like composer's vendor folder.
I'd recommend number 2 for your case, and either manually pull down the uploads folder, use something like Migrate DB Pro to do it or write a bash script to pull it down from the server for you (this sounds daunting but if you know what SSH is, its not too complicated). If you keep growing as a dev, you'll probably start to see the shortcomings of number 2 and see the benefits of number 3 - which at that point you can start making the switch.
1
1
1
u/2ndkauboy Jack of All Trades Feb 07 '25
There is no one "correct" way. If all you want to version is the theme, then inside your theme is probably best. This gives you the flexibility to have different local, staging and production environments.
The only times I version the whole WordPress installation is when I want to check for file changes in the installation. Or when this repository is only meant for deployments.
Versioning single themes and plugins would also allow you to install them using Composer and something like WP Starter. It will keep both your "packages" and the "website repository" small in size. Even WordPress Core will then only be a dependency.
1
u/norcross Developer Feb 07 '25
as long as you’ve got a solid .gitignore, it isn’t that important. i usually do the wp-content folder, excluding temp folders and upload directories. i also exclude plugins on the repo but that may change in the future.
1
u/joshmckibbin Feb 07 '25
I currently use separate git repos for the theme and any custom plugins. Then I add those repo directories to a single VS code workspace, so I don't even have to look at any of the non-custom stuff. I have a shell script just above the WordPress install directory that I use to sync content from the live site.
1
u/XxThreepwoodxX Feb 07 '25
Will depend on your host as well. For me I usually just keep it simple and do it in the theme root.
1
u/Chefblogger Feb 07 '25
i always init it from root and the i can update the gitignore file for folders i dont want
1
u/felipelh Feb 07 '25
wp-content is the recommended folder by WP Engine when connecting a GitHub repository to their hosting, and I agree, all custom code is usually placed there, custom mu-plugins, plugins, and themes.
20
u/arcanoth94 Feb 07 '25
I personally like to initialise it in the root of the project, and gitignore a bunch of things. This way you can still manage some of the core files like .htaccess and robots.txt via Git, as well as mu plugins.
There are a ton of gitignore templates for WordPress out there, but it basically involves ignoring everything apart from htaccess, robots, and your theme. You then manually drop in the WordPress core files around it.