Manual talk:Special pages

(Redirected from Talk:Writing a new special page)
Latest comment: 8 months ago by GregRundlett in topic Broken template for class documentation
The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Fixing lt and gt (< and >) on Special:SpecialPages

edit

If your Special Page's name is surrounded by < and >, it means you haven't defined a string mapping in your i18n file. Suppose you have an extension named FooBar. Your first line should be 'foobar' => 'My Foobar extension'. Here's an actual example that would live in FooBar.i18n.php:

$messages = array
(
    'en' => array
    (
        'foobar' => 'The FooBar extension',
        'thing1' => 'This is a fancy string that I can call using wfMessage()!',
    )
);

Now when you view your Special:SpecialPages index, your extension will appear as:

Special:The FooBar extension

instead of

Special:<foobar>

Rstockbower (talk) 12:56, 29 August 2012 (UTC)Reply

Outdated?

edit

I think this page has to be updated? It seems that you only need a file in the extension directory to create special page now.

An example is the Board Vote file

I have accordingly updated the word of warning section. I think the old material is for 1.4, so it's still relevant, so I'm going to try to rewrite the whole thing for 1.5. Ambush Commander 00:09, 22 December 2005 (UTC)Reply
As of 1.6.x, my PageCreateOrder extension broke and I spent some time trying to figure out why until I looked at the BoardVote extension you mentioned. I now see that the class I was defining needs to be done inside the loader function and the includes file no longer needs to be there. I've updated the documentation to reflect this. -- Suso 13:44, 5 May 2006 (UTC)Reply
Hey, Suso, are you User:216.9.137.122? (because that's the only edit I see) Ambush Commander 21:30, 5 May 2006 (UTC)Reply
Yes I am. Sorry, I must have logged out or something when I made the edit. It happens. -- Suso 22:29, 30 May 2006 (UTC)Reply

create a new special page

edit

Hello, I would like to insert forms in pages related to my wiki, which is necessary to modify in the quick template to have a special page?

a: I didn't have to change anything in the template. Try using BoardVote.php as a model for your page, put it in the extensions directory. You can put your forms in the 'execute' function as this is what gets called automatically when the special page is loaded. To get mediawiki to recognize the existence of your new page, just include it at the end of LocalSettings.php.

You probably want to read into Extending wiki markup, which lets you add arbitrary HTML to a page and is great for creating really quick extensions for creating forms. Ambush Commander 00:09, 22 December 2005 (UTC)Reply

clear title < >

edit

I can't remove the < > witch appears on both sides of the page title. First, I added a line in the $wgValidSpecialPagesFr array and then in all arrays of my language file. I read the explanation with the addMessage() function but y didn't very understand because of my bad english. Barbux 22:10, 1 October 2005 (UTC)Reply

Put $wgMessageCache->addMessages(array('page' => 'My Page Name')); into the start of your wfExampleExtension() after the globals declaration.
Failing that, create this page: MediaWiki:Yourpagename and put the name of your page there. Ambush Commander 00:09, 22 December 2005 (UTC)Reply
Had same problem. Solution was to make sure that keys in i18n file were lower-case. Happy Joe 13:59, 30 December 2008 (UTC)Reply

Had same problem, brute-forced by adding

$wgOut->setPageTitle(wfMsg('myextension'));

in execute function under wfLoadExtensionMessages... --76.8.128.114 18:59, 18 November 2009 (UTC)Reply

sysops only?

edit

ImaTard 20:06, 31 October 2005 (UTC)Reply

How would i go about making a sysops only special page? im using v1.5

a:I thought it might help to show what I have in my code at the beginning of my execute function:

               if (! $wgUser->isBureaucrat() && ! $wgUser->isDeveloper() ){
                       $wgOut->errorpage( "bureaucrattitle", "bureaucrattext" );
                       return;
               }

This code only allows admins to use the page. Note that i have only tested this on v1.4.6 though.

This is a good idea for a section on the page, but it's fairly obvious if you just look at some of the code. Those functions are deprecated, you can use: $this->isAllowed( 'protect' );. Ambush Commander 00:12, 22 December 2005 (UTC)Reply
Extra note: the code given earlier does not make the page sysops only. Ambush Commander 00:13, 22 December 2005 (UTC)Reply

I'm using 1.8, and i'm having problems as well...Here's what i have in my function:

SpecialPage::addPage(new SpecialPage('ArchiveNews', 'sysop', true, 'ArchiveNews', false));

I thought that passing "sysop" as the second parameter would only allow sysops to see the page. But, when i do that and go to the page, I get:

Permission error
You are not allowed to execute the action you have requested.

I am a sysop, so i can't figure out why it wouldn't work...is this by chance deprecated? I've tried everything...sysop, admin, administrator, etc, and nothing works. The only thing that made any difference, was when i set it to "bot" just for fun, and I got a different message, stating that I was not in the group "bots". Any help would be appreciated. --Duke33 22:31, 20 December 2006 (UTC)Reply

The second parameter of SpecialPage's constructor is the right needed to view the page, not the group. Since (by default at least) a bureaucrat's only right is userrights, pass "userrights" as the second parameter to limit the page to bureaucrats. To limit the page to sysops, consider why -- because sysops can delete pages? Or upload files? A full list of default user group/rights settings is in DefaultSettings.php. 23:18, 22 May 2007 (UTC)

Modification needed for 1.6

edit

I just made a special page using the example found on this page. But, apparently on 1.6 you need to add this to the execute(); function.

 $wgOut->setPagetitle( wfMsg( 'messagename' ) );

--Phroziac (talk) 20:34, 8 November 2005 (UTC)Reply

This is not necessary. Read about how MediaWiki can be used to dynamically load extensions and their functions. Ambush Commander 00:09, 22 December 2005 (UTC)Reply

Revert to previous version

edit

In this edit User:Slanted reverted the new set of instructions to a pre-1.5 state. The edit was marked minor and had no edit summary, so I chose to revert him before posting an inquiry on his talk page. So... discussion? Ambush Commander 02:52, 5 January 2006 (UTC)Reply

Add setHeaders() to example?

edit

The code in SpecialPage.php says you should call setHeaders() in your execute function. This turns out to be necessary to set the window title and other stuff (Thanks to Michael on Wikitech-l for pointing this out). Shouldn't we add something like the following to the example on this page?

$this->setHeaders(); // call this method of the super class to set the window title

--Jmcneil86043 19:09, 7 January 2006 (UTC)Reply

SpecialPage automatically calls the function from its base method. Notice how in the code examples, I do not inherit a new class from SpecialPage. Calling this is only necessary if you overload execute() and you don't call the original. Generally, inherited classes are overkill: UnlistedSpecialPage and IncludableSpecialPage should have all the alternate functionality you need, and there probably should not be any domain logic inside the SpecialPage class (perhaps somewhat counterintuitively).
However, if you followed the instructions correctly, it should have worked. Where did you get your special page template anyway? Ambush Commander 00:01, 8 January 2006 (UTC)Reply

I based my code on BoardVote.php, which was recommended in the old code as an example (I started this code a few months ago when that doc was current). It was over-complicated for my purposes, but I am implementing a form, so it was helpful. These new docs are more simple, but It's not completely obvious how to do a form, although I guess I could figure it out with a little work. Do you recommend calling the base-class' execute method, or re-writing so I don't sub-class? I'm going to be doing several more of these, so I'd like to do this prototype correctly. Thanks, --Jmcneil86043 03:58, 8 January 2006 (UTC)Reply

The developers likely aren't in agreement about everything. After all, I am just an outside. My observations are based off the upload special page, which Vibber does say is a, and I paraphrase, piece of crap. I'll do some more research on the other standard special pages. I think that this simply way is a lot better though.
Regarding your question about rewriting versus calling the base class's execute method, you can't call the base class's execute method because it will go off and call the function anyway (even if it doesn't exist). You will have to rewrite it, or give it a dud function. Not that you'd want to: just put all the logic inside the function that it calls. Do you understand that idea?
Regarding the creation of forms, I do need to add some documentation about WebRequest. I'm concerned, however, that the page is getting a bit long. Ambush Commander 00:36, 9 January 2006 (UTC)Reply

Passing Parameters to a Special Page?

edit

Is there any way to pass parameters to a special page? The preceding unsigned comment was added by Behrang Amini (talk • contribs) .

Yes, see "Special Parameters" on article page
84.137.220.251 14:12, 2 March 2006 (UTC)Reply


How about calling SpecialPage::executePath in the php code. How can I pass parameters to the page? Nazly.elshazly 09:35, 17 January 2007 (UTC)Reply

Special:Example

edit

Special:Example is dead. The preceding unsigned comment was added by 80.185.25.241 (talk • contribs) .

Of course. There's no special page by the name of Example on this wiki. Ambush Commander 21:46, 18 January 2006 (UTC)Reply

Special Characters in $wgMessageCache->addMessages

edit

Hi, how is it possible to put german umlauts in $wgMessageCache->addMessages? (&ouml; or &#246; don't work)
84.137.220.251 14:10, 2 March 2006 (UTC)Reply

I suppose MediaWiki expects pure text. I recommend using $string = 'needsumlat' . chr(246) . 'textafterumlat';. Remember, you can always edit the corresponding system message if you don't want to put special characters in the source code. Ambush Commander 22:38, 3 March 2006 (UTC)Reply
> Remember, you can always edit the corresponding system message if you don't want to put special characters in the source code.
That's a splendid Idea. I'm going to do it like that, thanks!
By the way, I tried "chr(246)" and it didn'd work either (allways get a question mark instead of the special character).
Otterstedt 21:22, 4 March 2006 (UTC)Reply
Hmm... that's interesting. Probably 246 is the incorrect number (it's in decimal, not hex, and remember, it has to be UTF-8 encoded). I'll have to look into that (or a developer, in their infinite wisdom, will give us the answer). Glad you resolved your problem though. Ambush Commander 23:20, 4 March 2006 (UTC)Reply
I'm getting a little bit annoyed with not finding information on how to actually achieve this. I'm writing an extension with finnish texts. Nothing so far has been displayed correctly. Including the above tip. And the tip about being able to edit the messages Special:Allmessages page doesn't work either for some reason. In my extensions/SpecialDigitemp.php I have this
$wgMessageCache->addMessages(array('digitemp' => 'Lämpötila'));
The message name and the message itself are present in the Special:Allmessages page, but when trying to edit the message I get a page saying that the page doesn't exist. The link on the Special:Allmessages page for the word digitemp is
http://xxx/wiki/index.php?title=MediaWiki:Digitemp&action=edit when for other texts it's
http://xxx/wiki/index.php/MediaWiki:Diff
So what's the deal? And how to get ä's and ö's to work? The preceding unsigned comment was added by 193.167.88.25 (talk • contribs) .
You need to use the &#nn; (HTML Unicode format) encoding when hard coding messages. Nn is equivalent to the decimal number representing the character. For example:
wgOut->HTML('L&#138;mp&#154;tila');
When using messageCache you could use php's utf8_encode() function to convert your strings to UTF-8 like in the following:
$wgMessageCache->addMessages(array('digitemp' => utf8_encode('Lämpötila')));
Hope this helps. The preceding unsigned comment was added by 213.186.252.201 (talk • contribs) .

The system messages aren't supposed to exist. Here's the thing: as an aide to you, the MediaWiki installer automatically populates the core set of system messages. Most extensions don't do so. Just create the page and it will work as normal. I strongly discourage non-ASCII characters in source code, just because of encoding issues (if you're using the wrong encoding, they'll show up weird in the source (unlikely, since Latin-1 is the most widely used character set (but still possible, esp. for non-European languages))). Ambush Commander 23:09, 31 March 2006 (UTC)Reply

Modifying permissions for existing special pages

edit

An anon posted this. I don't agree with it's methodology, but the main reason it's not appropriate for this article is that it has nothing to do with new special pages. Just old ones. Anyone know of a more appropriate place to put it? Ambush Commander 04:18, 30 March 2006 (UTC)Reply

This was my post. I postet it because I was looking for that kind of solution for preventing access for some hours in the documentation in here before I used my own brain ;-) But you are totally right, it is not about writing a new page. So I fitted it now in there, where I would have expected it at first and where it is fully logical: at Preventing_Access.

Great job. (removed text) :-D Ambush Commander 21:31, 30 March 2006 (UTC)Reply

Defining functions/classes from a function

edit

I don't think that defining classes/functions from inside a function is conceptually the cleanest way to go about doing things. In fact, the developers tend to disagree about where the extension code should go.

From this page: [1], here's an overview of what developers are doing:

  • Cite by avar - inlined inside function, extends special page class
  • Makebot by robchurch - non-conditional definition, extends special page class
  • NewestPages by robchurch - non-conditional definition, extends special page class
  • SpecialMakesysop by timstarling et al - non-conditional definition, uses generic special page class but tells special page not to load file
  • SpecialRenameuser by avar - inlined inside function, extends special page class
  • SpecialCrossNamespaceLinks by avar - inlined inside function, extends special page class
  • BoardVote by vibber - inlined inside function, extends special page class
  • SpecialFileList by Magnus Manske - inlined inside function, extends special page class
  • PurgeCache by robchurch - unconditional definition, extends special page class
  • SpecialFilePath by avar - inlined inside function, extends special page class
  • LuceneSearch by vibber - inlined inside function, extends special page class
  • OAI repository by vibber - inlined inside function, extends special page class
  • SiteMatrix by vibber - inlined inside function, extends special page class

Ambush Commander 22:23, 5 May 2006 (UTC)Reply

Egads! It seems I was barking up the wrong tree to begin with! Ambush Commander 04:27, 7 May 2006 (UTC)Reply

BoardVote example -- where is it?

edit

The article says:

If this is unclear, you might check out the BoardVote.php file in the extentions/BoardVote directory, as it does things the right way.

Great, but BoardVote.php is not in my extentions/BoardVote directory. If this is supposed to be the canonical example, how about publishing it where folks can see it -- like the extensions category here? JohanTheGhost 15:05, 20 May 2006 (UTC)Reply

I used to not endorse that statement, but it prompted me to check out a bunch of the other extensions by leading developers, and it turns out that inlining the class definition in the function is the commonly accepted way. Please see the above topic, Defining functions/classes from a function.
You can view the HEAD version of the BoardVote extension in the SVN repository. Personally, I wouldn't use it as a template since it's a bit too complicatd. — Ambush Commander(Talk) 17:27, 20 May 2006 (UTC)Reply


Question...

edit

Ok can some one explain to me why when I follow the instructions on this page I end up with a blank Special Pages page?

I'm using Fedora Core 5
MediaWiki: 1.9.3
PHP: 5.1.6 (apache2handler)
MySQL: 5.0.27

April 17 2007

add the following line in MyExtension_body.php
        # Do stuff
        $output = 'Hello World!';

Vic 21:51, 23 April 2007 (UTC)

Vic add this to MyExtension_body.php right after your <?PHP line:
error_reporting(1);
This should give you the error instead of a blank page 00:52, 25 April 2007 (UTC)


Special Page with MW Version 1.6.9

edit

Hi, I've written a special page with the proposed template and it works really fine with 1.9.3. But under V 1.6.9 I can't call that page (It is listed under Special:Version, but not at Special pages and if I call it directl it doesn't exist) :-( I googled a little bit and found that this problem exists. Do you know how to solve it?

Thanx Chris

Other Important Files?

edit

I really didn't get where I'm supposed to stick this stuff. Lets say I want to make it so that my special page does not appear in Special:Specialpages, what function exactly am I supposed to modify in the above code? Can anyone clarify please? --Nate 89.0.127.224 23:58, 1 October 2007 (UTC)Reply


Making a Special Page Printable

edit

How do I go about this? I have a special page that I created that needs to be printable. If I pass in a variable to tell the Page it should be printable is there a function that should be called in the code for that page to let the parser know to make it printable instead of using the standard display?

Thanks Will

I believe that just by printing the page, the browser will automatically figure out (using the @media print { ... } calls in the CSS) the correct way to display it for printing. 68.80.149.10 16:36, 31 October 2007 (UTC)Reply
Sorry I don't understand the above response, but I do see that if you add "&printable=yes" to the special page's URL, it will produce a printer-friendly page. I am hoping to find a way to add that to special pages' sidebar, or as a link on each special page, but so far that is a mystery. User must add the string to the URL manually. 67.101.25.82 14:01, 21 June 2011 (UTC)Reply

Cache Question

edit

Regarding caching, I was wondering how to go about doing an object cache. I assume MediaWiki abstracts the underlying cache systems (memcahed, APC, DB cache, etc), and was just wondering what class I would need to call to do some basic object caching. I can figure it out from there with the help of the code documentation, just need to be pointed at the right class ;)

Thanks, 68.80.149.10 16:34, 31 October 2007 (UTC)Reply

Special:Statistics

edit

My Special:Statistics page has a huge number (18,446,744,073,709,551,614) listed in "Excluding those, there are $2 pages that are probably legitimate content pages.". Any idea why this is? --Egingell 03:05, 8 January 2008 (UTC)Reply

Problem with SpecialPage hooks

edit

As per bugzilla:10719, extensions that subclass SpecialPage and implement their own execute() function have a couple of drawbacks. The main one being they don't fire off all the SpecialPage hooks that SpecialPage::execute() fires. Also, the subclass execute() function has to call setHeaders() and do it's own user permission checking. I added some information on all this and suggested a work around here: Manual:Special pages#The Body File. --Cneubauer 22:36, 11 February 2008 (UTC)Reply

php4

edit

This manual includes a note saying: It should be pointed out that the method used below will not work on PHP 4:. Where can I find the description on how to write a Special page-extension with Mediawiki 1.6 and PHP 4? -- JanCK 11:43, 11 April 2008 (UTC)Reply

Try an old revision of the page. [2] should probably work. --Cneubauer 12:12, 11 April 2008 (UTC)Reply

landing page

edit

I cannot find anything in the manual to create a landing page like wikipedia.org have. Can someone tell me how I can make a landing page like wikipedia's, but the only 2 differences will be that I will have a different Image and it will be a size of 800x600 pixels(i want to be able to write some text underneath the image too). I want the search box removed and replaced with a enter button and a leave button. the enter button will take people to the Main_Page and the leave button will take people to another url. I am not a professional programmer so could you explain it to me step by step. for example, open up main.php and put the code main=45435HTMLetcetc underneath the existing code on line 45 underneath 4534534head.php, then create a new file and upload it in the home directory etc etc.Ryan1414 01:37, 3 July 2008 (UTC)Reply

looking for developer to modify wiki

edit

i am looking for a developer who can code new functions into wiki. please have a look at http://www.wikinvest.com/stock/Apple_(AAPL) i want to add functions like bulls, bears and chart function to wiki. i am ready to pay for the final product.

Error message: Parse error: syntax error, unexpected $end, expecting T_FUNCTION in

edit

Hi, I am trying to write an specialpage, now i am getting this error message if i try to run the special page: "Parse error: syntax error, unexpected $end, expecting T_FUNCTION in" The error is located in the end of my body.php file.

Someone knowing this error?

Thanks Niels

Hate that PHP error - basically means you forgot to close a brace (one of these { ) somewhere in your document. Go back, check your functions, and make sure you closed each one properly. 206.231.255.81 21:10, 6 May 2009 (UTC)Reply

Problem with the setup instructions under 1.13.3

edit

I had these problems when I followed the setup instructions to the letter with 1.13.3:

  • $wgExtensionCredits version should be a number, not a string (I've fixed the page for this)
  • if I include descriptionmsg it fails for some reason (despite being defined in the i18n file)
  • if I include the $wgExtensionAliasesFiles line it fails
  • if I include $this->setHeaders() in execute it fails

for all cases it fails in the most frustrating way - no log messages of any sort, if I click on (eg) Special Pages it just ignores it and stays on the current page.

Download further down?

edit

At the " Basic special page template" section, "A working copy is available for download, see further down"

Where?
Manual:Special_pages#The Alias files - link at the bottom of that section. 142.164.181.107 20:08, 23 June 2009 (UTC)Reply


setup special page

edit

I'm trying to create a new special page on my wiki, and I must be missing something - I don't see any information here about how to access the page. I have created the four files, and put them in extensions/MyExtension. I've tried going to /Special:MyExtension and /Extension:MyExtension - the first errors, and the second is empty. Do I have to register the new page in another file somewhere? The instructions could be much clearer. 24.28.83.55 05:23, 24 July 2009 (UTC)Reply

In case someone has the same problem: yes, you do need to "register" the page in another file somewhere, in LocalSettings.php, like any other 'extension'. This was mentioned obliquely on the page, as the error output of one of the php scripts. I personally copied and pasted all the php code without reading it - I wanted to get the page working before delving into the details. I might have been less hasty, but in any case I have edited the page to be a little more clear.
This requirement may be obvious to some more experienced mediawiki users - its obvious to me in retrospect. I had this problem because I was attempting to create a "Special Page" and not an "Extension" - I did not realize that "custom Special Page" is exactly the same thing as an "Extension" - for all I knew, the software scans files in the extensions directory looking for references to the SpecialPage class. 146.6.204.46 20:28, 24 July 2009 (UTC)Reply

Wann endlich in Deutsch?

edit

Es wäre ungeheuer notwendig, wenn es diese Erläuterungen endlich auch in deutscher Sprache gäbe. So gut kann das amerikanische Englisch der Durchschnittsdeutschen nicht sein, um hier keine Fehler zu begehen.--Jens Rusch 06:49, 25 September 2009 (UTC)Reply

Make special page transcludable

edit

I can guess from the documentation availabre that there is a way of making ones SpecialPage transcludable (meaning it can be included in other pages like this: {{Special:mySpecialPage}}. However I couln't make it work for my special page. When I add the code to an article it only generates a link to the special page. No transclusion. Any ideas?

You must open source of that Special page and locate line which contains extends SpecialPage { and change that to extends IncludableSpecialPage {
However, there might be some problems with that
Manual:Special_pages#OutputPage-.3EaddWikiText.28.29
I am currently running two discussions about this :
User_talk:Wikinaut#Including_Special_pages_error_-_workaround
Help_talk:Magic_words#Username
--88.102.135.201 22:50, 19 May 2010 (UTC)Reply

There are some transcludable special pages, like Special:RecentChanges: --Diego Grez return fire 22:51, 19 May 2010 (UTC) {{Special:RecentChanges}}Reply


...containing into nowiki tag...
yes, I know. However, it works only when you want show content, but not if you want to pass it to some function

When I include template in middle of line, it stays there. but when I include special page, it breaks line and starts new one. Even though Special page gives just text without <p> and </p> (I checked it), after inclusion it appears there.. --88.102.135.201 00:26, 20 May 2010 (UTC)Reply

Hello world example (MyExtension)

edit

We should make the MyExtension example available via Special:ExtensionDistributor, perhaps renamed as HelloWorld. It'll be a good starting place for new extension developers. Tisane 05:30, 11 March 2010 (UTC)Reply

Adding tools

edit

Hi, is it possible to add links to the toolbox when my own special page is displayed? I created a dictioary as a specialpage and now need an add-buton, which should be in the toolbox on the left.--87.167.113.109 18:45, 24 June 2010 (UTC)Reply

$wgOut->setPagetitle() funktioniert nicht bei $wgOut->addWikiText()

edit

Hallo, wenn ich WikiCode ausgebe, verliert setPagetitle seine Wirkung. Ich Versuche den Inhalt einer Vorlage meines Wikis einzubinden, was natürlich problemlos funktioniert. Daraufhin erscheint mir als Titel jedoch Spezial:blabla. Liegt das an der Mediawiki Version 1.16 oder ist der Fehler allgemein bekannt? Vielen Dank für jegliche Hilfe!--87.167.95.145 12:12, 7 July 2010 (UTC)Reply

Hiding some pages causes syntax errors

edit

Via the documented syntax array( 'SpecialPage', name, right ) I can hide some pages, but if I try the same syntax on others it creates a syntax error.
e.g. "Listusers" works just fine, but if I try to block "Activeusers" it is hidden for unauthorized users, but if an authorized one tries to activate it, the syntax error below comes up:

'Listusers' => array( 'SpecialPage', 'Listusers', 'block' )
'Activeusers' => array( 'SpecialPage', 'Activeusers', 'block'),
Warning: call_user_func(wfSpecialUserrights) [function.call-user-func]: 
 First argument is expected to be a valid callback in 
 /home/bisimadm/resources.bisimulations.com/wiki/includes/SpecialPage.php on line 793

76.10.156.165 14:46, 25 February 2011 (UTC)Reply

My WORKING solution to controlling Special Pages access.

edit

I've read so many posts on sooo many sites trying to solve this issue without ever finding a solution. This wiki got me closest to what I needed for this particular installation so I figured it would be the best site for my results.

NOTE 01: Sorry if this is not proper on this wiki. Just trying to help.

NOTE 02: I am not a wiki expert. Nor am I a professional programmer. This may be an ugly solution. There is likely a much better way. After exhaustive searching for a week I never found it. With that said, this is what I have cobbled together for MY Windows XP/XAMPP test environment AND IT WORKS. MAYBE someone can get some use out it.

NOTE 03: This has not been tested with every extension. I did leave Semantic MediaWiki pages in this cut as an example of how I handle extension pages. Good luck with yours. This code is straight from my working file. Feel free to remove the comments and noise before using it.

~MVW

## ----------------------BEGIN SECTION------------------------
##                    SPECIAL PAGES ACCESS
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## I prefer to keep this as close to last in this file as possible. My original
# test snippet of code came with such a recommendation so I stick to it.
## This section controls SPECIAL PAGES. We use a removal method to control
# which groups see certain special pages.
## Anons allowed 'Specialpages' page access with only 'Userlogin' page available.
## To allow Admin or registered users page access the page name must be NOT
# be in the anon array!!!
## Dont forget to add EXTENSION SPECIAL PAGES when needed.
## REF: http://lists.wikimedia.org/pipermail/mediawiki-l/2009-June/031231.html
# This is the doc I found with the closest solution. Basing off it I made my
# solution to all of my Special Pages and groups.
## ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

function hideSpecialPages(&$list)
 {
   #ANON ARRAY
   #Load array with left over pages not removed in sections below.
   #This array hides pages from all anonymous surfers.
   #Booksources not used in this wiki
   foreach(array(
     'Booksources'
   )as $i){unset($list[$i]);}

   #unset (aka HIDE) SYSOP pages
   #Only Admins can DELETEREVISIONs on this installation so its our key
   global $wgUser;
   if(!$wgUser->isAllowed('deleterevision')){
     unset($list['Blankpage']); #UNLISTED page
     unset($list['Blockme']); #UNLISTED page
     unset($list['Emailuser']); #UNLISTED page
     unset($list['Export']);
     unset($list['Import']);
     unset($list['Listadmins']); #UNLISTED page
     unset($list['Listbots']); #UNLISTED page
     unset($list['Lockdb']);
     unset($list['MergeHistory']);
     unset($list['Movepage']); #UNLISTED page
     unset($list['Mycontributions']); #UNLISTED page
     unset($list['Mypage']); #UNLISTED page
     unset($list['Mytalk']); #UNLISTED page
     unset($list['Resetpass']);
     unset($list['Revisiondelete']); #UNLISTED page
     unset($list['Unlockdb']);
     unset($list['Userlogout']); #UNLISTED page
     # EXTENSION PAGES BELOW
     unset($list['ExportRDF']); # Semantic MediaWiki
     }

   #unset (aka HIDE) BUREAUCRAT pages
   #'move' test qualifies Admin and Bureaucrat
   if(!$wgUser->isAllowed('move')){
     unset($list['Activeusers']);
     unset($list['Allmessages']);
     unset($list['Allpages']);
     unset($list['Blockip']);
     unset($list['Contributions']);
     unset($list['DeletedContributions']);
     unset($list['Filepath']);
     unset($list['Ipblocklist']);
     unset($list['Listfiles']);
     unset($list['Listgrouprights']);
     unset($list['Listusers']);
     unset($list['Log']);
     unset($list['Mostcategories']);
     unset($list['Mostimages']);
     unset($list['Mostlinked']);
     unset($list['Mostlinkedcategories']);
     unset($list['Mostlinkedtemplates']);
     unset($list['Mostrevisions']);
     unset($list['Prefixindex']);
     unset($list['Protectedpages']);
     unset($list['Protectedtitles']);
     unset($list['Resetpass']);
     unset($list['Statistics']);
     unset($list['Tags']);
     unset($list['Undelete']);
     unset($list['Unusedcategories']);
     unset($list['Unusedimages']);
     unset($list['Unusedtemplates']);
     unset($list['Unwatchedpages']);
     unset($list['Userrights']);
     unset($list['Version']);
     unset($list['Withoutinterwiki']);
     # EXTENSION PAGES BELOW
     unset($list['UnusedProperties']); # Semantic MediaWiki
     }

   #unset (aka HIDE) POWERWIKERS pages
   #'patrol' test qualifies Powerwikers
   if(!$wgUser->isAllowed('patrol')){
     unset($list['Ancientpages']);
     unset($list['BrokenRedirects']);
     unset($list['Deadendpages']);
     unset($list['DoubleRedirects']);
     unset($list['Disambiguations']);
     unset($list['Fewestrevisions']);
     unset($list['LinkSearch']);
     unset($list['Listredirects']);
     unset($list['Lonelypages']);
     unset($list['Longpages']);
     unset($list['MIMEsearch']);
     unset($list['Randomredirect']);
     unset($list['Recentchanges']);
     unset($list['Recentchangeslinked']);
     unset($list['Shortpages']);
     unset($list['Uncategorizedcategories']);
     unset($list['Uncategorizedimages']);
     unset($list['Uncategorizedpages']);
     unset($list['Uncategorizedtemplates']);
     unset($list['Wantedcategories']);
     unset($list['Wantedfiles']);
     unset($list['Wantedpages']);
     unset($list['Wantedtemplates']);
     # EXTENSION PAGES BELOW
     unset($list['Ask']); # Semantic MediaWiki
     unset($list['CategoryTree']); # CategoryTree
     unset($list['Properties']); # Semantic MediaWiki
     unset($list['SearchByProperty']); # Semantic MediaWiki
     unset($list['SemanticStatistics']); # Semantic MediaWiki
     unset($list['Types']); # Semantic MediaWiki
     unset($list['WantedProperties']); # Semantic MediaWiki
     }

   #unset (aka HIDE) pages ONLY EMAIL VERIFIED USERS get
   #'edit' qualifies verified emails
   if(!$wgUser->isAllowed('edit')){
     unset($list['Categories']);
     unset($list['FileDuplicateSearch']);
     unset($list['Newimages']);
     unset($list['Newpages']);
     unset($list['Preferences']);
     unset($list['Upload']);
     unset($list['Userlogout']);
     unset($list['Watchlist']);
     # EXTENSION PAGES BELOW
     unset($list['Browse']); # Semantic MediaWiki
     }

   #unset (aka HIDE) pages REGISTERED BUT NOT VERIFIED USERS get
   #'sendemail' qualifies all registered
   if(!$wgUser->isAllowed('sendemail')){
     unset($list['Popularpages']);
     unset($list['Randompage']);
     unset($list['Search']);
     unset($list['Whatlinkshere']);
     # EXTENSION PAGES BELOW
     }

   return true;
 }

$wgHooks['SpecialPage_initList'][]='hideSpecialPages';
## -----------------------END SECTION-------------------------

Don't overwrite original page title when transcluding special page

edit

I am adapting a special page from an existing extension (ContactPage) which will be transcludable. However, currently when transcluding the special page, the original page title will always be re-written to Special:Contact. I know this is not the case for all special pages, e.g. when transcluding Special:RecentChanges, but I could not find any documentation on how to enable/disable this behavior. Does anyone know how I can achieve this? Thanks, Markus 87.144.82.81 10:47, 24 October 2012 (UTC)Reply

Now running into this same problem, and I cannot figure it out. I have looked extensively over e.g. SpecialRecentChanges.php but cannot see why transcluding this doesn't change the page title, while transcluding a custom made extension does? --131.142.152.65 18:01, 26 August 2013 (UTC)Reply
For anyone who finds this, the solution I found was to create a new Parser object (and ParserOptions) and use that to parse any wikitext to HTML, then use the $wgOut->addHTML() approach. --131.142.152.23 15:47, 3 September 2013 (UTC)Reply

Update documentation to use RequestContext

edit

Is it appropriate to update this documentation to reflect the change from using global variables to using the RequestContext? I guess the older method should still be documented for legacy purposes (legacy meaning old versions of MW.) Votes/ideas?

--Daniel Renfro talk/email 17:15, 30 October 2012 (UTC)Reply

Attempting to update. Might make a mess! --JimHu (talk) 23:06, 26 May 2014 (UTC)Reply

Possible error in sample code

edit

Is this code correct?

$wgExtensionMessagesFiles[ 'MyExtensionAlias' ] = __DIR__ . '/MyExtension.alias.php';

Shouldn't it be:

$wgExtensionMessagesFiles[ 'MyExtensionAliases' ] = __DIR__ . '/MyExtension.alias.php';

NOrbeck (talk) 12:20, 5 November 2013 (UTC)Reply

Consistency

edit

Is that really the more consistent way? It seems to me that on Special:SpecialPages, most do it "This way" rather than "That Way". Leucosticte (talk) 22:35, 5 March 2014 (UTC)Reply

Special Contact Information Page

edit

Greetings, MediaWiki community,

I am building a wiki for which I would like to display contact information (name, email, phone number, etc.) that will display as part of the skin and can easily be changed by an inexperienced user. My strategy to do so has been to create an extension that would build a special page to hold the information (similar to the Sidebar special page), editable only to administrators.

Unfortunately, I am very new to MediaWiki, and the documentation on the subject seems fragmented at best. My main stumbling blocks are: understanding how to obtain and parse the text of the special page, and passing the parsed data to the skin, so that it can display the contact info on every page. I have looked, and there do not appear to be any preexisting extensions for this sort of functionality. Any thoughts?

T121 : where is the parameter ???

edit

Hi, on T121 we say "It passes a single parameter,..." but the function "execute()" described in the title T119 of the paragraph has none. So what are we speaking of ? - can anyone clarify ? - Thanks.

13:48, 28 July 2019 (UTC)

Example code broken in 1.34

edit

Using the example code verbatim, on loading the Special:SpecialPages page, I get :

[8d071dee540ecead9515bcd8] /mediawiki/index.php/Special:SpecialPages InvalidArgumentException from line 238 of /var/lib/mediawiki-1.34.0/vendor/wikimedia/object-factory/src/ObjectFactory.php: Provided specification is not an array. 

Backtrace:

#0 /var/lib/mediawiki-1.34.0/vendor/wikimedia/object-factory/src/ObjectFactory.php(131): Wikimedia\ObjectFactory::validateSpec(string, array)
#1 /var/lib/mediawiki-1.34.0/vendor/wikimedia/object-factory/src/ObjectFactory.php(102): Wikimedia\ObjectFactory::getObjectFromSpec(string, array)
#2 /var/lib/mediawiki-1.34.0/includes/specialpage/SpecialPageFactory.php(447): Wikimedia\ObjectFactory->createObject(string, array)
#3 /var/lib/mediawiki-1.34.0/includes/specialpage/SpecialPageFactory.php(478): MediaWiki\Special\SpecialPageFactory->getPage(string)
#4 /var/lib/mediawiki-1.34.0/includes/specials/SpecialSpecialpages.php(56): MediaWiki\Special\SpecialPageFactory->getUsablePages(User)
#5 /var/lib/mediawiki-1.34.0/includes/specials/SpecialSpecialpages.php(44): SpecialSpecialpages->getPageGroups()
#6 /var/lib/mediawiki-1.34.0/includes/specialpage/SpecialPage.php(575): SpecialSpecialpages->execute(NULL)
#7 /var/lib/mediawiki-1.34.0/includes/specialpage/SpecialPageFactory.php(611): SpecialPage->run(NULL)
#8 /var/lib/mediawiki-1.34.0/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#9 /var/lib/mediawiki-1.34.0/includes/MediaWiki.php(900): MediaWiki->performRequest()
#10 /var/lib/mediawiki-1.34.0/includes/MediaWiki.php(527): MediaWiki->main()
#11 /var/lib/mediawiki-1.34.0/index.php(44): MediaWiki->run()
#12 {main}

When I chuck some debug code into ObjectFactory.php, the thing it's objecting to is the SpecialPages definition - "MediaWiki\Extension\MyExtension\Special" is what it's objecting to not being an array

Changing the extension.json to the blow seems to fix things.

{
  "name": "MyExtension",
  "version": "0.0.0",
  "author": ["Your Name"],
  "url": "https://www.mediawiki.org/wiki/Extension:MyExtension",
  "descriptionmsg": "myextension-desc",
  "license-name": "MIT",
  "type": "other",
  "AutoloadClasses": {
    "SpecialMyExtension": "src/Special.php"
  },
  "SpecialPages": {
    "MyExtension": "SpecialMyExtension"
  },
  "MessagesDirs": {
    "MyExtension": ["i18n"]
  },
  "manifest_version": 2
}

better documentation for key identifier strings

edit

This isn't a help request so much as a "check me to make sure I'm not posting incorrect information". I'm working on a custom extension, and in between last night and this morning something changed which resulted in "No such special page" when I went to the page's URL from Special:SpecialPages -- although everything was still displaying properly there and in Special:Version. I figured that one out, but I thought it was high time to take some notes and, once I'm reasonably sure they're correct, post them here in MW's official documentation.

Anyone who does have answers, though, please feel free to chime in. ^.^

The documentation issues I'm trying to address:

  • There doesn't seem to be a clear list somewhere of all the bits that need to be defined properly in order for everything to work (and what is affected).
  • There's very little documentation of the JSON files, specifically what each key-string means or could mean. (This is partly JSON's fault for not permitting comments, which would be the obvious way to document examples.)

Crucial Bits List

edit

Here's what I've got so far:

  • Knowns:
    • In extension.json:
      • The value of the "name": key is what is shown on the extension's entry on the Special:Version page.
      • Each element in "SpecialPages": { } defines a SpecialPage URL. The element name is the "X" in "Special:X" for each page.
        • (Tentative) This allows a single extension to define multiple Special pages, with the name of each element being the "X" for another Special:X. The element's value is the class to use.
        • (Tentative) For each X that points to a different class, that class can generate a corresponding entry in Special:SpecialPages.
    • In the primary PHP file:
      • the constructor should call parent::__construct('X');, where "X" must be the value of "Special:X".
      • whatever is returned by function getDescription() is displayed on Special:SpecialPages as the extension's description.
  • Unknowns:
    • In extension.json:

JSON files

edit
  • extension.json:
    • The descriptionmsg element seems to define the name of a key which should (or must?) appear in the i18n files.
  • i18n/ files:
    • All of the files in this folder are basically different-language translations of the same set of messages, so each one should (ideally) have the same set of keys.
    • Are there any specific entries (messages) which must be present, and mean something specific to MW? Or are they all pretty much up to the extension to use as desired?
    • qqq.json:
      • The qqq "language" is a "special" language which provides an explanation (in one language only), rather than display text, for each message. (Where is this actually used? Or is it just for human consumption? Does the name actually matter, or could a really thorough documenter have qqq-en.json, qqq-de.json, etc.?)
        • Each qqq element has a name of the form "[spkey]-[name]". where "[spkey]" refers to the Special Page's name -- but what, exactly, does [spkey] need to match?

Still exploring and documenting, but that seems to cover a lot of the information I couldn't find earlier.

Woozle (talk) 22:00, 29 August 2020 (UTC)Reply

Broken template for class documentation

edit

See the discussion at https://www.mediawiki.org/wiki/Template_talk:Class_doclink

That template, used on this page and pages like it, is broken. I didn't have time to investigate the structure of generated docs + the template code to fix it. Greg Rundlett (talk) 20:20, 5 April 2024 (UTC)Reply

Return to "Special pages" page.