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 <markus@semantic-mediawiki.org> wrote:
On Donnerstag, 29. Mai 2008, Steve Sanbeg wrote:
> On Wed, 2008-05-28 at 09:13,
> semediawiki-devel-request@lists.sourceforge.net 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 <mak@aifb.uni-karlsruhe.de>
> > Subject: Re: [SMW-devel] Poem extension revealing faults
> > To: semediawiki-devel@lists.sourceforge.net
> > Message-ID: <200805191516.54061.mak@aifb.uni-karlsruhe.de>
> > 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
> > mak@aifb.uni-karlsruhe.de          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
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel



--
Markus Krötzsch
Semantic MediaWiki    http://semantic-mediawiki.org
http://korrekt.org    markus@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.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel




--
Roses are red,Violets are blue,I'm schizophrenic,and so am I.