Snippets and <%TOPICLASTEDITED%>

[Alexey Zhebel]

If I have certain text repeated throughout several topics, it is convenient to use linked snippets. However, when I change the contents of the snippet, the time and date of when the topics containing this snippet were last edited do not update. Is there a way to work around this?

[Tim Green]

Hi Alexey,

The variable output is actually correct because the topic has not been edited. It is the snippet that has been edited, not the topic. At the moment it is not possible for Help & Manual to know whether a snippet that is being inserted in a topic has been edited or not. I will check and see if this can be put on the wish list for a future version.

The problem is, what if a topic contains multiple snippets? There will then be multiple "last edited" timestamps, so which one do you take?

[Alexey Zhebel]

The problem is, what if a topic contains multiple snippets? There will then be multiple "last edited" timestamps, so which one do you take?

If its the same snippet inserted multiple times, then the timestamp will be the same. If they are different snippets, the latest one would be the most reasonable obviously.

Users of published outputs don't care how my project is structured, they don't even know about snippets. They want to know when the last change was made to the information in the topic. If I change a snippet, I want all timestamps in topics using this snippet to update. This is something that is not relevant to me, I can just check the snippet's timestamp if I need to, but it is relevant to the user.

[Tim Green]

Hi Alexey,

I've discussed this with our developers and I'm afraid that there's no short-term solution for it. Even if you put the TOPICLASTEDITED variable in the snippet it will still deliver the timestamp of the topic in which it is inserted, because the variable is resolved after the snippet is inserted in the topic, and the topic timestamp has not changed.

[David Makulec]

Tim --

While I recognize that, from a technical perspective, my issue is different, I am similarly frustrated that H&M doesn't recognize the replacement of a topic's screencapture with an updated (but identically-named) version as a change to that topic.

In order to "mark" the topic containing the replaced image as changed, I have to make a "fake" text edit, save it, and then undo that edit (and save it again). (This workaround doesn't, of course, address any additional topics where that image is also used.)

We've discussed this before -- and I see a similarity that, as with the snippets discussed above, in the limited context of the topic itself, the topic has not (strictly speaking) changed.

But of course, as Alexey points out, from the Help user's point of view, it *has* changed.

I'm of mixed minds about exactly how to "fix" this. But, if I were King of the Forest, I'd change it.

[Tim Green]

Hi David,

I do appreciate the problem and sympathize, but at the same time this is an even knottier problem than Alexey's with the snippets. As far as the program is concerned, nothing at all has changed, because all it knows about the graphics file is its name. Synchronizing the timestamps of the graphics files with the timestamp of the topic wouldn't really work because it's quite possible to use graphics that are years old. The only real option that comes to mind offhand would be to scan the file contents, create a checksum and store and compare that. But that would be hugely processing-intensive and would slow output to a crawl, for a very tiny benefit.

In order to "mark" the topic containing the replaced image as changed, I have to make a "fake" text edit, save it, and then undo that edit (and save it again).

There's a much easier way: Just double-click on one of the images and click on Open without changing anything to insert it "again". The topic will be flagged as changed and its timestamp will be updated.

[David Makulec]

Tim --

Understood, if H&M is ignoring everything about the image except its name (including its resolution, as we've discussed before ).

The "doubleclick | open" workaround is a bit nicer than a fake text edit, which someone (who? me?) just *might* forget to undo. Thanks!

So now I just have to persuade you to have a "rightclick | Picture | Reload" on an image have the same effect.

[Alexey Zhebel]

Synchronizing the timestamps of the graphics files with the timestamp of the topic wouldn't really work because it's quite possible to use graphics that are years old. The only real option that comes to mind offhand would be to scan the file contents, create a checksum and store and compare that. But that would be hugely processing-intensive and would slow output to a crawl, for a very tiny benefit.

I think a good solution would be to compare timestamps of all inserted content with the timestamp of the topic. If a graphic or snippet was last edited years ago - it doesn't matter, it's ignored if it's timestamp is older then the topic's. And if not, the timestamp of the topic is updated. You can even do it as a separate feature from publishing: Update timestamps. Then the author can do it if he has a Topic last edited line at the end of each topic in a help output, for example. Or not do it if he does not need to provide users of his output with this info.