Thanks for that, Markus.
You say the problem fundamentally is :
"either at the inappropriate use of $wgTitle in SF or at the code that calls SF
in a context that it is not meant to be run in."
I think it's actually:
"code that SF calls in a context that it is not meant to be run in."
Not in front of the code now, but the error crops up in core code (OutputPage
class), and the fix I did was in "core-ish" (SMW) code.
But, SF is attempted to generate a createPage job in this part of the code,
which involves parsing a page that isn't the current "page" (since there is no
page here, we're in a script. So this is a unusual activity i guess.
But portions of the core parsing code expect to be in the context of a page,
and are therefore breaking.
So, maybe there's a better way for SF to go about parsing these auto-generated
pages, but maybe the code didn't expect this kind of use, and doesn't have the
necessary API and hooks for it. Anyone know?
But in the meantime adding one line in SMW_refreshdata.php is a pretty easy
thing to do. And really, it's the same thing I see in mediawiki's
refreshLinks.php script, which is a very similar type of operation. Basically,
if you're simulating the activities that a page might perform, it makes some
(hackish) sense to construct the context that the page would operate in.
At least in theory; obviously there could be unintended sideffects; it's better
to have a layer of code in between the context and the page activity; those
global variables freak me out.
anyways, I sure appreciate you looking into this.
Don Undeen
________________________________
From: Markus Krötzsch <mar...@semantic-mediawiki.org>
To: don undeen <donund...@yahoo.com>
Cc: smw dev list <semediawiki-devel@lists.sourceforge.net>
Sent: Sat, November 20, 2010 8:21:41 AM
Subject: Re: [SMW-devel] having trouble with "creates pages with form" feature
on SMW_refreshdata.php
On 19/11/2010 21:53, don undeen wrote:
> here I am, posting fixes to my own problems...
>
> in SMW_refreshData.php, around line 166,
> where you see:
> $title = Title::newFromText( $page );
>
> I added after that:
> $wgTitle = $title;
>
> and that seems to take care of it.
>
> This fix could probably go into SF instead, but it's probably appropriate that
> it be on that script; similar code is the MW's refreshLinks.php
>
> anways, if anyone's having a similar problem, there you go.
There is usually a problem if code is relying on $wgTitle. Normally, MediaWiki
controls what is in $wgTitle, and uses it for its own purposes. There are only
very few places where extensions can safely work with the contents of this
variable (for example, SMW uses it to get the extracted semantic data in a hook
*after* parsing). Note that $wgTitle must never be used during parsing. In this
situation, the title is obtained from $wgParser->getTitle() only.
Let me be more explicit:
*** $wgTitle must typically not be used in extensions. ***
*** $wgTitle must typically not be set in extensions. ***
Looking into this, I now found a bug in SMW where $wgTitle was set in
SMWSQLStore2::refreshData(). It is inappropriate and dangerous to set a global
MediaWiki variable in this place. I have now fixed this. Code that relies on
$wgTitle being set by a method that is actually meant to provide basic storage
manipulation operations (independent of the current MW application state)
should
urgently reconsider its design assumptions.
The only exception where $wgTitle might be set in extension code is when an
extension starts new parsing operations, i.e. is at the beginning of MediaWiki
control flow. This can indeed happen in maintenance scripts (it does in
refreshLinks.php), but normally not for batch processed pages as in our above
refresh script. Looking at MediaWiki's scripts, one can see that $wgTitle is
often set to a place holder value that has no significance to the current task,
e.g.
./maintenance/runJobs.php:57:
$wgTitle = Title::newFromText( 'RunJobs.php' );
Summing up: it is neither common nor required to set $wgTitle in extensions or
in maintenance scripts, unless the respective code is the start of a new global
processing activity (such as in MW's refreshLinks.php). It is wrong and
potentially harmful to set $wgTitle in functions that can be called in jobs
(such as the refreshData function I mentioned above).
I suppose that the problem discussed in this thread ultimately comes from an
unsuitable access to $wgTitle. Setting the variable in SMW_refreshData.php
would
not be wrong (since it is an entry point and $wgTitle was not set before), but
it would not solve the underlying bug. Indeed, the only thing that happens in
this script afterwards is that an update job is run. Code in jobs must not
depend on $wgTitle. Never. Working around the issue in this one place is not
going to solve it. The issue needs to be addressed at its root instead: either
at the inappropriate use of $wgTitle in SF or at the code that calls SF in a
context that it is not meant to be run in.
Cheers,
Markus
> ________________________________
> From: don undeen<donund...@yahoo.com>
> To: smw dev list<semediawiki-devel@lists.sourceforge.net>
> Sent: Fri, November 19, 2010 4:43:42 PM
> Subject: Re: [SMW-devel] having trouble with "creates pages with form" feature
> on SMW_refreshdata.php
>
>
> oh, and when I run maintenance/refreshLinks.php, in main mediawiki directory,
> the createPage jobs get created just fine, and all that passes through the
same
> semanticforms code.
> So maybe the problem is in SMW...
>
>
>
>
> ________________________________
> From: don undeen<donund...@yahoo.com>
> To: smw dev list<semediawiki-devel@lists.sourceforge.net>
> Sent: Fri, November 19, 2010 4:38:01 PM
> Subject: having trouble with "creates pages with form" feature on
> SMW_refreshdata.php
>
>
> hey guys,
> I'm having some trouble running SMW_refreshData.php on pages with the
> "creates pages with form" property.
>
> The idea is that if there's a page with a property pointing to a non-existant
> page,
> and that property has the property "Creates pages with form::blah",
> then a job task will be set up to create a page using form "blah", with the
>page
> name of the non-existant page.
>
> Make sense? Anways, when I try to run SMW_refreshData.php, and it encounters
>one
> of those pages with the broken link. I get the error:
>
> Empty $wgTitle in OutputPage::parse
> Backtrace:
> #0 [internal function]: OutputPage->parse('This is a minor...', true, true)
> #1 D:\xampp\htdocs\metwikiupgrade\includes\StubObject.php(58):
> call_user_func_array(Array, Array)
> #2 D:\xampp\htdocs\metwikiupgrade\includes\StubObject.php(76):
> StubObject->_call('parse', Array)
> #3 [internal function]: StubObject->__call('parse', Array)
> #4 D:\xampp\htdocs\metwikiupgrade\includes\GlobalFunctions.php(740):
> StubObject->parse('This is a minor...', true, true)
> #5
>D:\xampp\htdocs\metwikiupgrade\extensions\SemanticForms\includes\SF_FormUtils.php(488):
>:
> wfMsgExt('minoredit', Array)
> #6
>D:\xampp\htdocs\metwikiupgrade\extensions\SemanticForms\includes\SF_FormPrinter.php(1032):
>:
> SFFormUtils::minorEditInputHTML(false, NULL, Array)
> #7
>D:\xampp\htdocs\metwikiupgrade\extensions\SemanticForms\includes\SF_LinkUtils.php(198):
>:
> SFFormPrinter->formHTML('<noinclude>?Thi...', false, false, NULL, NULL,
'Some
> very long ...', NULL)
> #8
>D:\xampp\htdocs\metwikiupgrade\extensions\SemanticForms\includes\SF_LinkUtils.php(149):
>:
> SFLinkUtils::createLinkedPage(Object(Title))
> #9 [internal function]: SFLinkUtils::setBrokenLink(Object(SkinOntoSkin3),
> Object(Title), Array, '00.19.13', Array, NULL)
> #10 D:\xampp\htdocs\metwikiupgrade\includes\Hooks.php(117):
> call_user_func_array(Array, Array)
> #11 D:\xampp\htdocs\metwikiupgrade\includes\Linker.php(222):
> wfRunHooks('LinkEnd', Array)
> #12 D:\xampp\htdocs\metwikiupgrade\includes\Linker.php(513):
> Linker->link(Object(Title), '00.19.13', Array, Array, 'broken')
> #13 D:\xampp\htdocs\metwikiupgrade\includes\parser\LinkHolderArray.php(233):
> Linker->makeBrokenLinkObj(Object(Title), '00.19.13', '')
> #14 D:\xampp\htdocs\metwikiupgrade\includes\parser\LinkHolderArray.php(115):
> LinkHolderArray->replaceInternal('<p><br />?</p>?...')
> #15 D:\xampp\htdocs\metwikiupgrade\includes\parser\Parser.php(4101):
> LinkHolderArray->replace('<p><br />?</p>?...')
> #16 D:\xampp\htdocs\metwikiupgrade\includes\parser\Parser.php(344):
> Parser->replaceLinkHolders('<p><br />?</p>?...')
> #17
>D:\xampp\htdocs\metwikiupgrade\extensions\SemanticMediaWiki\includes\jobs\SMW_UpdateJob.php(60):
>:
> Parser->parse('{{Interactive F...', Object(Title), Object(ParserOptions),
>true,
> true, 3372)
> #18
>D:\xampp\htdocs\metwikiupgrade\extensions\SemanticMediaWiki\maintenance\SMW_refreshData.php(170):
>:
> SMWUpdateJob->run()
> #19 {main}
>
>
> I think this is because this is running from a script, and therefor $wgTitle
> isn't set, because $wgTitle is supposed to be the title of the loaded page? is
> that right?
>
> the part that expects the wgTitle to be in place is in the wiki core:
> includes/OutputPage.php
> I dont' think I should be changing that.
>
> But looks like that's only called because of the call in SF to
> wfMsgExt('minoredit', Array)
> Do we need that?
> Or should I spoof up a wgTitle object when I first notice that it's null,
> somewhere in
>
> SF_LinitUtils.php::createLinkedPage
>
> Any Idea what's up? I'm using the SemanticForms 1.9.1, with the patch from
>Halo,
> just to make things a bit more complicated.
>
> All my other versions of things are in line with the latest stable halo
> releases.
>
>
> I feel like this may have been something I've fixed in the past, but lost due
>to
> upgrades.
> Maybe Yaron remembers something about this...
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
>
>
>
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
