Difference between revisions of "Issue:Call to a member function getPrefixedDBkey() on a non-object"
Ycombarnous (talk | contribs) (→Same error with MW 1.13.2 and DPL 1.7.4) |
Ycombarnous (talk | contribs) (→Same error with MW 1.13.2 and DPL 1.7.4) |
||
Line 141: | Line 141: | ||
*Note 5: I have no issue with #lsth usage, is that because it uses still the old parser? --[[User:Ycombarnous|Ycombarnous]] 22:30, 7 December 2008 (UTC) | *Note 5: I have no issue with #lsth usage, is that because it uses still the old parser? --[[User:Ycombarnous|Ycombarnous]] 22:30, 7 December 2008 (UTC) | ||
+ | |||
+ | * Note 6: could this help: [https://bugzilla.wikimedia.org/show_bug.cgi?id=12906] ? --[[User:Ycombarnous|Ycombarnous]] 10:21, 8 December 2008 (UTC) | ||
== Reply == | == Reply == |
Revision as of 12:21, 8 December 2008
Description: | Call to a member function getPrefixedDBkey() on a non-object |
Extension / Version: | DPL / 1.7.3 |
Type / Status: | Bug / open |
Contents
Problem
From file version 20080505195057!Semeb_extensions.zip onwards, using mediawiki 1.12.0 I get this error when accessing any page that uses DPL:
Fatal error: Call to a member function getPrefixedDBkey() on a non-object in /var/www/mediawiki-1.12.0/includes/Preprocessor_DOM.php on line 972
Previous versions are OK.
Test Case
Test case now on this wiki (since upgrade to 1.13): paste the following into a page.
{{#dpl: | uses=Template:Issue | include={Issue}:Description,#Problem[200] | table=class="wikitable sortable", Issue,Problem }}
Ianb1469 19:26, 27 August 2008 (UTC)
Reply
I was able to track the problem down to two minimalistic files, called Xxx and Yyy. Xxx contains the following code
{{#dpl: | titlematch=%Yyy% | include=#X }}
But the offending statement comes from the parser itself. Could you please try to involve those people who made the new parser?
Gero 21:19, 27 August 2008 (UTC)
Is there a test case that triggers this without using DPL then? Ianb1469 05:13, 28 August 2008 (UTC)
- Unfortunately not, so far. Maybe I can shrink the code down, but I guess the effect can only be shown if one writes an extension which calls that parser function in a certain way. I am pretty sure that the calling code does not pass any corrupted paranmeters but this has still to be shown. Can you program or at least read php? Gero 06:59, 28 August 2008 (UTC)
- No, I've never really programmed php. I've plenty of Ada, C and Perl experience, so I could probably make sense of it, but writing php definitely not. Ianb1469 18:52, 28 August 2008 (UTC)
Parser function only
Hi, I also have the same problem but I realised the error only appears when {{#dpl:}} syntax is used instead of <DPL></DPL>, which works correctly. -EmuWikiAdmin1 - July 19th 2008
Heading Inclusion
I realised that Line 972 was meant to threat some data related to heading and I tried removing the heading (=Heading Example=) from my list separators and it worked. So basically it's a problem with heading generation -EmuWikiAdmin1 - July 20th 2008
Yes, this seems to be the case. The first example triggers the bug, the second does not. (Mwiki 1.12, DPL 1.7.6)
Triggers bug: {{#dpl: | category=test | include={template1}:name,#Chaptername | table=class="wikitable sortable", X,Y,Z }} OK: {{#dpl: | category=test | include={template1}:name | table=class="wikitable sortable", X,Y,Z }}
Ianb1469 00:33, 27 August 2008 (CEST)
Occurring in MW 1.13.0
I just started getting this problem after a MediaWiki 1.13.0 upgrade. Here is the DPL query in question:
{{#dpl: |category = My category name |format = ,\n=[[%PAGE%|%TITLE%]]=\n\n,, |includepage = %0 |includetrim = true |noresultsheader = No entries |ordercollation = latin1_general_ci |reset = templates }} All articles in the category are in the Template namespace.
The error is:
- Fatal error: Call to a member function getPrefixedDBkey() on a non-object in ...\includes\parser\Preprocessor_DOM.php on line 994
The line is:
$titleText = $this->title->getPrefixedDBkey();
in function expand(). The above example worked fine in 1.12.0. --Maiden taiwan 16:10, 20 August 2008 (CEST)
Related Error Message
It may be unrelated, but it sometimes occurs with two other error messages (dpl 1.7.6_
Notice: Uninitialized string offset: 0 in /var/www/mediawiki-1.12.0/extensions/DynamicPageList-1.7.4/DynamicPageList2.php on line 2351
Notice: Uninitialized string offset: 0 in /var/www/mediawiki-1.12.0/extensions/DynamicPageList-1.7.4/DynamicPageList2.php on line 2351
Fatal error: Call to a member function getPrefixedDBkey() on a non-object in /var/www/mediawiki-1.12.0/includes/Preprocessor_DOM.php on line 972 Ianb1469 00:40, 27 August 2008 (CEST)
I also get this bug in MW 1.13.2
Fatal error: Call to a member function getPrefixedDBkey() on a non-object in ...../includes/parser/Preprocessor_DOM.php on line 994
It's when I try to save a page which is in a category (the categories have dpl). Will post more detail when I have time Jonathan 00:13, 6 October 2008 (UTC)
Update: it gives the error when I go to save the page, but MW has saved the page, and if I reload the page MW does display it correctly. Jonathan 00:19, 6 October 2008 (UTC)
But when I try to save a category page which contains a call to the template (which has the dpl) it won't save. Jonathan 00:23, 6 October 2008 (UTC)
Final update (I hope): It was when the page to be saved belonged to a category whose DPL page included part of that page; if the page to be saved would have had NO text included then the category broke. If that's not clear, then please do ask Jonathan 00:37, 6 October 2008 (UTC)
Same error with MW 1.13.2 and DPL 1.7.4
Some DPL work, some don't, I had to revert an upgrade quite late in testing after realizing that. PAges seem to have in common:
- call with compact form {{#dpl...}}
- all of them use the chapter inclusion function
Help ;-). --Ycombarnous 20:54, 7 December 2008 (UTC)
- Note 1: I just tried with DPL 1.7.2, and everything seems to work fine there!??! --Ycombarnous 21:36, 7 December 2008 (UTC)
- Note 2: I can confirm I have the same pattern in my DPL as XXX example from Ianb1469. I include chapters from page that have sub-chapters. Only in that case do I get the issue.
- Note 3: and also confirm that using the <DPL></DPL> syntax, I don't get the issue. But I have tons of {{#dpl:...}} all over my website, gah...
- Note 4: when using debug=5 I get the proper wikitext in above Xxx example. Gah, this is getting me mad.
- Note 5: I have no issue with #lsth usage, is that because it uses still the old parser? --Ycombarnous 22:30, 7 December 2008 (UTC)
- Note 6: could this help: [1] ? --Ycombarnous 10:21, 8 December 2008 (UTC)