Yesterday I upgraded my (tiny) 1.4.9 installation to 1.5rc4, which was a relatively trouble-free affair (I used the web install with the same values as on the original install, instead of running "php update.php").
I spent quite a while trying to determine how to set up the navigation toolbar; the only reference to it is in RELEASE-NOTES, and erroneously mentions MediaWiki:navbar. Fortunately, after a (long) while I discovered the MediaWiki_FAQ on the web, which nicely explains the whole issue. Not a big deal.
More puzzling was the fact that I was getting errors about unknown variables while loading an extension. From LocalSettings.php I load extensions/MyExtensions.php, which starts with the following code:
function __autoload($class_name) { require_once($class_name . '.php'); }
require_once('MyFunctions.php');
SpecialPage::addPage(new UnlistedSpecialPage('MyExtension'));
For some reason, that used to work OK on 1.4.9, but on 1.5rc4 I was forced to add
require_once('SpecialPage.php');
before the call to addPage(). Is that expected?
Now, the only thing I miss is a way to customize $wgBookstoreListEn which doesn't involve hacking languages/language.php (because I must remember to update it every time I upgrade, which is a PITA). Setting it in LocalSettings.php does not work. Any ideas?
Juanma Barranquero wrote:
Yesterday I upgraded my (tiny) 1.4.9 installation to 1.5rc4, which was a relatively trouble-free affair (I used the web install with the same values as on the original install, instead of running "php update.php").
I spent quite a while trying to determine how to set up the navigation toolbar; the only reference to it is in RELEASE-NOTES, and erroneously mentions MediaWiki:navbar. Fortunately, after a (long) while I discovered the MediaWiki_FAQ on the web, which nicely explains the whole issue. Not a big deal.
More puzzling was the fact that I was getting errors about unknown variables while loading an extension. From LocalSettings.php I load extensions/MyExtensions.php, which starts with the following code:
function __autoload($class_name) { require_once($class_name . '.php'); }
require_once('MyFunctions.php');
SpecialPage::addPage(new UnlistedSpecialPage('MyExtension'));
For some reason, that used to work OK on 1.4.9, but on 1.5rc4 I was forced to add
require_once('SpecialPage.php');
before the call to addPage(). Is that expected?
Ug. Whoever wrote that extension should remove it.
Now, the only thing I miss is a way to customize $wgBookstoreListEn which doesn't involve hacking languages/language.php (because I must remember to update it every time I upgrade, which is a PITA). Setting it in LocalSettings.php does not work. Any ideas?
Write an extension function to change it after initialization.
-- Jamie ------------------------------------------------------------------- http://endeavour.zapto.org/astro73/ Thank you to JosephM for inviting me to Gmail! Have lots of invites. Gmail now has 2GB.
On 9/16/05, Jamie Bliss astronouth7303@gmail.com wrote:
Ug. Whoever wrote that extension should remove it.
I don't understand. *I* wrote MyExtension (not the real name, of course). It adds a special page. Before, it just worked. Now, I have to pre-load SpecialPage.php. Why the difference? Did something change in the way modules are loaded, or in the paths used for it?
Write an extension function to change it after initialization.
That's a good idea. I'll try it.
Juanma Barranquero wrote:
On 9/16/05, Jamie Bliss astronouth7303@gmail.com wrote:
Ug. Whoever wrote that extension should remove it.
I don't understand. *I* wrote MyExtension (not the real name, of course). It adds a special page. Before, it just worked. Now, I have to pre-load SpecialPage.php. Why the difference? Did something change in the way modules are loaded, or in the paths used for it?
Basically, it will try to load the file if the class doesn't exist, based on the class name. IMHO, this is fine when you write your own stuff and you control all the classes and file names. But in MediaWiki, file names and class names don't always match.
The way it is done sometimes is to wrap the class definition and other initialization bits in an extension function. (There is an example of this at extensions/BoardVote/BoardVote.php in CVS. http://cvs.sourceforge.net/viewcvs.py/wikipedia/extensions/BoardVote/BoardVote.php)
-- Jamie ------------------------------------------------------------------- http://endeavour.zapto.org/astro73/ Thank you to JosephM for inviting me to Gmail! Have lots of invites. Gmail now has 2GB.
On 9/17/05, Jamie Bliss astronouth7303@gmail.com wrote:
Basically, it will try to load the file if the class doesn't exist, based on the class name.
If you're referring to the __autoload stuff, I know. I wrote that bit of code (inspired in something I read in a document, but I understand what it is supposed to do; autoloading is not nine o'clock news, after all).
IMHO, this is fine when you write your own stuff and you control all the classes and file names. But in MediaWiki, file names and class names don't always match.
Fine. But SpecialPage is loaded from a file called SpecialPage.php...
The way it is done sometimes is to wrap the class definition and other initialization bits in an extension function. (There is an example of this at extensions/BoardVote/BoardVote.php in CVS.
OK, and I do that with my extensions. Which does not answer my question. Let me recapitulate:
- SpecialPage.php is MediaWiki's code, not mine
- The file is called SpecialPage.php, and it's in includes/
- The class inside is called SpecialPage
- includes/ is in include_path (set in LocalSettings.php)
- even if it weren't, I've got an autoload to load a ClassName.php from ClassName
- On MediaWiki 1.4.9 this code worked:
SpecialPage::addPage(new UnlistedSpecialPage('SpecialMyExt');
- On MediaWiki 1.5rc4, it does not work unless I do, *before*:
require_once('SpecialPage.php')
The problem is *not* that SpecialMyExt is not being loaded. The problem is that loading of SpecialPage.php complains about a bunch of variables being undefined: $wgUseValidation, $wgDisableCounters, $wgDisableInternalSearch, $wgEmailAuthentication. At this point, all special pages cease to work.
Now, these variables are defined in includes/DefaultSettings.php, which is included from LocalSettings.php way before the SpecialPage::addPage() call.
So, the question remains: why the call to SpecialPage::addPage() worked on 1.4.9, and suddenly does not work on 1.5rc4 unless I preload SpecialPage.php?
Juanma Barranquero wrote:
[snip] The problem is *not* that SpecialMyExt is not being loaded. The problem is that loading of SpecialPage.php complains about a bunch of variables being undefined: $wgUseValidation, $wgDisableCounters, $wgDisableInternalSearch, $wgEmailAuthentication. At this point, all special pages cease to work.
When you upgraded, you upgraded all the files, correct?
Now, these variables are defined in includes/DefaultSettings.php, which is included from LocalSettings.php way before the SpecialPage::addPage() call.
So, the question remains: why the call to SpecialPage::addPage() worked on 1.4.9, and suddenly does not work on 1.5rc4 unless I preload SpecialPage.php?
At this point, it sounds a little more intricate than can be easily discussed on a mailing list. If you can paste the code somewhere, maybe we (I) can help you.
(Of course, if someone else knows something about this, feel free to jump in.)
-- Jamie ------------------------------------------------------------------- http://endeavour.zapto.org/astro73/ Thank you to JosephM for inviting me to Gmail! Have lots of invites. Gmail now has 2GB.
On 9/17/05, Jamie Bliss astronouth7303@gmail.com wrote:
At this point, it sounds a little more intricate than can be easily discussed on a mailing list. If you can paste the code somewhere, maybe we (I) can help you.
It's not really intricate. Please follow the example, which uses two files and less than 15 lines of code.
(Using MediaWiki 1.5rc4) add
include('extensions/MyExtensions.php');
at the end of your LocalSettings.php. The file extensions/MyExtensions.php contains this:
<?php function __autoload($class_name) { require_once($class_name . '.php'); } SpecialPage::addPage(new UnlistedSpecialPage('MyTest')); ?>
and extensions/SpecialMyTest.php contains this:
<?php function wfSpecialMyTest() { global $wgOut; $wgOut->setPageTitle('My Test'); $wgOut->addHtml(''); } ?>
Loading MediaWiki produces a warning about undefined variables on SpecialPage.php. Now add this to extensions/MyExtensions.php:
require_once('SpecialPage.php');
*before* the call to SpecialPage::addPage(). Now MediaWiki loads without any warnings and runs just fine.
In MediaWiki 1.4.X, loading SpecialPage.php before the call was not needed. Why the difference?
On 9/16/05, Jamie Bliss astronouth7303@gmail.com wrote:
Juanma Barranquero wrote:
Now, the only thing I miss is a way to customize $wgBookstoreListEn which doesn't involve hacking languages/language.php (because I must remember to update it every time I upgrade, which is a PITA). Setting it in LocalSettings.php does not work. Any ideas?
Write an extension function to change it after initialization.
I've done that, and it works beautifully, thanks.
Still, I'm a bit puzzled. Surely $wgBookstoreList* is something prone to be customized in non-Wikipedia installations of MediaWiki. What's the point of having a getter getBookstoreList() and not a setter setBookstoreList()?
Juanma Barranquero wrote:
Still, I'm a bit puzzled. Surely $wgBookstoreList* is something prone to be customized in non-Wikipedia installations of MediaWiki. What's the point of having a getter getBookstoreList() and not a setter setBookstoreList()?
The list is just a default when there's not a wiki page for the books list defined; customizations are meant to be done in the wiki.
-- brion vibber (brion @ pobox.com)
On 9/20/05, Brion Vibber brion@pobox.com wrote:
The list is just a default when there's not a wiki page for the books list defined; customizations are meant to be done in the wiki.
Aha, that's the datum I was missing.
AFAICS, MediaWiki:Booksources contains the name of a page in the {{ns:4}} namespace, which is used verbatim, except that MAGICNUMBER is substituted by the ISBN.
Nice, though not the most documented of features :)
Juanma Barranquero wrote:
AFAICS, MediaWiki:Booksources contains the name of a page in the {{ns:4}} namespace, which is used verbatim, except that MAGICNUMBER is substituted by the ISBN.
Nice, though not the most documented of features :)
It predates the editable MediaWiki: messages, so yeah it's a little ugly. Could use some cleanup.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org