Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
Comments on What are best practices for keeping my blog in version control repository (Wordpress in a git repo)?
Parent
What are best practices for keeping my blog in version control repository (Wordpress in a git repo)?
What are best practices for keeping my blog in version control?
In particular, I hear that many people use git to version control a Wordpress blog. (a) (b) (c) (d) (e) (f) (g) (h) (i) (j)
That way if something gets deleted or mangled on the public blog (usually the authorized user, me, making a silly accidental mistake, but potentially some computer cracker trying to push malware to the readers of my blog), it can be easily reverted. Ideally, if the production blog server is destroyed, it should be quick and easy to spin up a new server that is indistinguishable from the pre-destruction old blog server to the typical blog reader.
But a Wordpress blog has a bunch of pieces:
- a SQL database (containing the text I post to the blog)
- a folder containing photos and media I post to the blog
- folders containing the base WordPress software, themes, plugins, etc. that generally I don't expect to ever manually edit, and so in principle I don't need to save because I can simply re-download from upstream, but will change every time there's an update.
- the
wp-config.phpthat (by default) contains the password to the SQL database (and so should not be published in a publicgitlabrepository).
How many git repositories should I store those pieces in?:
- Should I somehow store the entire website -- blog and SQL database -- in one big monorepo?
- Should I have separate git repos, so that every piece is in some repository or another?
- Should I version-control only things I edit (blog-unique content), and somehow have some tool automatically pull/install/update themes, plugins, etc. available elsewhere?
VersionPress sounds very promising for maintaining a Wordpress blog in a git repository, but as of 2024, VersionPress was still alpha -- not ready for public use. (z)
What's the best practice for posting to a version-controlled Wordpress blog:
- Use the WordPress web editor on the production website server and then somehow pull those changes to a git repo?
- Use the WordPress web editor on some isolated local machine or development server or staging website, and then commit those changes to a git repo and then push to the production server?
- Directly edit the files in the
gitlabrepo (using thegitlabweb text editor), and then "pull" those changes into the production website server?
For a (non-WordPress) simple static website, the answers to those questions seem much simpler:
- Since
.htmlfiles correspond 1:1 with reader-visible web pages, all those files can be downloaded directly from the website, so there's no secrets -- I might as well stick every.htmlfile for the entire simple static website in a big publicgitlabmonorepo. - I can use
gitin the normal way to allow changes to those files in all 3 locations -- on the simple static website, in thegitlabrepo (using thegitlabweb text editor), and on a local machine with my favorite text editor -- and then push/pull/merge those changes until all 3 locations are back in sync.
Post
My blog uses Jekyll to generate a static website, so that I don't need to fuss with server software (except for when I do need a server...), so you might need to tweak certain parts of this scheme, but I do keep everything under version control. In my case, it's as much because I release under a Creative Commons license and want to make it as easy as possible for people to reuse posts, but the principle should hold up.
After some early experimentation, I landed on using three repositories.
Code
The least-interesting repository contains whatever a person (like future-me, in the event of a crash) would need to get the blog running again. All my scripts, plugins, styling, and configuration go in there, exactly as I run it on my local machine.
Media
I have a folder with all the assets, mostly images, a few audio clips, some fonts, and maybe a few other items. They're all sized to fit my layout, so they're technically all distinct from their sources, but I could probably get by without it, since every post indicates where I got the media that it uses.
Also, of the three repositories, this feels like it gets the fewest benefits for using git. The upside is mostly that I can quickly host it all somewhere like GitHub or GitLab for other people to get at, but any backup scheme would've worked just as well. Depending on the media, git might even be a bad idea, since it requires extensions to handle larger files with any agility.
Posts
This is the real meat of the project, since I can import the files into another blog or other app. It's also where you'll probably need to take an extra step to get something out of WordPress that version control can manage.
Searching around, I found a guide to WordPress's export feature, Tools/Export, which should give you an XML file that (I would hope) you can usefully see changes from version to version and import into the same or a different WordPress installation. The former is nice, because it lets you quickly see what changed in a post when (and a bad export will reorder things constantly to hide that), and the latter is what you're after, where you either need to restore broken posts or wipe the entire site and start with a known-working version of the software.
The export won't include the media, but will include pointers to where it will expect WordPress to find the media when restored. Regardless, the export saves you from needing to mess around directly with the database. I gather that tools also exist that will convert that XML to formats that other blogging software can use, if you ever want to replace WordPress in the future.
Why Separate
While I can see the argument for keeping everything together - especially in Jekyll, where the assets and posts will go right into the code's folder anyway - I decided to go with the three repositories for a couple of reasons.
- They feel like different kinds of thing, to me.
- If I want to change blogging engines, I don't want to haul everything down and then scrape away all the Jekyll parts.
- Likewise, if somebody wants a blog that works like mine, they shouldn't need to take the step of ditching my posts.
- The three pieces have different update rates. I commit changes to the media assets weekly. Posts get automatically committed when a new post goes out. And code gets committed...whenever I get around to working on it.
- In my case, they have different licensing requirements. The code derives from Jekyll's, so needs to respect their contribution, but my posts have their own license, and each piece of media has a separate license (which I handle in a fairly shoddy way, but that's another story).
I call out my reasoning, because your view of your system could easily differ enough that you'll want a different scheme. But separate repositories for code, posts, and media should work for most people, if no clearer solution presents itself. Though again, I question the wisdom of actually using version control for the assets, when you probably don't care about their evolution or going back to the media that you had in place three months ago.
In the spirit of your thinking about saving HTML files, by the way, I should also mention that, every month, I run a script that uses my site-map to have the Internet Archive slurp down my site, so that a last-ditch backup exists there.
1 comment thread