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?