Silva Issue Tracker Archive: Issue1645

 This tracker has been migrated to Launchpad. Please post new messages at:
Title Ghosts without date in HTTP header
Priority bug Status testing
Superseder (list) Nosy List flynt, kitblake, lbenno, thisfred, wolfgang (list)
Assigned To thisfred Topics Silva-1.5, Silva-1.6 (list)

Created on 2006-11-29.16:56:56 by flynt, last changed 2007-03-15.17:24:29 by thisfred.

msg9277 (view) Author: thisfred Date: 2007-03-15.17:24:27
Whew, it's fixed, both on trunk and the 1.5 branch. The main changes are in
SilvaMetadata, so you'll need the trunk of that to test.
msg9253 (view) Author: thisfred Date: 2007-03-12.15:53:06
Ok, I will look at this with Martijn on thursday, and hopefully a fix will find
its way into 1.6 and if it's at all possible into the 1.5 branch.
msg9252 (view) Author: lbenno Date: 2007-03-12.15:44:45
I can confirm that this unexpected behavior exists in Silva 1.5.8 too.
I don't think that this behavior is new, but existed for quit a long time
msg9249 (view) Author: thisfred Date: 2007-03-08.20:29:11
Note to self: GhostFolders have the same problem.
msg9248 (view) Author: thisfred Date: 2007-03-08.20:26:08
Oh, and I haven't thought of a solution yet, unfortunately, but I'm sure I will.
msg9247 (view) Author: thisfred Date: 2007-03-08.20:24:55
This is a beauty, took me a good while to track down:

We have access handlers for the metadata of ghosts, which means that if the
metadata binding for a ghost is called, it passes through that accesshandler,
which returns the metadata of the target instead. 

That is obviously a huge problem when we get the binding when we want to *WRITE
TO IT*. 

What I don't get, is why this behavior is new: both the handlers, and the way
the code calls them are ancient. Benno, can you confirm this is not the case in
1.5? The way to trigger the behavior is to click the 'save reference' button on
the ghost, and see whether the target document's modification date is changed
after that.

To assist my own memory:

The offending call comes from lines 260-267:

                binding = self.service_metadata.getMetadata(version)
            except BindingError:
            if binding is None:
            now = DateTime()
            binding.setValues('silva-extra', {'modificationtime': now})
msg9229 (view) Author: lbenno Date: 2007-03-01.11:47:23
I encountered a new problem concerning ghosts and their target objects:
I had a Silva Document with last modified (according to the SMI) Oct. 26, 2006.
I then created a ghost for this target document. This ghost, then, shows as last
modified date March 1, 2007. That's what we expect.
Unfortunately, the last modified date of the target object changed through this
action and shows March 1, 2007 too :-(
That's not what we expect concerning the use of get_modification_datetime with
cache control.
msg9225 (view) Author: daniel Date: 2007-02-26.19:46:02
From r23559:

Ghosts now override `get_modification_datetime` to get their
modification date from the haunted object, allowing the
`Last-Modified` header to be set in a convenient way.

If you're setting the headers via model/get_modification_datetime, this should
be your fix.  Previously, this would have returned None.

Can you test this and confirm that we can close the issue?  Thanks!
msg9007 (view) Author: kitblake Date: 2007-01-19.07:00:14
I'm removing the Silva 1.5 label, leaving 1.6. We still don't know if we can fix
msg8977 (view) Author: flynt Date: 2006-12-11.18:56:26
Okay. I see the point. I agree, if it needs larger changes, it is not suitable
for a bugfix release.
msg8975 (view) Author: thisfred Date: 2006-12-11.12:07:31
Since the headers are set from Zope, and Silva doesn't really have a way to
intervene currently, that will be rather hard, and I  don't think we can
realistically expect to do this for 1.5.9 which I hope to release today or
tomorrow. This is really more than a bugfix issue, and if we find a way to solve
this, it probably shouldn't go into a bugfix release version anyway.
msg8974 (view) Author: flynt Date: 2006-12-11.11:51:07
So, is it possible to follow Kit's proposition to show as 'Last-Modified' the
respective date of the haunted object for the next release of Silva-1.5?
msg8956 (view) Author: thisfred Date: 2006-11-29.18:38:28
Nope sorry, that is not entirely correct. I think that *Zope* actually sets this
header. Silva doesn't override it anywhere, and so Ghosts show the modification
date of the ghost object, not the haunted content...
msg8955 (view) Author: thisfred Date: 2006-11-29.18:33:09
I don't think plain Silva even sets the Last-Modified header in the response. I
think you might be doing that in your own public layout code, in which case
you'd need to call the metadata on the published version of the haunted content,
instead of the Ghost itself...
msg8954 (view) Author: kitblake Date: 2006-11-29.17:49:21
Ok. Ghosts should provide the last modified of the haunted object. Once a ghost
is made it usually never changes (even though it's versioned content).
msg8953 (view) Author: flynt Date: 2006-11-29.16:56:55
Bengt is reporting:

Ghosts seem to lack a Last-Modified date in the HTTP header. Therefore they are
not cacheable. They should return the date of the target object.
The main page is a ghost to which has a date,
but not the main page.
Date User Action Args
2007-03-15 17:24:29thisfredsetstatus: in-progress -> testing
topic: + Silva-1.5
messages: + msg9277
2007-03-12 15:53:07thisfredsetmessages: + msg9253
2007-03-12 15:44:45lbennosetmessages: + msg9252
2007-03-08 20:29:12thisfredsetmessages: + msg9249
2007-03-08 20:26:46thisfredsetstatus: testing -> in-progress
2007-03-08 20:26:31thisfredsetpriority: wish -> bug
2007-03-08 20:26:09thisfredsetmessages: + msg9248
2007-03-08 20:24:56thisfredsetmessages: + msg9247
2007-03-01 11:47:24lbennosetmessages: + msg9229
2007-02-26 23:46:28flyntsetnosy: + lbenno, wolfgang
2007-02-26 19:46:04danielsetstatus: chatting -> testing
messages: + msg9225
2007-01-19 07:00:16kitblakesettopic: - Silva-1.5
messages: + msg9007
2006-12-11 18:56:28flyntsetmessages: + msg8977
2006-12-11 12:07:32thisfredsetmessages: + msg8975
2006-12-11 11:51:08flyntsetmessages: + msg8974
2006-11-29 18:38:29thisfredsetassignedto: thisfred
messages: + msg8956
2006-11-29 18:33:10thisfredsetmessages: + msg8955
2006-11-29 17:49:22kitblakesetstatus: unread -> chatting
messages: + msg8954
2006-11-29 17:46:38kitblakesetnosy: + thisfred
2006-11-29 16:58:10flyntsettopic: + Silva-1.5, Silva-1.6
2006-11-29 16:56:56flyntcreate