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
-Robert
On Sun, Jun 15, 2008 at 3:51 AM, Markus Krötzsch <
[EMAIL PROTECTED]> wrote:
> On Donnerstag, 29. Mai 2008, Steve Sanbeg wrote:
> > On Wed, 2008-05-28 at 09:13,
> > [EMAIL PROTECTED] 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 PROTECTED]>
> > > Subject: Re: [SMW-devel] Poem extension revealing faults
> > > To: [email protected]
> > > Message-ID: <[EMAIL PROTECTED]>
> > > 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.
>
> <snip>
>
> >
> > 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
> http://korrekt.org/page/Note:PHP5_migration_problems_with_MediaWiki
>
> Please let us know if this fixes your problem, so we can close or modify
> the
> <poem> bug.
>
> -- Markus
>
> >
> > > 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
> > > [EMAIL PROTECTED] www http://korrekt.org
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Semediawiki-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
> --
> Markus Krötzsch
> Semantic MediaWiki http://semantic-mediawiki.org
> http://korrekt.org [EMAIL PROTECTED]
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Semediawiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
--
Roses are red,Violets are blue,I'm schizophrenic,and so am I.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Semediawiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
