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
