Wikimedia Bugzilla is closed!

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.