Sage 9 FTP - Updating existing project?

[da-kicks-87]

Hello I have successfully deployed my Sage project to my server using FTP ( I don’t have access to composer on my sever). I used the guide https://roots.io/docs/sage/9.x/deployment/#deploying-sage-via-ftp

Now brings the question, when sending new updates to an existing project on server with FTP what should be done?
Example: I made sass / css changes that i want to go live

I noticed after compiling assets, the main.css in /dist gets numbers add to the file name: main_96a99de4.css
Which is different number that is current on the server. So would i have to manually delete the old file since new file wont overwrite it?

Would I have to upload package.json and composer.json files to reflect the changes? Is there something else I am missing here?

[strarsis]

The file names are hashed as a cache busting mechanism. This ensures that the new stylesheet is downloaded and used by the browser, even when heavy caching is used.

Are you sure you only got FTP and nothing else? Is it at least encrypted FTP?

Ideally you would have an automated deploy, that means you are just issuing the deploy command and all relevant files should be uploaded to server (via FTP, as you got no other option here).
The moment where the new manifest is uploaded, the new filenames will be used by the theme.
So depending on the complexity you could try to upload a new theme release and then quickly switch to it (e.g. by renaming or symlinking to it (if this is supportend by the webspace)).

[da-kicks-87]

@strarsis

re you only got FTP and n

I have Shared Hosting Plan server which doesn’t give root access. So the auto deployment apps won’t work.

What I did to upload my changes were, running the commands yarn build:production and composer install --no-dev, then upload only files that I changed and the entire dist folder. The assets.json in there is making reference to the new cache busting #.
I loaded my live website and the changes were live.

The old CSS and JS files were still on my server. I had to delete them manually.

[knowler]

I made a script for this sort of thing a few years ago. I imagine it still works. The README explains the usage.

knowler/sage-prep

[strarsis]

Nice, I wrote scripts (Sage 9 + Sage 10) for a similar scope some months ago:

Deployment on Shared Hosting

IMHO it could be quite helpful to add an “eject” task to Sage that automatically creates a minimal theme ZIP as build artifact. Note: node_modules/ is only required for building the theme - it is not needed and should not be needed by the theme during runtime. If there are any files that should be available for the theme, either add them using webpack (e.g. imported SASS, url(...)) or copy them from node_modules/ into dist/ or - for some cases - resources/. For Sage 10 themes: #!/bin/sh echo …

[da-kicks-87]

Thanks for the ideas. But sorry guys, but how do these methods solve the hashed numbers of the css and js files? It makes more sense for me to upload the files that I have changed and not an entire theme folder.

[strarsis]

rsync doesn’t work over FTP:

How to use rsync over FTP

It makes sense though to optimize the transfer at each deploy (when you must use FTP).
There are tools that can sync over FTP:

How to automatically sync the contents of a local folder with the contents of a ftp folder?

This approach is simple but can lead to a small window of downtime during the deploy as live files are changed on the fly.

[knowler]

But sorry guys, but how do these methods solve the hashed numbers of the css and js files?

Sorry, I totally missed that in your original post. When Sage 9 builds the frontend assets, it generates an assets manifest file which maps the files to the cache-busted version of the files to determine what CSS and JS files to load (see dist/assets.json). So whenever you need to update your frontend assets you need to make sure to at least upload the entire dist directory (technically, you could be selective, but then you’re manually checking the hashes. It might make sense to be selective if you have a ton of images though.).

In the past, I just found uploading the entire theme directory to be more foolproof as I knew it all worked together, while uploading individual files was problematic because if I forgot to upload a single file the whole thing could break (turns out humans are highly susceptible to failure).

[da-kicks-87]

@knowler Yes I see what you mean, uploading the entire theme dir would be more fool proof. But only in the case where many files were changed.

In the method I used i would have to delete to old hashed css and js files after uploading the new ones. This could become tedious when I have a lot of files. Any better ideas here?

About the assets,json file if it doesn’t find the hashed # does it use the old hashed # that is in the dist? It looks like it does.

Example my brand logo .svg in the live dist folder is hased 73eadee2. My assets,json has a new generation, so the hased # it is referencing for all items is 96a99de4. The logo load fine on the live website with the old hashed # .