Right - this might sound like a very crazy idea and one that experts will probably laugh at !!! and one @Norm will be able to answer straight away.
When saving a website, the file saves where I want it to be saved on my Mac and then I tend to upload the files to my server and all works nice.
I do back my websites up to the cloud and also on an external drive, but then I got thinking…wouldn’t it be great if on the export settings there would be a check box area saying : ‘Server Back up’ and when uploading the website, it includes backing up the actual Blocs file too - that sits there - possibly compressed and yes this will take extra storage and probably duplicate the whole size of the backup - but I just thought what a great option this would be as an extra layer of back up. Can simply check the box and it saves a zipped/compressed file or the normal file in a way not to effect the operation of the website.
Yes this can be done manually - but I do think at times when I hear people say they think that might have lost their site etc - what a great extra layer this would be as we are going more one click does more.
Just a thought ! - and of course, if you do not want this, simple…do not check the server back.
That is a good idea, RW/Stacks does this (I’m guessing you’ve used this feature in the past?), but it does provide a backup solution, especially with some cloud services being a bit flaky at times with Mac sync. OneDrive great when working, but can sometimes cause me big headaches with suddenly going on demand files etc.
I would add to your idea that improves on the RW/Stacks approach would be to password protect project file, therefore it doesn’t matter if it discovered on the server (although difficult to do but theoretically possible).
I do like the Blocs file format being a self-contained file as opposed to a package file. A packkage file is really open to being corrupted with file sync cloud systems. I learnt this the hard way with another system, the file was sitting on the cloud drive looking all good until I retrieved it and it was corrupted.
Why not just use a version control system (VCS) and get all these benefits and then some? I suspect there’s more designers/front end folks around here than coders/back end folks, so this might be unfamiliar. I’m sure everyone’s heard maybe just in passing about Git and maybe even Subversion (SVN).
Although there’s some initial setup and familiarization involved, once used, you not only will have backups, but also backups of every version including commit notes so that you know what’s changed. Additionally, you can formally tag versions and also branch the “code” when needed. And of course you can check in whatever you like, your Blocs project file, web site exports, or both, as the choice is up to you.
And today there’s a ton of great GUI apps for these systems to make the experience as easy and enjoyable as possible. In the past I believe @Jannis has spoke about Repository Manager potentially being used in this manner.
But there’s good and bad here as well. As the project files are monolithic binaries, it means that from one version to the next you have no idea what’s changed within. For example if you change one thing, such as a script in your header, you can’t see what got changed in any diff tools.
@Norm Maybe I’m the contrarian here, but I actually think it would be awesome to add another format to save in, something plain text so that the “source code” could more finely be controlled. Or maybe I’m missing something and you could share how you manage this dilemma in your own Blocs projects.
Funnily enough, the IT departmant at one of the companies I’ve created a site for have asked if I’ll use this in case I get hit by a bus or something like that as a contingency so they have access to the latest file at all times.
I get what you are saying here, and is very very true for a number of apps, but with RW/Stacks that uses this method has caused no end of grief for many, on the forums for that app there are loads of instances where folk have had corrupted files and no way of recovering other than rebuiding from scratch due to cloud sync and retrieval at a later date. It happened to me some time ago, I figured out after looking in to it, researching, testing, that this was the problem and had to adopt a method of zipping the package file to sync everytime I made major changes to remidy that problem and naming versions of the zips as Project 1 V1, Project 1 V2 etc. I know recently sync apps have got better, but I still wouldn’t leave it to chance. With regard to troubleshooting package files, in RW/Stacks this could be less helpful as RW/Stacks renames files for its own process (which translates in to the end source code generated), for instance just looked in a RW/Stacks package file now and all images are renamed to random file names. An image that should have a nice descriptive title has been renamed to 1C6E98F1-743A-4BF0-BF12-D1448A76111C.jpg this appears in the package file and the end source code generated. Admittedly though Blocs doesn’t do this and keeps the integrity of the filename in the source code, nice-named-image.jpg remains to be titled nice-named-image.jpg. Therefore the troubleshooting as you say may be relevant to Blocs, thought I’d add some context though as to whay I have a phobia of package files
It’s actually a pretty common business practice in tech circles, sort of like stopping at stop signs when driving.
I don’t have any recent experience with RW but this doesn’t sound like fun.
But to be clear, I’m not advocating for a package based format nor to replace the existing binary form. I’m requesting that a new text based format be created, in addition to the existing binary one, for use with VCS. I’m purposing leaving the implementation vague here as Norm will know what’s best for him, but realistically this would be a big JSON file or maybe even XML.
But who knows, maybe the binary format is done strategically for lock in purposes similar to what Microsoft did with Office in the early days.
I use a slightly different approach. Perhaps this suggestion will help some of you.
MAMP Pro is installed locally. After changes or regularly, the “vhosts” folder or only individual domains are synced to a suitable local directory via rsync. Mamp is configured appropriately and uses this directory depending on the host.
After the sync, the local website is the same as the live website. The Mysql data is copied to the MAMP “db” folder. These are therefore available locally 1 to 1.
However, this is also the pitfall, MySQL/PHP from MAMP and live system (possibly MariaDB) must match. Depending on the hosting package, there is not much you can adjust and the dB part does not work or only with manual intervention. The MAMP paths then only differ in the attached port (8888). This must be adjusted.
With new MAMP versions, you must always check the versions of the components.
With rsync and zip, download and backup can be handled well in scripts.
I have had very good experience with this for years and it is also ideal for testing.
Disadvantage: it does not work out of the box, you have to deal with it and know a little about mysql, mariadb and php. You also need the right rights on the server. It also only runs under macOS, but Blocs is also mac-only.
