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 <markus@semantic-mediawiki.org>
To: don undeen <donundeen@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<donundeen@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<donundeen@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