Last modified: 2010-05-15 15:37:29 UTC
The SpecialPage class uses a $mFile variable with just filename and path based in includes/. This makes adding SpecialPage objects with files placed in other locations, e.g. extensions/, unintuitive. $mFile or the SpecialPage constructor should be changed so that when creating a SpecialPage object with the $file parameter, $file is relative to the wiki root, not includes/.
You should use the build in method: SpecialPage::addPage( new YourSpecialPageClass );
http://meta.wikimedia.org/wiki/Writing_a_new_special_page has an excellent set of tips for first-time MediaWiki hackers, which might be of use.
>> 1 The built-in method looks for includes/Special<title>.php. >> 2 "To add your own extension page, you will need to add two pages to the MediaWiki installation." It then goes on to mention one of them is placed in the includes directory. When you add special pages, you're extending the base setup, and it should go in the extensions directory. You should not have to worry about sorting out custom things in includes/ every time you upgrade.
How bizarre that the rest of us can create self-contained special pages which exist in a single file. Check the extensions module in CVS for some examples.
So you probably mean like the BoardVote extension. It extends SpecialPage, adds its own constructor, has its own execute method, and adds its own class to the page list. All that to accomplish what should be default behavior. I could create self-contained special pages before I posted this bug in the first place. The point is that it was too much work for something which is a basic task and should be simple.
I'm not sure I understand what you mean by, "the default behaviour". To my mind, being able to extend a standard class ensures that special pages can be authored to be consistent with the rest of MediaWiki, and it encourages cleaner and neater code. The whole point of extensions is to be clean and self-contained. They can extend (as indicated by the name) the base functionality of the parser, or can provide special pages or other useful features using one of the multitude of hooks added to the software. To the original point: The SpecialPage::mFile member is irrelevant, for the most part, when dealing with a custom special page in an extension, since it's added in a different manner altogether.
