On 20/11/2010 18:04, don undeen wrote:
> 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?
Clearly, if SF triggers an MW activity that requires $wgTitle to be set
then it must make sure that $wgTitle has an appropriate value.
>
> 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.
I have to disagree here. The refreshLinks.php script sets $wgTitle and
$wgArticle to execute its operations. It directly uses these variables
and executes operations on them that require both to be set.
In contrast, SMW_refreshData.php is more like runJobs.php: all it does
is running jobs. The only difference to runJobs.php is that the jobs are
not taken form the job queue but are created by other means. But all the
jobs that SMW_refreshData.php runs could just as well be run by runJobs.php.
Jobs can never assume to operate on an article page that is set in
$wgTitle, and runJobs.php and the MW Job class indeed do not set this
variable. This is why we cannot fix the problem by modifying
SMW_refreshData.php: it is just one of many possible ways that will lead
to the SF code being executed in a context where $wgTitle is set to the
wrong value. The only way to solve this is to modify the SF code to
handle this situation appropriately. In contrast, adding an assignment
to SMW is merely confusing, making the code more complicated to
understand (Since jobs must not use $wgTitle, why would it be set by a
script that runs jobs?). Clearly, SMW cannot provide workarounds for
alleviating the effects of broken code in extensions that use SMW.
What we can do, however, is to set $wgTitle to a fallback value in the
script, similar to what is done in runJobs.php. I have committed this to
SVN now, ensuring that $wgTitle is always set to a (meaningless) value
when this script is run. Maybe this can at least avoid the error
messages you get, though it might still lead to undesired effects.
> 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.
+1, global variables are bad for code design
Regards,
Markus
>
>
> ________________________________
> 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
