Author: magnusrk+wiki
Description:
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/.
Version: 1.5.x
Severity: trivial
You should use the build in method:
SpecialPage::addPage( new YourSpecialPageClass );
robchur wrote:
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.
magnusrk+wiki wrote:
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.
robchur wrote:
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.
magnusrk+wiki wrote:
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.
robchur wrote:
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.