So after using Kirby for a while, I’ve ran into a problem that happened to me multiple times. Content I’ve adjusted on production got overwritten by deploying updates from my local environment. Somehow my gitignore file doesn’t always do it’s job.
What is the best way to keep my local and production content and media files separated?
The problem with the gitignore has probably something to do with us changing it a lot. We’re working in a team where we sometimes do want to push the content to our git so other co-workers will work with the same content. However, we do not want those changes to affect the production
I use rSync and Git together for this to pull content down from production that clients have created / updated into my local git repo and from there i can manage conflicts / merge it before pushing back up to live when i’ve done my job. I treat the production server content folder as golden, and consider my local copy as always out of date.
I dont deploy with git, i do it all with rSync which allows you to do a dry run. It shows you what will be changed on the production server without actually doing it.
How that will work out in a team, i dont know but its an idea.
No worries. the nice thing is that you can set it up in a bash script and trigger from the npm scripts section in package.json. That way you can just type something yarn deploy:live rather then having to remember the epicly long rSync command.
If you are using AWS, you may interest the Elastic File System (EFS) which will allow you to mount the content folder easily.
For now we use rsync too, Kirby is a File based CMS, so EFS could get a little latency due it is a external network resource. To avoid that you will need a instace optimizada for network things.
The bad thing with rsync is that you shoud use the correct arguments, because you could lost “metadata” as date modified timestamp on files, it causing re-create the thumbnails again if is the case. For image CDNs it could ingrease your bill.
It seems that @jimbobrjames is a master on rsync, I will follow its work .
(Adding a comment here because you land on this topic when googling for relevant keywords)
I had a similar problem recently. Even though the /content folder was in my .gitignore file, it overwrote the content on the live server.
For files or folders that were previously tracked, the ignore rule gets ignored. You’ll have to remove the folder from the tracked files by using something like git rm --cached -r content first. Not before creating a backup of course. Then upload the folder manually and it will not be overwritten anymore.
I learned this from an answer on Stack Overflow. It’s only one possible reason, but maybe it helps somebody.