Difference between revisions of "Issue:Upgraded to 1.11 Notice: Undefined variable"

From FollowTheScore
Jump to: navigation, search
(→‎Problem)
 
(26 intermediate revisions by 4 users not shown)
Line 2: Line 2:
 
  |Type        = Bug
 
  |Type        = Bug
 
  |Extension  = DPL
 
  |Extension  = DPL
−
  |Version    = ?
+
  |Version    = 1.4.5
 
  |Description = Notice: Undefined variable:
 
  |Description = Notice: Undefined variable:
−
  |Status      = open
+
  |Status      = closed
 
}}
 
}}
  
Line 22: Line 22:
  
 
== Reply ==
 
== Reply ==
 +
 +
This is my query
 +
 +
<nowiki><DPL>
 +
resultsheader= === A ===
 +
namespace = Terms
 +
shownamespace = false
 +
titlematch = A%
 +
</DPL></nowiki>
 +
 +
I did this for each letter through the alphabet. The Terms namespace is set to 100. I'm not sure how to enable the full error messages or give a full stack trace, but I will try to figure it out.  Thank you.
 +
 +
--[[User:Rovo|Rovo]] 03:11, 1 October 2007 (CEST)
 +
 +
:I cannot figure out how to turn on the full error message. --[[User:24.250.201.191|24.250.201.191]] 14:37, 1 October 2007 (CEST)
 +
 +
== Reply (2) ==
 +
 +
# You should put a '\n' behind the resultsheader, otherwise you will not get a heading.
 +
# Does the error depend on the namespace?
 +
# Does it work for one single letter? How do you do the "loop" for each letter? (If here is another extension involved, that could be the reason, too)
 +
# For full error information you must set $wgShowExceptionDetails = true; in the LocalSettings.php
 +
 +
== Reply (3) ==
 +
 +
# I'm not sure where to put the '\n' behind the resultsheader? At the very end, or just at the end of the word header, instead of an = ?
 +
# I've removed the namespace and shownamespace from the query, so it just looks for titlematch = A%
 +
# I am testing it on a page for a single letter only, A . It used to be set for each letter, just repeating the query for each.
 +
# I set the full error information, after turning off all other installed extensions, and only received the error,
 +
<nowiki>Parse error: parse error, unexpected T_REQUIRE_ONCE in /home/wikistoc/public_html/wiki/LocalSettings.php on line 161</nowiki>
 +
 +
I should add, line 161 is where the require call to DynamicPageList.php is.
 +
 +
--[[User:Rovo|Rovo]] 19:09, 1 October 2007 (CEST)
 +
 +
I have tried a streamlined query and still the same error,
 +
 +
<nowiki><DPL>
 +
  titlematch = A%
 +
</DPL></nowiki>
 +
 +
--[[User:Rovo|Rovo]] 04:47, 2 October 2007 (CEST)
 +
 +
== Reply (4) ==
 +
So we are coming closer.
 +
 +
# the '\n' should be at the very end of the line where you define your resultsheader. Otherwise the first line of your output will not start in a new line and the wiki parser will not recognize the "== ... ==" pattern as a chapter headline.
 +
# I suspect that you have a syntax error in your LocalSettings (maybe you forgot a semicolon or a bracket in some line above 161.
 +
# The fact that the most primitive DPL query ("titlematch=A%") leads to an error indicates that there must be a more fundamental problem with your wiki (outside DPL).
 +
 +
You should:
 +
# comment out the requireOnce for DPL and check if your wiki runs stably.
 +
# make sure that you have the latest DPL revision. You only need the three files in subdirectory DynamicPageList.
 +
# uncomment the DPL requireOnce and check that pages which do NOT use DPL behave normal.
 +
# try a DPL statement with a wrong parameter, eg. "dummy=nonsense". You should get an error message from DPL. The trick with this that you only touch 3% of the whole DPL source code if there is an error in the parameters.
 +
# then you can try your query again and see what happens.
 +
 +
Then you should leave a message here again. (Is your wiki online available?)
 +
 +
:[[User:Gero|Gero]] 16:50, 2 October 2007 (CEST)
 +
 +
== Reply (5) ==
 +
 +
# I have created a new barebones Localsettings.php. The wiki loads fine. I then added the DPL query
 +
<nowiki>
 +
<DPL>
 +
  titlematch = A%
 +
</DPL>
 +
</nowiki>
 +
 +
# I am using 1.4.5 DPL
 +
 +
# Without the requireonce to DPL in localsettings, everything runs fine. I have then run with only a requireonce to DPL, and no other extensions. The article with the query then does not work.
 +
 +
# I run a different skin than monobook, but I have been testing it in monobook, and the same error.
 +
 +
# When I try a DPL statement with only "dummy=nonsense", I get
 +
 +
<nowiki>
 +
%DPL-1.4.5-WARNING: Unknown parameter 'dummy' is ignored. Help: available parameters: addcategories, addpagecounter, addpagesize, addeditdate, addfirstcategorydate, addpagetoucheddate, adduser, addauthor, addlasteditor, allowcachedresults, userdateformat, goal, category, categoriesminmax, offset, count, randomcount, distinct, columns, rows, rowsize, rowcolformat, debug, reset, eliminate, headingmode, headingcount, hitemattr, hlistattr, includepage, ignorecase, includesubpages, includematch, includenotmatch, inlinetext, includemaxlength, itemattr, listseparators, listattr, linksfrom, linksto, notlinksto, uses, notuses, createdby, notcreatedby, modifiedby, notmodifiedby, lastmodifiedby, notlastmodifiedby, mode, escapelinks, namespace, notcategory, notnamespace, title, titlematch, nottitlematch, order, ordercollation, ordermethod, minoredits, lastrevisionbefore, allrevisionsbefore, firstrevisionsince, allrevisionssince, noresultsheader, noresultsfooter, oneresultheader, oneresultfooter, openreferences, redirects, resultsheader, resultsfooter, secseparators, multisecseparators, dominantsection, shownamespace, replaceintitle, table, tablerow, titlemaxlength.
 +
 +
</nowiki>
 +
 +
# The wiki and article I am using to test DPL is here, [http://www.wikistock.com/wiki/Test WS Test]  .
 +
 +
I really appreciate you trying to help me solve this. Thank you.
 +
 +
--[[User:Rovo|Rovo]] 18:49, 2 October 2007 (CEST)
 +
 +
== Reply (6) ==
 +
 +
When I look at the [http://www.wikistock.com/wiki/Special:Version Version Special page] of your wiki I see a very old Version of DPL: 0.9). How can this be? You seem to have DPL scripts in the subdirectory DynamicPageList and in the root of your extensions directory. I would recommend to clean this up first. Maybe you should copy extensions to extensions.old and then have just the DPL subdirectory within extensions. Although I am not sure that this may cause the problem ... (because the correct DPL version shows up in the error message.)
 +
 +
You may also have a problem in your permission setting. Line 1112 of Title.php contains a RunHook for permission checking. This doesn´t look like it was DPL-related, does it?
 +
 +
:[[User:Gero|Gero]] 10:39, 3 October 2007 (CEST)
 +
 +
:: At some point late last night, I decided to just try and return to the older version of DPL. For some reason that did not work out as well, which led me to believe there is something wrong with my Title.php. I think that is weird, because I've never modified the file in any way. It's just as it was when I downloaded and installed 1.11 MW . Whereever the hiccup is, I've resolved to just use a special:SpecialPages listing of the namespace instead of using DPL. It will have to suffice for now. I greatly appreciate all your efforts in looking into this problem.
 +
 +
--[[User:Rovo|Rovo]] 18:38, 3 October 2007 (CEST)
 +
 +
Wish you good luck! You may run into similar problems when installing other extensions. Maybe you want to do a final check of your LocalSettings regarding ''permissions'' as the offending line in Title.php invokes a callback which seams to check rights (I have no idea what that really does).
 +
 +
Cheers, [[User:Gero|Gero]] 22:09, 3 October 2007 (CEST)
 +
 +
== New Message ==
 +
I’ve had the same problem as Rovo.  Here’s some background on my experience:
 +
 +
* I get the same message, ''Notice: Undefined variable: result in /home/mywiki/public_html/includes/Title.php on line 1112''.  This message is typically repeated 4 or 5 times and the skin is screwed up as well.  The results of the query display the correct data.
 +
 +
* The conflict only appears on pages that include DPL statements.
 +
 +
* I don’t believe that there is a problem with my query statements.  I have cut and pasted each of the statements from DPL’s page [http://semeb.com/dpldemo/index.php?title=Example_3 Example 3] and get similar errors.  Each of the different query statements causes a different number of repetitions of the “Title.php on line 1112” notice.  I haven’t taken the time to count, but it when I tried
 +
 +
<pre><nowiki>
 +
{{#dpl:
 +
  |namespace=Image
 +
  |format=«gallery»,%PAGE%¦%NR%. %TITLE%\n,,«/gallery»
 +
}}
 +
</nowiki></pre>
 +
 +
it appears that the “Title.php on line 1112” notice is repeated as many times as there are images.
 +
 +
* I have not been able to utilize DPL without conflicts regardless of versions.  However, I do not know if the conflicts have been related.
 +
** I initially tried to use DPL 0.9.9 with Mediawiki 1.8.2.  At that time I would get a message about an undefined variable in Parser.php.  See [http://bugzilla.wikimedia.org/show_bug.cgi?id=9187 bugzilla].
 +
** I have since installed Mediawiki 1.9.3 and MediaWiki 1.11.0.  Following both upgrades I continued to received a conflict with DPL 0.9.9, but I did not keep track of what the specific message was.
 +
** I am currently experiencing the “Title.php on line 1112” notice with MediaWiki 1.11.0 and DPL 1.6.0. 
 +
 +
* I have tested DPL with a default LocalSettings.php file and the error persists.
 +
 +
* Changing skins does not make the problem go away.  However, the “Title.php on line 1112” notice is repeated a different number of times for different skins.
 +
 +
 +
Thanks.  [[User:Furboy2|Furboy2]]
 +
 +
----
 +
Try the following:
 +
* shutdown the web server / reboot your machine OR touch the file (i.e. update the timer stamp) so that the server must recompile
 +
* make sure that there are only THREE files in the DPL directory.
 +
 +
A safe way would also be to use a new root directory for your mediawiki.
 +
 +
The only reason for your trouble I can think of lies in reminscents from older versions of DPL which are still held in your server´s cache ...
 +
 +
[[User:Gero|Gero]] 21:03, 7 December 2007 (CET)
 +
----
 +
Thanks for your reply, Gero.
 +
 +
I'll need to get with my hosting company to try the reboot.
 +
 +
I do have only three files in the DPL directory. In my previous DPL installation, the files (which I have deleted) had been directly in the /extensions directory, although I don't know whether the previous file location affects what's hanging around in the cache.
 +
 +
I recognize that at DPL's wiki you are using MediaWiki 1.9.0.  Have you or the other developers had an opportunity to test DPL on MediaWiki 1.11.0?  It doesn't appear that Rovo, above, was able to resolve his/her issue.  I've also visited a handful of sites using DPL and couldn't find one using MediaWiki 1.11.0.  Perhaps there is a universal conflict in the new MediaWiki 1.11.0 code.
 +
 +
Thanks, [[User:Furboy2|Furboy2]] 19:04, 11 December 2007 (CET)
 +
 +
=== Reply regarding MW 1.11 ===
 +
I am using MW 1.11 successfully with DPL since more than a month now on my local PC. As far as I am aware of there are NO problems.
 +
I plan to migrate dpldemo to 1.11 soon.
 +
:[[User:Gero|Gero]] 21:36, 11 December 2007 (CET)

Latest revision as of 21:36, 11 December 2007

Description: Notice: Undefined variable:
Extension / Version: DPL   /   1.4.5
Type / Status: Bug   /   closed

Problem

I've upgraded to 1.11, and started getting this error message

Notice: Undefined variable: result in /home/wikistoc/public_html/wiki/includes/Title.php on line 1112

--Rovo 23:12, 30 September 2007 (CEST)

Answer

We need more information. What is your DPL query? Can you enable the full error messages and give the full stack trace?

--Gero 23:52, 30 September 2007 (CEST)

Reply

This is my query 

<DPL>
 resultsheader= === A ===
 namespace = Terms
 shownamespace = false
 titlematch = A%
 </DPL>

I did this for each letter through the alphabet. The Terms namespace is set to 100. I'm not sure how to enable the full error messages or give a full stack trace, but I will try to figure it out. Thank you.

--Rovo 03:11, 1 October 2007 (CEST)

I cannot figure out how to turn on the full error message. --24.250.201.191 14:37, 1 October 2007 (CEST)

Reply (2)

  1. You should put a '\n' behind the resultsheader, otherwise you will not get a heading.
  2. Does the error depend on the namespace?
  3. Does it work for one single letter? How do you do the "loop" for each letter? (If here is another extension involved, that could be the reason, too)
  4. For full error information you must set $wgShowExceptionDetails = true; in the LocalSettings.php

Reply (3)

  1. I'm not sure where to put the '\n' behind the resultsheader? At the very end, or just at the end of the word header, instead of an = ?
  2. I've removed the namespace and shownamespace from the query, so it just looks for titlematch = A%
  3. I am testing it on a page for a single letter only, A . It used to be set for each letter, just repeating the query for each.
  4. I set the full error information, after turning off all other installed extensions, and only received the error,

Parse error: parse error, unexpected T_REQUIRE_ONCE in /home/wikistoc/public_html/wiki/LocalSettings.php on line 161

I should add, line 161 is where the require call to DynamicPageList.php is.

--Rovo 19:09, 1 October 2007 (CEST)

I have tried a streamlined query and still the same error, 

<DPL>
  titlematch = A%
 </DPL>

--Rovo 04:47, 2 October 2007 (CEST)

Reply (4)

So we are coming closer.

  1. the '\n' should be at the very end of the line where you define your resultsheader. Otherwise the first line of your output will not start in a new line and the wiki parser will not recognize the "== ... ==" pattern as a chapter headline.
  2. I suspect that you have a syntax error in your LocalSettings (maybe you forgot a semicolon or a bracket in some line above 161.
  3. The fact that the most primitive DPL query ("titlematch=A%") leads to an error indicates that there must be a more fundamental problem with your wiki (outside DPL).

You should:

  1. comment out the requireOnce for DPL and check if your wiki runs stably.
  2. make sure that you have the latest DPL revision. You only need the three files in subdirectory DynamicPageList.
  3. uncomment the DPL requireOnce and check that pages which do NOT use DPL behave normal.
  4. try a DPL statement with a wrong parameter, eg. "dummy=nonsense". You should get an error message from DPL. The trick with this that you only touch 3% of the whole DPL source code if there is an error in the parameters.
  5. then you can try your query again and see what happens.

Then you should leave a message here again. (Is your wiki online available?)

Gero 16:50, 2 October 2007 (CEST)

Reply (5)

  1. I have created a new barebones Localsettings.php. The wiki loads fine. I then added the DPL query

<DPL> titlematch = A% </DPL>

  1. I am using 1.4.5 DPL
  1. Without the requireonce to DPL in localsettings, everything runs fine. I have then run with only a requireonce to DPL, and no other extensions. The article with the query then does not work.
  1. I run a different skin than monobook, but I have been testing it in monobook, and the same error.
  1. When I try a DPL statement with only "dummy=nonsense", I get

%DPL-1.4.5-WARNING: Unknown parameter 'dummy' is ignored. Help: available parameters: addcategories, addpagecounter, addpagesize, addeditdate, addfirstcategorydate, addpagetoucheddate, adduser, addauthor, addlasteditor, allowcachedresults, userdateformat, goal, category, categoriesminmax, offset, count, randomcount, distinct, columns, rows, rowsize, rowcolformat, debug, reset, eliminate, headingmode, headingcount, hitemattr, hlistattr, includepage, ignorecase, includesubpages, includematch, includenotmatch, inlinetext, includemaxlength, itemattr, listseparators, listattr, linksfrom, linksto, notlinksto, uses, notuses, createdby, notcreatedby, modifiedby, notmodifiedby, lastmodifiedby, notlastmodifiedby, mode, escapelinks, namespace, notcategory, notnamespace, title, titlematch, nottitlematch, order, ordercollation, ordermethod, minoredits, lastrevisionbefore, allrevisionsbefore, firstrevisionsince, allrevisionssince, noresultsheader, noresultsfooter, oneresultheader, oneresultfooter, openreferences, redirects, resultsheader, resultsfooter, secseparators, multisecseparators, dominantsection, shownamespace, replaceintitle, table, tablerow, titlemaxlength.

  1. The wiki and article I am using to test DPL is here, WS Test .

I really appreciate you trying to help me solve this. Thank you.

--Rovo 18:49, 2 October 2007 (CEST)

Reply (6)

When I look at the Version Special page of your wiki I see a very old Version of DPL: 0.9). How can this be? You seem to have DPL scripts in the subdirectory DynamicPageList and in the root of your extensions directory. I would recommend to clean this up first. Maybe you should copy extensions to extensions.old and then have just the DPL subdirectory within extensions. Although I am not sure that this may cause the problem ... (because the correct DPL version shows up in the error message.)

You may also have a problem in your permission setting. Line 1112 of Title.php contains a RunHook for permission checking. This doesn´t look like it was DPL-related, does it?

Gero 10:39, 3 October 2007 (CEST)
At some point late last night, I decided to just try and return to the older version of DPL. For some reason that did not work out as well, which led me to believe there is something wrong with my Title.php. I think that is weird, because I've never modified the file in any way. It's just as it was when I downloaded and installed 1.11 MW . Whereever the hiccup is, I've resolved to just use a special:SpecialPages listing of the namespace instead of using DPL. It will have to suffice for now. I greatly appreciate all your efforts in looking into this problem.

--Rovo 18:38, 3 October 2007 (CEST)

Wish you good luck! You may run into similar problems when installing other extensions. Maybe you want to do a final check of your LocalSettings regarding permissions as the offending line in Title.php invokes a callback which seams to check rights (I have no idea what that really does).

Cheers, Gero 22:09, 3 October 2007 (CEST)

New Message

I’ve had the same problem as Rovo. Here’s some background on my experience:

  • I get the same message, Notice: Undefined variable: result in /home/mywiki/public_html/includes/Title.php on line 1112. This message is typically repeated 4 or 5 times and the skin is screwed up as well. The results of the query display the correct data.
  • The conflict only appears on pages that include DPL statements.
  • I don’t believe that there is a problem with my query statements. I have cut and pasted each of the statements from DPL’s page Example 3 and get similar errors. Each of the different query statements causes a different number of repetitions of the “Title.php on line 1112” notice. I haven’t taken the time to count, but it when I tried
{{#dpl:
   |namespace=Image
   |format=«gallery»,%PAGE%¦%NR%. %TITLE%\n,,«/gallery»
}}

it appears that the “Title.php on line 1112” notice is repeated as many times as there are images.

  • I have not been able to utilize DPL without conflicts regardless of versions. However, I do not know if the conflicts have been related.
    • I initially tried to use DPL 0.9.9 with Mediawiki 1.8.2. At that time I would get a message about an undefined variable in Parser.php. See bugzilla.
    • I have since installed Mediawiki 1.9.3 and MediaWiki 1.11.0. Following both upgrades I continued to received a conflict with DPL 0.9.9, but I did not keep track of what the specific message was.
    • I am currently experiencing the “Title.php on line 1112” notice with MediaWiki 1.11.0 and DPL 1.6.0.
  • I have tested DPL with a default LocalSettings.php file and the error persists.
  • Changing skins does not make the problem go away. However, the “Title.php on line 1112” notice is repeated a different number of times for different skins.


Thanks. Furboy2

Try the following:

  • shutdown the web server / reboot your machine OR touch the file (i.e. update the timer stamp) so that the server must recompile
  • make sure that there are only THREE files in the DPL directory.

A safe way would also be to use a new root directory for your mediawiki.

The only reason for your trouble I can think of lies in reminscents from older versions of DPL which are still held in your server´s cache ...

Gero 21:03, 7 December 2007 (CET)

Thanks for your reply, Gero.

I'll need to get with my hosting company to try the reboot.

I do have only three files in the DPL directory. In my previous DPL installation, the files (which I have deleted) had been directly in the /extensions directory, although I don't know whether the previous file location affects what's hanging around in the cache.

I recognize that at DPL's wiki you are using MediaWiki 1.9.0. Have you or the other developers had an opportunity to test DPL on MediaWiki 1.11.0? It doesn't appear that Rovo, above, was able to resolve his/her issue. I've also visited a handful of sites using DPL and couldn't find one using MediaWiki 1.11.0. Perhaps there is a universal conflict in the new MediaWiki 1.11.0 code.

Thanks, Furboy2 19:04, 11 December 2007 (CET)

Reply regarding MW 1.11

I am using MW 1.11 successfully with DPL since more than a month now on my local PC. As far as I am aware of there are NO problems. I plan to migrate dpldemo to 1.11 soon.

Gero 21:36, 11 December 2007 (CET)
Retrieved from "http://followthescore.org/dpldemo/index.php?title=Issue:Upgraded_to_1.11_Notice:_Undefined_variable&oldid=8863"