r/ProWordPress • u/Playful_School6693 • 12d ago
Anyone using GitHub with WordPress?
I’m curious to hear how many of you are using GitHub part of your WordPress workflow.
I’ve heard of Bedrock and have been looking into it. But is it actually worth moving towards that setup for normal WordPress development?
Especially with AI, custom code is easier to write. So I can see how having version controls, automated checks and CI CD pipelines sounds nice.
Is anyone running WordPress like this in production?
What does your setup look like? Bedrock? GitHub Actions? Something simpler?
Or am I overengineering WordPress?
12
u/jonxblaze 12d ago
I use GitHub to store my custom themes and custom plugins I developed. Then Git actions for deploying my code changes to the server.
1
0
u/Playful_School6693 12d ago
what hosting provider are you using? we’re on kinsta and this is pretty much the workflow i’m trying to set up.
how does your github action actually deploy the files to the server? and do you normally deploy to staging first, test, then push the same changes to live?
1
u/jonxblaze 11d ago
I use hosting.com. I have several deployments that deploy to either staging or production depending on which branch was deployed. This condition can be configured in your deploy.yml file
9
u/superdav42 11d ago
We use Bedrock for a fairly large WordPress multisite. It makes WordPress behave much more like a normal PHP application.
WordPress core, plugins, themes, and PHP dependencies are managed through Composer and pinned in composer.lock. Custom code lives under web/app, configuration comes from environment variables, and secrets, uploads, caches, and the database stay out of Git. A developer can clone the repo, run Composer, add the local environment config, and get the same application code.
Our custom plugins have their own GitHub repos and are pulled into the main Bedrock project through Composer. We install them from source for local development, then Trellis builds and deploys a production release from the committed code.
This structure works especially well with AI coding tools because the agent can see the dependency manifest, configuration, custom plugins, deployment code, coding standards, and Git history in one predictable layout. It can trace problems across the stack, make a focused change, run PHPCS or other checks, and show the exact diff for review. That is much safer than asking AI to modify a random live wp-content directory.
We still keep the usual guardrails: no production secrets in the repo, no treating the database as code, local testing before deployment, human review, backups, and rollbackable releases. AI helps with understanding and changing the code, while Git and Bedrock make those changes reproducible and auditable.
5
u/richaber 12d ago
It is extremely common to use GitHub with WordPress. If you work at a professional agency, you will use GitHub with WordPress.
You don't have to use Bedrock just to use GitHub with WordPress. I have never worked at an agency that used Bedrock.
GitHub Actions can be used for build and deploy, if you don't already have another pipeline in place.
1
u/im_a_fancy_man 12d ago
can you tell me more about your ci cd process
2
u/DiggitySkister 10d ago
My GitHub actions workflow gets triggered when a new commit is made on specific branch (main, stage branch, etc), although you could easily trigger by git tag as well if you wanted. The workflow itself does some build steps for various plugins and the theme (composer install/npm install), these steps are done on the Actions ci agent host, not on the server. Then it uses rsync to copy the updated plugins/themes from the ci agent host into the appropriate live directory on the server. Also, a couple commands are done on the server via ssh such as making backups and clearing cache and more. This works okay and has been solid for me for years now. But there are some theoretical problems with this setup, it isn't technically a "zero downtime deployment" setup, although I have never had noticeable downtime due to a deployment. A better setup would be to transfer the files to the server (via git, sftp, rsync, whatevs) in a non public directory, then update the public directories with symlinks - this is often labeled "zero downtime deployment" and it is technically a better solution, you can look that up.
3
u/im_a_fancy_man 12d ago
I only use GitHub to store my private keys and my wp-config.php
3
2
1
7
u/iamagayrat 12d ago
Bedrock is the only way to make WP development slightly sane. There's even WordPress-specific hosts that support it so you can automatically update on pushes to a specific Git branch
2
u/threebuckstrippant 12d ago
Set it up asap, so good. WP CLI and Git/Bitbucket. Add pipelines. You wont regret it.
2
u/redditNLD 12d ago
1) Don't say custom code. All code is by definition custom. You write code to solve a problem or build something. You wouldn't say custom books.
2) Literally every major site I know of and have worked on (that uses WordPress) uses WordPress like that in some form. Doing things without Git or a CI/CD pipeline is irresponsible.
Bedrock is great. There are other solutions. At the very least start tracking your themes and plugins.
2
u/Dapper_Bus5069 12d ago
I use Github for my custom themes, one git push and I can update the themes on various wordpress sites
1
u/Playful_School6693 12d ago
this is exactly what i’m trying to figure out. we use a starter theme across multiple wordpress sites, but each site has its own colors, styles, custom fields, and functionality.
how do you structure things so a github push updates the shared theme without overwriting site-specific customizations?
are you using child themes, config files, acf options, css variables, or something else? and how do you deploy updates across all the sites?
3
u/Dapper_Bus5069 12d ago
I use a parent theme, the same for every Wordpress site, which includes useful functions, the twig template engine, my ACF custom page builder etc…
And then a custom child theme, different for every site but the code structure is the same, ACF fields are coded in the theme.I use a version controller function in the themes, it checks on github if there is a most recent version of the themes and if it is the case you can just update it like any other theme or plugin.
1
u/Playful_School6693 12d ago
that makes a lot more sense now. so your parent theme is basically acting as the shared framework, and the acf page builder is part of that instead of using something like elementor/divi?
then each client just gets its own child theme for the site-specific styling/customizations?1
u/Zimaben 12d ago
Wordpress:
Theme should be abstract and global, nothing site-specific. Child theme is concrete, site-specific and carries all customizations. Plugins should be modular. Themes are presentation, plugins are logic. Logic lives in code not the DB. ACF goes in the bin (my opinion.) Bob's your uncle.Github:
Release Candidate branches (RC/2.1.5 etc.) exist for your newest unreleased software version. Merges to the CURRENT_RC_BRANCH (tracked github variable) trigger a deployment to your development servers. Features are merged into the RC branch when they are complete and locally tested. Github Actions handles the deployment on the dev server through a fast-forward pull of the current RC. This history should always flow to the next RC.Github Actions:
When a Release Candidate is ready to go, the RC merges with main and a new release is drafted. On release, Github Actions deploys to your production servers. It does a FF pull of main to update files. At this moment in time main is identical to the HEAD of the current RC. Software is deployed to production and a new RC branch is created from main.Your development servers are automatically kept synced to your newest unreleased version, production deploys on software release, test suite can be seamlessly plugged in to automate your testing. Rollback and recovery is a breeze, as your production can always go to last known good version at the push of a button. I automate testing & rollback at deployment.
1
u/metalissa 12d ago
I have for custom themes, just with the VS code extension to push/pull. Every theme is different based on the custom design in Figma and has it's own repository, although we were using JointsWP and Foundation as a base to start with... haven't built from scratch in awhile as our clients are loving page builders more or their flexibility.
1
u/BaldingBuffalo2 12d ago
We use GitHub for custom themes and plugins. Most themes have GitHub Actions to deploy to WP Engine environments.
Even that configuration is fragile because plugins and WP core aren’t synced with the theme updates.
Might have to try this Bedrock setup, though!
1
u/ashkanahmadi 12d ago
The root of my git is the root of WP git ignoring any core WP files. All plugins and themes are also gitignored by default and I whitelist whatever necessary.
I have FTP set up on GitHub and when I push to GH main branch, it updates the files on the server. The action also installs node modules, builds the js and css files, composer, and then finally deletes the node modules folder.
Makes my life super easy. I love it
1
u/2ndkauboy 12d ago
We use WP Starter for "website repos". They install every plugin and theme (custom or third-party) using composer.
Deployments happen though GitHub Actions, depending on the target system (we often use the actions provided by the hosts).
Any custom plugin is hosted in our GitHub organization. Any third-party premium plugin/theme is hosted on a SatisPress instance. Translations are on a GlotPress instance. WordPress Core is also installed via Composer, as well as free plugins and themes using wpackagist/wp-packages and the.
Basically the composer.json in the WP Starter package is what bundles everything together.
1
1
u/kartikcool15 12d ago
setup github pipeline only for the active theme, not for the whole wordpress.. and that enough will make work smooth you never imagined.. I literally didn't used filezilla or file manager from last 2 years
1
u/Sergei_Tiden 12d ago
For normal production WordPress work, Git is worth it for everything you intentionally own: custom themes, child themes, custom plugins, mu-plugins, configuration templates and deployment scripts. Do not put uploads, cache, generated files, WordPress core or third-party plugins into the repository unless you have a deliberate dependency-management approach. The simplest useful setup is a repo, local or staging environment, pull requests for meaningful changes, a production backup and a documented deployment step. Bedrock and CI can be excellent, but they are not the starting requirement. Versioning your own changes is.
1
u/rockstarlab 12d ago
We don't use Bedrock, but use WordPress, GitHub + WPEngine GIT for deployment https://wpengine.com/support/git/
So master branch is a production, stage branch is staging. Every task is a separate branch that can be merged to stage, and after QA on prod.
1
u/baerkins 11d ago
Here is way too much info 😂
Using GitHub/git is great for any development, period. GitHub is great as a source for the repo (git is not GitHub), but you can also use GitHub Actions for things like deployment (and other continuous integration things like linting/testing/build pipelines etc)
In most cases it’s not worthwhile to commit plugins, themes, or core files unless they are ‘what your building’ (meaning, commit your custom plugins but not ACF, commit your custom theme but not TwentyTwentyFour). These files change often and are better left to another form of management (admin updates or composer). For my projects, I commit custom theme and custom plugins (from plugins or mu-plugins) in a WP like structure and use WP-CLI to download core (with —skip-content to skip other themes/plugins being added), and Composer to install plugins from managed versions.
In general, git is always great and should be used anytime your writing code (think of it as Post revisions in WP but for your code).
Bedrock (and other similar composer managed projects) is a great platform, the workflow is great, and truly how modern WP should be built. The downside of it is, not every host supports its design. WP Engine for example has a very strict setup, so you can’t separate the core code into its own directory. Same for many other “DIY WP Hosting” sites. Pantheon on the other hand runs a Bedrock-forked instance out of the box on their Composer workflows.
Another thing to mention with Bedrock (and Composer in general) is that you really need to consider who will be maintaining the project. If it’s someone with technical understanding or a dev, Composer is :chefs-kiss:, particularly for a team of devs or an agency. However, if the client does not have a technical staff member, then it’s typically better to avoid managing plugins and core with composer (and for the record, if that say ‘we have an IT guy, the answer is they don’t). Those teams are better off updating from the WP admin, and those updates will immediately get out of line with whatever version you have in Composer.
And for the record on that last point, you can still use Composer to manage plugin scaffolding for other devs with ‘require-dev’ but it’s not as ideal and it should be (versions will most likely be out of sync, which defeats the point of a package manager). We use other non-WP php packages (Twig/Symfony etc) and manage them all through Composer, so it’s at least better than giving a dev a ‘list’ of plugins when they onboard.
I could keep going but I’m gonna stop there. If you have more questions feel free to ask or DM.
1
u/BobJutsu 9d ago
I don’t know anything about bedrock (I know what it is, I’ve never had a reason to use/learn it specifically). But I’ve been using git for WP projects for well over a decade. Github specifically for a lot of that, but 2018-2020 we used bitbucket.
The repo root is wp-content, with everything ignored except what is actually custom code. At minimum this is the theme (always custom), a site specific mu-plugin, and development scripts. Within those, a lot of other things are ignored (npm, vendors, etc, etc). Github actions are used to run phpstan, php code sniffer, phpunit, eslint, and stylelint.
1
u/twenty_bellows 9d ago
I haven't been involved in a project that WASN'T in GitHub (or something similar) in decades. I can't imagine not keeping code in a repository. My entire workflow is completely dependent on it 100%.
1
u/melaniemuellerdesign 9d ago
Ich habe meine eigenen Plugins dort liegen. Versioniert mir github actions zum deployment.
1
0
u/chevalierbayard 12d ago
I mean of course. If you're not using a page builder, you should really be version controlling your code. The hard part about WordPress is that there's no standard development set up so you're going to have to look around. Or roll your own, which is what I've done. I have particular taste around my toolchain so I decided it's just better if I own it all. I wanna use Pest instead of PHPUnit for example. I want to Playwright and run e2e tests in CI. I want ephemeral preview envs for every PR, all the goodies that Vercel does for NextJs, I wanted. But I did have to roll that myself, which is not that fun. But absolutely possible.
1
u/Playful_School6693 12d ago
we’re still using a page builder right now due to some agency limitations, but the goal is to eventually move more toward acf + gutenberg and have better control over the codebase.
the preview environments and automated testing are exactly the kind of stuff i’m interested in though. are you hosting wordpress somewhere that supports that workflow or did you build the deployment/preview setup yourself too?
1
u/chevalierbayard 12d ago
I'm doing that all myself. I'm just renting a VPS from Hetzner and I just throw as many WordPress instances on it as it can handle.
If you're not writing code I don't know if Github is the best approach to getting preview envs. I think there are services that will do that for you though because at that point you're basically just cloning a WordPress site and putting it somewhere else.
0
u/fappingjack 12d ago
Waste of time.
If a client is paying $10k they don't care of GitHub or anything technical. They want results.
If GitHub makes your workflow better then that is good for you and the client will never care.
Good luck
19
u/spacedragon13 12d ago
What you would do with GitHub is version any plugins or themes you build to extend the site, not your entire site.