Working within a high activity Website Development Cycle

1. You have a client who wants to have changes implemented and visible immediately.
2. You have made some important changes but they are taking a long time to propagate.
3. Several end-users still cannot see the recent changes you've made.
4. You want to document changes you have made for your own sanity.
5. You want to add version control into your design.
6. ...

This approach does all of the above with the addition of a small control page into your design.

Attachment 134028

You could immediately augment any design file by copying and pasting the first page in the attached above.
Simply change the first page > Page filename to v100, Save and Export Website to a local folder.

If you now go to this folder, you will see two things different to your normal delivery:

• An additional file, v100.htm
• A v100_htm_files folder (instead of an index_htm_files folder).

If published, the URL to index.htm would show your website as designed.
The hidden difference is Xara has relinked all assets to the new folder.

When you make any design changes and want to publish or export them, the only extra necessary step is to up-version (increment) the Page filename of this first page.
So v100 becomes v101 and on Export you will have an new v101.htm page and a new v101_htm_files folder.
Each iteration creates a new set.
At the same time your website index and other pages will have been updated.

As effectively everything has changes, you no longer have a Xara incremental upload so do not Publish this way if your asset files sizes are overlarge.
Export Website instead and then use an FTP Client, with a few simple setting changes: only overwrite if different.
But, crucially clone the vnnn_htm_files folder on the server and rename that new folder to vnnn+1_htm_files (the version of your first design page).
Then incrementally update your local folder vnnn+1_htm_files into the server one.
So far, there is no down time for end-users.
The last step is to upload all the htm files and others at your top level.
As these are usually around a payload of a megabyte, the changeover time is near instant.
A user on old version jumps to a different HTM page and they will be served the updated page (fully connected to the new, updated assets) with no indication of a switch.
Clearly a Back button click will present a page that is in browser cache but any new session or fresh link will set all views to the new pages.

Not tested but feasible. If you publish and click on the Version Link on my index page, it will go you what it thinks is the latest version control page and that should immediately jump to the latest index page, clearing the browser cache.

To assure roll-back, the ability to go back to a prior version, you need to save the design file with a filename that names the version.
You simply Export Website and just upload the top-level files; its version assets are already there.

In the Main control file page, you can add any detail you want around what you have changes. As it is off-page, it never publishes and never become a slowdown other that a local Save.

---

How it Works

• The control page has a small JavaScript jump Page head.
  
  • The the page is accessed, this immediately jumps to the index page.
  
  
• If JavaScript is disabled, then the second code line kicks in after a third of a second.
  
  • The JS code does not affect the browser Back button; this one does so that is why if is delayed and used as a fall-back.
  
  
• The final fall-back is a Link on the control page that when clicked goes to the index page.
  
  • Clearly, this should never happen but there is always a one in a million chance, and, as Terry Pratchett might have said, 'One in a million chances happen around 50:50.'

---

If it all goes to rats for you, just delete the control file and republish.

For housekeeping, after extensive user testing and acceptance, delete all but the last asset folder.
Then delete the control file and republish.
The server will still have a v1nn_htm_files folder and an index_htm_files folder with the HTM files pointing to the latter.
For new work, add the control file back and change its Page filename to v200 and Export Website as described. You are now back in a development cycle.

---

No promises but I will try and look at any issues that approach may cause.

The cycle is:

• Add a control file (copy v100).
• Make changes.
• Increment the control file Page filename.
• Save the design with a filename that had a linkage to the version of the control file.
• Export Website locally.
• Incrementally Publish.

Acorn

---

Attachment 134029

To make it simpler to use this method, just drop this XAR file onto your design and then move to first page position.

Attachment 134030

You can add a Link to page: Previous Page in your index design page while you are developing.

Acorn

I feel dizzy and need to sit down. Wait. I am already sitting down. :O

The point of this is those who make frequent changes and publish and they, their clients or punters don't see the changes as caching is taking place in Preview, their browser or from served content. It's a simple mechanism with larger application.

In essence if you publish content to a new folder, it hasn't been cached.

Acorn

Is this only a xara issue or wordpress and others suffer from it?

Quote:

---

Originally Posted by behzad

Is this only a xara issue or wordpress and others suffer from it?

---

It impacts many static sites as well as WordPress: https://www.wpbeginner.com/wp-tutori...ng-right-away/.
WP is different as it is a CMS and designed to handle Post changes but site pages are still static and will also suffer. Xara Cloud doesn't, for instance. Nor do document management systems (Documentum) or RDBMSs (Oracle), but these are expensive. Any CMS with PHP generating HTML dynamically won't either but a CMS has other overheads (complexity, security, technical debt, ...).

Any delivery system is dependent on the application, the service provider and its application rendering and promulgation through hub servers (c.f., Cloudflare).
Some TGers do not have any control over their SP (e.g., through Magix) and most users do not know how to purge the browser cache on their smartphone or tablet.
It was most apparent with Xara in the past as it generated lots of images and font changes, all which are usually cached at the server as they ought not change that frequently.
The Plus versions offset this with SVG covering simple shapes (rather than NavBar images all over every page in their hordes; sadly, it still happens).
You normally don't see all this in Preview (it can still happen) as Xara has set all caching off through its in-built server.

My proposal bypasses most of these issues and leaves control with the website developer. It is around 6kB but could be edited down to under 256 bytes and still work.
Say Xara did all that under the hood as well as the housekeeping and didn't tell you. All you would do is add a version number.
Now that would be nice.

Acorn

P.S. If you know Cloudflare (or other) has a cache refresh delay of 4 hours you might just change the v100 Page filename to alternating values (SiteA, SiteB) if you republished daily. Never tried so who knows.

Thanks Acorn. You’re a marvel and eons ahead of some of us. I really wish I had continued my coding classes. I’m going to make a strong cup of coffee and chase it with a Red Bull. ;).
My mental solution of multiple users and changes was the cloud based Xara. Come to think of it, why doesn’t the cloud solve some of this user problem by offering many more features that Xara Pro has. I’m not saying your idea isn’t genius.

Cloud offers the templates etc, but is elementary with the drawing and web features of Pro+. I’m not handy enough to work through your idea, but in my estimation your top 5 items should be solved in the Cloud module. No? Good discussion.