File timestamps

[Tim Frost]

Having finally managed to switch to 7.20 and a v3 responsive skin (which all looks great), I was disappointed to find that after each build the output HTML and JS timestamps all get set to the current time, even when the contents have not changed. This makes it impossible to see at a glance which files need to be uploaded to our website after minor changes. Is this intentional or have I missed a configuration setting somewhere? I am used to displaying both local and website folders in Beyond Compare and just uploading the necessary couple of dozen files after most builds.

Of course I could write a simple program to transfer the XML timestamp to the corresponding .html and .js files and run this after each build, but I would prefer not to have to do this! I have learnt over the years to recognize when this is not safe and all files need to be updated, but the present situation is not supportable for minor maintenance, which usually takes only a minute or so. Uploading all our 2400 small files takes well over half an hour, as I discovered on the first upload with the new skin.

[Martin Wynne]

Hi Tim,

I've found that uploading individual files doesn't work with V3.

I upload the entire lot to a dummy folder, and then swap the folder names afterwards. This takes only a couple of seconds and means your site is down only for as long as that takes.

In V3 the images are in a sub-folder, so you don't need to upload that every time if you don't want to. That would save the majority of the upload time. This assumes you have a means on the server controls (e.g. cPanel) or FTP to move an entire folder about. i.e. into the the dummy folder before swapping names.

regards,

Martin.

[Tim Green]

Hi Tim,

As Martin points out, uploading WebHelp 3 output selectively is tricky, because there are always two copies of each topic file: one .html file on the root level of the output folder and one .js file containing just the compressed body content of the topic in the /jstopics sub-folder.

If you change the skin or make any changes at all to a skin you must always delete all the old WebHelp files and upload ALL the new files because that changes everything, without exception. Similarly, you must always upload all the files related to the full-text search, because they all change if you change even one letter in one topic (settings.js and all the file with names beginning with "zoom...").

Normally, the timestamps of the topic files only change when you have actually edited a topic file. You can change this to the publishing timestamp in Configuration > Publishing Options > WebHelp > HTML Export Options, but then ALL the output files will have the publishing timestamp.

The only really reliable selective upload option is to activate the change flag option in HTML Export options. Then all files that have any changed content will have their change flag set. However, this only works if you have an FTP upload program that can do selective uploads on the basis of the change flag.

[Tim Frost]

No problem with uploading both files for changed topics, or with making the zoom files 'always upload'. And I am used to uploading everything if any change has been made to the skin. But thanks for the pointer to the HTML Export Options area, because there seem to be some problems here, and a solution:

1. We have 'Apply Date Stamp of topic to the corresponding HTML output file' CHECKED, but this is not happening. This setting is checked in the project options: there is no corresponding setting in the skin. All HTML and JS output files have the time of writing.

2. We have 'Modify archive bit of topic files' enabled, but we do not use this and it would not help to determine which html and js files to upload. But I cleared all the html and js archive flags, changed two topics, and rebuilt to test this anyway. In the output, the two changed topic html/js files did NOT have the archive flag set, although a few other hm*.html and hm*.js files, and zoom files, did have it set. Curious, but not an issue for me, anyway.

3. I then found a setting for 'sync topic timestamps' in the SKIN file, using the toolbox. This was initialised to 0 and I changed it to 1, modified one more topic and rebuilt. This has fixed the problem and the timestamps of the topic files are now transferred to the corresponding html and js files as expected. And this time the archive bit WAS set on the modified html/js files.

I feel that this setting should be exposed in the skin, because its name in the toolbox list is misleading: it would be clearer if it said that it synchronises the OUTPUT timestamps. It was sufficiently worrying that I first backed up my topics folder in case this was actually the option for updating the topic timestamps on publishing! Alternatively, would unchecking 'activated' in the toolbox list have caused the project setting to be used? If so, it might be better if this was the default. Finally, the 'archive' setting in the export options dialog only mentions that the archive flag will be set on the topic files, not on the output (and then only if the output timestamp updating is enabled).

Thanks for your help, as usual, but this time for pushing me towards finding what seems to be the solution!

[Tim Green]

Hi Tim,

I then found a setting for 'sync topic timestamps' in the SKIN file, using the toolbox.

Sorry -- I forgot that I activated that option in the skins. When you do that then the setting in the project is ignored. If you want to revert it to project control you need to delete the value and uncheck the "Activated" button. Then the setting will be completely removed from the skin and control goes back to the project. (I just noticed you get an annoying message when you do this in this location. I will correct this in the maintenance update coming this week or next week.)