This didn't fix my problem. I'm sure it's one of the gazillion string-function extensions I installed to chop up n-ary data in templates. I haven't had time to disable them all in turn and figure out which one it is, but I will
On Donnerstag, 29. Mai 2008, Steve Sanbeg wrote:
> On Wed, 2008-05-28 at 09:13,
> firstname.lastname@example.org wrote:
> I can clarify this a bit, since I looked into it a little.
> > Message: 1
> > Date: Mon, 19 May 2008 15:16:44 +0200
> > From: Markus Kr?tzsch <email@example.com>
> > Subject: Re: [SMW-devel] Poem extension revealing faults
> > To: firstname.lastname@example.org
> > Message-ID: <email@example.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> > On Freitag, 16. Mai 2008, Robert Murphy wrote:
> > > Dear Developers,
> > >
> > > I have successfully installed the Poem extension
> > > (http://www.mediawiki.org/wiki/Extension_talk:Poem) on my wiki and it
> > > has been running fine. However, I just discovered too faults with it,
> > > that I now think may be due to Semantic MediaWiki.
> > >
> > > First, on the talk pages of custom namespaces, use of the <poem> tag
> > > makes the error
> > > UNIQ583c33685170dbcd-poem-00000000-QINU
> > > (for an example, see
> > > http://reformedword.org/index.php?title=Greek_talk:Genesis/13&oldid=423
> > >322) .
See below, I may have an idea for that.
> > >
> > > Second, it makes the factbox right after the </poem>, in the middle of
> > > the page, and the values aren't on the page's main factbox, at the
> > > bottom. (see http://reformedword.org/Greek:Psalm/119).
This problem is due to the parser things I described, and I see no obvious way
of preventing this. Poem processes content as if it was a normal page, and
SMW cannot see that it actually isn't, and thus puts a Factbox below it.
> I don't think this is related to poem or SMW. From what I saw, if you
> put an XML-style tag, like <nowiki>something</nowiki>, it doesn't render
> correctly. I'd assume this is because the strip state is being
> corrupted by some extension, although probably not poem, SMW, or any of
> the official extensions. The best bet would be remove one by one, or
> remove all and add one by one, to find out where the bug is.
Oh, I just recall to have had strip state troubles due to wrong PHP5 settings
once! Check out
Please let us know if this fixes your problem, so we can close or modify the
> > The other stuff (Factbox in page) happens for other reasons. The problem
> > is that SMW uses MW hooks during parsing, i.e. functions that the parser
> > triggers when parsing wiki articles. Unfortunately, MediaWiki uses more
> > than one parser, and any hook in the parser code is used by all of those.
> > Thus, whenever MediaWiki uses a second parser for some part of text, SMW
> > will do the same as if this text was the only input. I know of no way of
> > detecting whether SMW runs in a subparser or in the "real" parser.
> > Normally, however, subparsers are triggered before or after the main page
> > was parsed, and no semantic data is found then -- thus the Factbox is
> > empty and remains hidden. You can try __NOFACTBOX__ to not display the
> > Factbox, or you can check whether it suffices to avoid semantic
> > annotations in certain environments.
> > -- Markus
> It uses the same parser, by calling its recursiveTagParse method.
> Although I think there are hooks that are called at the right time to
> tell the difference, that happens after links are processed, so I guess
> those won't recognize the SMW link syntax.
> >From a quick look at SMW, it looks like it's using a single hook to
> parse its special link syntax and generate the fact box, before MW does
> the normal link processing. It may be better to use one function that
> replaces the links and stores the results, then add the fact box later
> (i.e. from ParserBeforeTidy)
> > --
> > Markus Kr?tzsch
> > Institut AIFB, Universit?t Karlsruhe (TH), 76128 Karlsruhe
> > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
> > firstname.lastname@example.org www http://korrekt.org
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> Semediawiki-devel mailing list
Semantic MediaWiki http://semantic-mediawiki.org
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Semediawiki-devel mailing list