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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
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