With a static site generator, how do you update the live website without having to upload the whole public_html file again?

[built]

@turbin3 @SmokeTree
----
If you use a static site generator, how do you update the live website version without having to upload the whole public_html file again?

So say I make a new post about something, it creates the file and stores the assets. How do I just upload that post?

 

[turbin3]

Version control systems, such as "Git", help with this a LOT. I'll use Git for an example, as it's pretty easy once you wrap your mind around installing/setting it up, and then the basic commands. I'm no git wizard, though, so I'm sure someone like @SmokeTree will have better recommendations.

Usually, the basic strategy of these versioning systems is, you first create one for a project.

git init

Then add your project files to it.

git add .

You might periodically want to check this local repository, and see a list of what you've actually changed.

git status

Then, when you make significant changes to anything within the project, you make some sort of "statement" to record those changes.

git commit -m "I made these changes"

Lastly, say you're done with your changes, added your new content, you've made your "commits" to update your local repo. Now it's time to update your remote repository, wherever it may be (a remote server, CDN, S3, etc.).

git push origin master

The stuff that's changed gets pushed over to your "master" repository. To be safe, you can even do stuff like pull from your remote repo (git pull, though you have to create a repo there too), if you want to be absolutely sure your local repo matches what's on your live site.

That was a simple explanation, and there's a LOT in between. Things like different flags and different ways to use those commands for other purposes. The cool thing with version control is, some of these additional commands let you do things like quickly make duplicate "copies" of your repo (they're called "branches"), or even just components from your repo. All of them can be versioned. The idea here is, you work on things, you're logging those changes, and if at any point you have a problem, there are ways you can easily revert to previous versions.

On top of this, certain platforms have their own command line programs you can install, some of which are even a bit similar to this workflow. Amazon has their AWS CLI, for example. With it, there are commands to sync between your local repo and remote one, and only push the modified/new stuff, or remove files from the remote repo that you've removed locally.

 

[built]

Thanks for the reply @turbin3 will check out some YouTube tutorials on Git as well.

 

[SmokeTree]

I'm no git wizard, though, so I'm sure someone like @SmokeTree will have better recommendations.

Maybe not better, but what I've been doing lately is storing the code to generate the site itself in git (I have the /public directory in the .gitignore to prevent checking in generated files) and using rsync to deploy.

I've been working with Hugo (https://gohugo.io/) quite a bit lately and it has proven to me to be the best static site generator for my workflow and needs. I really like frameworks that can give me something very barebones to start with and Hugo fits the bill here.

For deployment of a static site, the method I've used lately with good success is by using rsync (https://rsync.samba.org/). Here's a basic tutorial but it seems to be missing file permission related things on the server side: https://gohugo.io/hosting-and-deployment/deployment-with-rsync/. Here's how I'm doing this with a VPS and Nginx on the server. Let's assume arguendo that the folder on the server that we are deploying to is /var/www/my_site and right now there's nothing in it. We also have an entry in the ssh config on the client-side that will allow us to SSH to a server we're calling "my-server" with the user "my_user". You'd do something like this to set this up:

On the Server

Change owner to "my_user" and group to "www-data"

sudo chown my_user:www-data /var/www/my_site

Change permissions of directory

sudo chmod 775 /var/www/my_site

Do a "setgid" on the directory so that any folders created inside will inherit the "www-data" group

sudo chmod g+s /var/www/my_site

On your machine (client side)

Now to deploy all you have to do on your local machine is run the "hugo" command to build your site and then run the following command to deploy/sync. Hugo builds the site to a directory called "/path/to/my_site/public":

rsync -rvz --chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r --delete /path/to/my_site/public my-server:/path/to/remote/folder

What the command above does is it will sync only the files on the server that's changed recursively (drill down to subdirectories) while enabling compression during transfer and deleting anything on the server folder that doesn't exist on the client-side. The "--chmod" bit will set the permission of all files to 644 and all directories to 755 respectively. The first time you run the command, all files will be copied over to the server. From then on, only the files/folders that have changed will be copied over. You can wrap up the commands to build the site, deploy and rsync up in a shell script, then you'll be able to build/deploy your site in a single command faster than most people can open an SFTP program.

Hope this helps. There are tons of other ways to deploy a static site and this is just one example. If you want to try this route and run into any snags, just PM me and we can chat about this on Skype if you like.