Last modified: 2010-05-15 15:37:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4551, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2551 - Special Page constructor doesn't include file path
Special Page constructor doesn't include file path
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.5.x
All All
: Normal trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-27 13:49 UTC by Dashiva
Modified: 2010-05-15 15:37 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dashiva 2005-06-27 13:49:14 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/.
Comment 1 Antoine "hashar" Musso (WMF) 2006-01-17 20:26:39 UTC
You should use the build in method:

SpecialPage::addPage( new YourSpecialPageClass );
Comment 2 Rob Church 2006-01-17 23:40:08 UTC
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.
Comment 3 Dashiva 2006-01-18 08:05:42 UTC
>> 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.
Comment 4 Rob Church 2006-01-18 19:28:49 UTC
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.
Comment 5 Dashiva 2006-01-19 12:40:26 UTC
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.
Comment 6 Rob Church 2006-01-20 07:54:51 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links