[ad_1]
Im running into major issues with having CI/CD with WordPress and now im just starting to have wordpress. I just want to be able to push my theme changes an have the site rebuild but there will always be downtime as I cant put the entire wordpress in my repo since the dashboard can create files eg. uploads. So….does anyone here work for a company where you dont have CI/CD wiith your wordpress site and the business runs fine?
[ad_2]
I have never used CI/CD in that manner with WordPress. Use a private repo for the theme, and use a script that checks for theme updates. If they exist update the theme from dashboard like you would with anything else wordpress.
There are full blown web agencies working with Elementor and almost never touching code, they charge $20k for websites.
You’re fine with whatever method works for you. You don’t have to make it difficult.
Use Composer-managed WordPress (ie: Bedrock) and then the only thing that’s in the repo is your custom code. Find a hosting service that supports CI/CD properly like Platform.sh or Pantheon.
> Is having a production WordPress site without CI/CD considered unprofessional?
No
I’ve been a wordpress developer for nearly 20 years, I didn’t even know what CI/CD was and had to google it.
We use CI/CD but only for theme and plugins. The deployment builds the theme and pushes to a temp directory. Then, the script renames wp-content/themes to themes.old and moves the themes directory from the temp location to /wp-content.
Our Plugins repos contain all plugins for the site, and those get deployed in a similar way. Deployed to a temp location on the server, current plugins folder renamed to plugins.old, and new plugins folder moved into place.
Downtime is only as long as it takes to move a directory, which is nearly instantaneous.
We keep all plugins in the repo because we have too many pro plugins that are a pain to manage with composer dependencies.
In WordPress?? There’s no way I’d do that. We have many sites and none of them do that. Constant snapshots and cloud backups that roll back if really necessary is all we use.
No, it adds an unnecessary amount of overhead for almost zero benefit.
If you’re building apps or working with multiple developers (are you?) and using backlog items to tracks stories and pr’s, then maybe. Otherwise, avoid the headache.
It depends, we auto deploy to many sites and it speeds things up for us as well as runs a bunch of tests which helps us. But only do it if it saves you time or makes it better for you.
Most WordPress devs don’t have any CI/CD in place. You need to understand that WordPress is one of the most popular CMSes in the world, only a small percentage actually dig deep in the code level, that too is at a very basic to very high level.
For eg. There’s a plugin that will sync your theme with git, cause some don’t know how to even set up git by themselves.
So for your repo woes: you could have just your theme be the repo. Or just your theme and the WordPress core & plugins. Generally speaking the uploads and any generated files or files WordPress can create should be ignored in the repo.
I wouldn’t expect there to be any downtime pushing code changes. You have any build processes (js script transpiling/minifying, etc) happen on the pipeline runner itself.
I found having the CI/CD pipelines in place made my life as the developer much easier. (It was definitely better than like FTPing in and replacing files that way, or trying to use some backup plugin)
Locally, I’d have a dev environment like VVV that would pull any images from the live site (that way I could avoid having to pull down the live uploads folder and staying in sync with it)
And every few days or so, or when I started a new feature/story I’d pull down a database dump so my local had the latest db.
Additionally, things like updating plugins and the WP core were disabled on the live site. These tasks would be done locally and then pushed up to the repo. (Which would then kick off a deploy to the live site) and exception to this would be sites hosted on like WPEngine. On those sites the plug-in updates and core updates can happen, and then WPEngine would commit them to git.
Never used it and don’t intend to start. I develop locally then take a snapshot of the entire site with a backup plugin. Upload the backup to the clients server and using the same plugin simply import it. Done.
No its not considered unprofessional as this is the beauty of wordpress.. however we use CI/CD with full custom theme or plugins. Also with professional environments that use bedrock https://roots.io/bedrock/
I prefer a ci/cd pipeline on my bigger accounts. I have dev/staging/production servers for my sites… I push theme to dev branch, it uploads the theme files to dev server. I merge those changes into staging branch, then it automatically pushes to staging server… I test in staging, when everything looks good, I merge into main branch and it uploads to prod server. It uses ssh for uploading files and only targets the theme’s directory on the WP server(s).
Not necessary by any means, but I just prefer it this way. I guess it really depends on what files your dashboard creates and whether or not they are necessary for theme-specific changes or not. If it’s specific to the theme, I wouldn’t keep them in the /uploads/ dir personally.
We do not implement any ci/cd except for in massive sites. To be fair, we do have a pipeline, but unless the site is under some type of active development it has no staging counterpart. Just daily backups, and an update schedule. There’s no build step, so no pipeline is necessary. Our repos don’t contain any 3rd party code, so updates to anything other than our custom bits and pieces (theme, a mu-plugin on each site, and any custom plugins specific to that site) don’t pollute our git history anyway.
Your CI/CD should be a pipeline which run an `npm run build` after rsync files… but running CI/CD on a WP mainly helps you spare time. WP customers don’t care about it, usually. They could be more interested in backups.
Wow, reading all those comments saying “you don’t need it” or “adds unnecessary work” clearly have not learned yet, why and how it can be useful. Like integrating e2e testing in the pipeline. Or atomic deployment with no downtime. Or metric ton of other reasons to use it…
If what you do is not really “development”, but just using plugins for everything and maybe doing a tiny bit of CSS, then yes you don’t need it. If you actually develop stuff that is a bit more complex and have projects that last longer than 2-3 months – then yes, it will save you loads of work and headaches.
Plus once you actually learn it it’s repetitive and doesn’t take much work to set up.
The biggest issue of wordpress is ton of “developers” who think that basic theme customization and a couple of scripts in functions.php is real coding 🙂
Not to mention being able to move to new vps server with launching one script, which installs everything on server, copies files, databases and the only think you have to do manually is changing server ip in cloudflare. Plus allows to easily create staging sites with docker, which mimic every little detail of production server.
I just put the wp-content (plugins and themes only) folder in GIT for tracking. Push the custom themes and plugins manually via zip files unless the client is on WordPress VIP where it becomes somewhat mandatory to use pipelines