Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component:
Branches:
By default it should display the latest revision unless a different rev has been specified by url params. Right?
It doesn't. Instead it displays what was left behind in the topicObject during the course of the preceeding rendering steps.
Hard to reproduce as %META{"form"}% displays fine in pattern but not in nat.
See irc logs starting at
http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2010-08-17,Tue&sel=278#l274
--
MichaelDaum - 17 Aug 2010
Wrong. it displays the
current rev, whatever that might be. In a viewed topic, it shows the currently viewed rev. In an included topic, it shows the rev included.
Without a testcase, or a description of how to reproduce this, I can't do anything.
--
CrawfordCurrie - 17 Aug 2010
As I said it is hard to reproduce. Still I get the error. It is a sever bug.
Do we agree that by "current" we define "the revision to be displayed currently"?
Please notice, that this might significantly differ from "the revision currently loaded into the topicObject" as being passed to %META.
The different behaviour stem from the fact that the very topicObject being used was formerly loaded with a different version which is not necessarily the one to be displayed.
It does not matter
how a different non-current revision got loaded into the topicObject. Presumably that happed during the course of some plugins reading arbitrary revision info.
In short: there is nothing in the code to make sure %META reads the current revision of a topicObject to be displayed.
--
MichaelDaum - 17 Aug 2010
No, and there shouldn't be. If the wrong revision is passed to the META code, then it's the caller that is at fault. For example, a call to $meta->expandMacros will use the revision currently loaded in $meta. $meta might be the object created in UI/View, or it might be created somewhere else entirely; or some other piece of code may have force-reloaded the object with a different version (perhaps even a plugin?). That's why it's impossible to track down without specific debugging information.
--
CrawfordCurrie - 18 Aug 2010
Would you at least consider it an error when
%META{"form"}%
displayed the wrong revision's form? Because that's what I get.
Here's how to reproduce the bug reliably:
- create a topic and attach form A to it
- edit the topic and attach form B to it and click force new revision
- add
%REVINFO{rev="1"}%
to the topic to make sure REV 1 gets loaded, the one with the old form A attached to it
- save
ERROR: : You'll see form A being displayed at the bottom of the page, although form B is currently attached.
--
MichaelDaum - 18 Aug 2010
The root cause is that meta objects can reload a different revision. That's a conceptual problem that has caused several problems on trunk in the past.
There might still by means to pollute a meta object with a different revision, which is then reused later on, i.e. the "current" meta object as being
passed around by the TML renderer. This one is sacred.
For now I didn't find any other way to trigger the reported error, now that
REVINFO has been identified evil and been fixed.
Still, that's only working on the symptoms.
--
MichaelDaum - 18 Aug 2010
Reopening this bug as I just found out that
%META{"attachments"}%
returns an empty string for a meta object that hasn't been loaded yet.
As far as I see, %META must have loaded
any revision at least, i.e. make sure there is one loaded.
--
MichaelDaum - 18 Aug 2010
erm, what's the call path? It shouldn't be possible for META to be called without a revision loaded.
--
CrawfordCurrie - 19 Aug 2010
Also, is this still the case after the most recent checkin against
Item9487 ?
--
CrawfordCurrie - 19 Aug 2010
Not anymore. Works now. Great. I am still a bit nervous about this. So I will keep poking around for a few days. Closing this item - will reopen a new one even if related.
--
MichaelDaum - 20 Aug 2010