Support

Don't worry for posting here on a weekend. We only have that notice up because we don't reply on weekends and we don't want to give the wrong impression that we don't care about your tickets. We just need some rest to let us work our regular 10 to 12 hour days on weekdays ;)

I see that Ticket 26854 was mostly focusing on how to get that site transferred. You were not given the reason of why the Site Transfer Wizard (I'll abbreviate it as STW from now on) didn't work for you.

STW is designed to transfer a site to a new location or server. In order to do that it expects that the target location is completely empty of anything that looks like another site. This is done for two reasons. First and foremost, the most common mistake people make when transferring a site is that they inadvertently transfer it on top of another, existing site they didn't mean to delete / replace. Of course this results to a total disaster which cannot be reverted (unless they had a backup). Even though this is 100% the user's fault we were getting all the blame and a bad reputation so we took measures for this not to happen.

The other reason is that depending on what you already have there you might get conflicts. For example, if you try to restore Joomla! 3.6 on top of Joomla! 2.5 (surprisingly not uncommon) you'll end up with a botched site that doesn't work. That's down to how Joomla! itself works. Furthermore, some .htaccess or php.ini / .user.ini settings could cause the helper script being uploaded to the site to facilitate the process malfunction, leading to a failure. So, again, if we detect an existing site we won't let you proceed.

Unless, of course, you click the Big Scary Red Button which tells Akeeba Backup that you really know what you are doing and you really want to transfer a site on top of an existing one (in which case if it breaks you get to keep both pieces without complaining). In your case you can totally use that since you're overwriting a slightly older version of the site with a new one.

Now that we clarified this, let's go to your specific questions.

After changing the name of kickstart.php (not mentioned in the video but required)

Only if you are using Akeeba Kickstart Professional which is only required if you want to transfer files from Amazon S3. In all other cases you can simply use Akeeba Kickstart Core which does not require renaming anything. That's why renaming is not mentioned in the video.

instead of doing what the video said and going to Pre-installation check, went straight to "Congratulations! Joomla! is now installed" screen.

This cannot happen because, quite simply put, there is no such page in ANGIE. What seems to be going on here is that you have a caching proxy or CDN in front of your site. You will need to disable it while restoring or, more correctly, flush it THREE times: before restoring, right after the extraction is complete (before you run the installer) and after the installer tells you that it's done. Otherwise you are going to see cached, static versions of the pages and the installer never runs. Of course if that happens you end up with an unconfigured site so everything else you say makes perfect sense: you never run the installer.

FWIW your local site (XAMPP) won't have this kind of cache in front of it. Try restoring there to see what I mean.

Finally, some browsers (Chrome, Opera, Safari) tend to cache redirections. This can get in your way. Before starting a restoration or a site transfer you should completely quit the browser (close all Windows and, if you have a macOS computer, use CMD-Q to completely exit the browser application). This tells the browser to "forget" redirections. I know it's VERY annoying but there is no way to control this! Chrome started doing this since version 4 (and now it's in version 57). Possibly the only thing you can do is use Firefox Developer Edition which disables all sorts of consumer-grade "helpers" which simply get into the way of web professionals like you and I.

So far I have been unable to find any way of developing a joomla site offline and then uploading updates to the live site. All I can do is to dev on the offline dev PC, write down everything I do, get it looking nice with the right content and then repeat the whole thing manually on the Live site.

Many have tried to create a real dev - staging - live solution for Joomla! but, frankly, this is just not possible unless you are only interested in very basic things. The whole problem is that everything is interconnected in Joomla! through the ACL and UCM systems. Adding an article on the live site has a direct impact on transferring the permissions of modules and extensions from the staging site. If you want to have a dev - staging - live workflow you have to be very religious on NOT making any changes in the live site. Which is kinda dumb on most sites since you want users to make changes. For example, if you don't use a cache and you rely on the hit counter then you expect that the articles will get updated (with the new hit counter) every time they are viewed. The dev - staging - live ends up having a limited potential.

Not that it's useless. We do use it on our own site, but in moderation. We use partial backups whenever we change something substantial on the site, e.g. when we completely overhauled the Support section which involved changing menus, adding modules, installing and updating extensions and changing content. The key to this process was that anything added to the live site was (manually) added back to the dev site to prevent the content and permissions from getting out of sync. This let us refactor the entire Support section, essentially restructuring the site, with a grand total of 1 minute 40 seconds of downtime (and a week of full time intense testing to minimize that time and any potential impact it might have had on our site).

When we need to add a new news articles we start by publishing an article with its Access set to Special so only us can see it, in the frontend of the site, in context with the rest of the page. Once it's formatted as we want we switch the Access to Public. This doesn't work on my blog where publishing an article in a specific Category results in Tweets and Facebook posts. So there I have to use a category with its access set to Special to format my article, then copy paste it into a new article in the correct Category. Even though it sounds inconvenient, it's actually more efficient in my use case. Remember, when I publish a blog item I want to send out tweets (with Open Graph content) and Facebook posts (with Instant Article content) and the only way to do that is if these items originate from my live domain. Doing a staging to live transfer would require inventing some complicated way to send the social media posts which becomes too convoluted too fast.

So I can see where you come from, but there is a quantum leap between static HTML (Dreamweaver) and dynamic content managed by a CMS (Joomla!). If you only ever use Joomla! as a glorified DreamWeaver you are using the wrong tool for the task. Perhaps you want a flat file, database-free CMS like Grav instead, something that combines the fine-grained control of static content with a modicum of CMS amenities like navigation generation and templating. Of course these flat file CMS stop being of any use as soon as you want real interactive features, from self-hosted comments to e-commerce. But, hey, being a professional is all about choosing the right tool for the task at hand, not trying to shoehorn the task to your tools or vice versa ;)

(sorry for the accidental blank message you received; my cat thought it be funny to step on the ENTER key before I could close the tab...)

Both local PCs (and Live) are on Joomla 3.6.5. So to get the site on dev1 onto dev2 would it be best to install AKB onto dev2 and then use that to restore a full backup from dev1.

No. You do not need Akeeba Backup to restore a backup. The backups include everything you need: the site's files, the site's database and the restoration script. Therefore you'd need to install Akeeba Backup on dev1 and use Site Transfer Wizard to transfer it to dev2 (FROM dev 1 TO dev 2).

Or I can remove the joomla files from c:/xampp/vhosts/site/htdocs and then use STW manual to install using kickstart / backup to install the site/joomla afresh in the new location.

Yes, that's what I described above :)

I'm not going to attempt to do anything on Live until I manage to get one site moved from dev1 to dev2. Then in future, I will dev on dev2 and when ready, use kickstart to upload to an "empty" live site (having setup a database / user there to connect to).

Technically you can restore on top of slightly older version of the same site as long as the Joomla! version is the same and there have been no extensions added / removed / updated. This makes sure that you don't have leftover files which could cause undesirable and unpredictable effects. So, yeah, restoring on top of an empty site is the best way to ensure you won't have a problem!

You're welcome!

PS: Simba says meow to Sibyl ;)