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?
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)).
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.
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.
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).
@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 # .