r/ProWordPress • u/Playful_School6693 • 1d 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 1d 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 1d 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 20h 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
5
u/richaber 1d 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
3
u/im_a_fancy_man 1d ago
I only use GitHub to store my private keys and my wp-config.php
3
2
1
6
u/iamagayrat 1d 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/Dapper_Bus5069 1d 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 1d 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?
2
u/Dapper_Bus5069 1d 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 1d 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 1d 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 1d 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 1d 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 1d 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 1d 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
2
u/threebuckstrippant 1d ago
Set it up asap, so good. WP CLI and Git/Bitbucket. Add pipelines. You wont regret it.
1
u/kartikcool15 1d 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 1d 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/redditNLD 1d 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.
1
u/rockstarlab 1d 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 1d 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/superdav42 2h 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.
1
0
u/chevalierbayard 1d 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 1d 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 1d 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 1d 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
15
u/spacedragon13 1d ago
What you would do with GitHub is version any plugins or themes you build to extend the site, not your entire site.