Manual:Special pages/de

From MediaWiki.org
Jump to: navigation, search
Gnome-preferences-other.svg Erweiterungen:Manual:Extensions EntwicklungManual:Developing extensions Tag extensionsManual:Tag extensions Handbuch:Parser functionsManual:Parser functions HooksManual:Hooks SpezialseitenManual:Special pages Handbuch:SkinsManual:Skins Handbuch:Magische WörterManual:Magic words APIAPI:Extensions
MediaWiki extensions

Spezialseiten sind Seiten, die von der Software auf Wunsch erstellt werden, um eine bestimmte Funktion zu erfüllen. Zum Beispiel könnte eine Spezialseite alle Seiten anzeigen, die einen oder mehrere Links auf eine externe Seite haben oder sie könnte ein Formular erstellen bzw. beinhalten, dass von Benutzern übermitteltes Feedback bereitstellt. Spezialseiten befinden sich in ihrem eigenen Namensraum (Spezial:) und sind nicht direkt wie andere Seiten editierbar. Entwickler können auch neue Spezialseiten erstellen. Diese Seiten können frei zugänglich sein und werden allgemein in der Liste aller Spezialseiten bei Spezial:Spezialseiten auftauchen. Einige Spezialseiten sind nur für Benutzer mit bestimmten Berechtigungen und Zugriffen zugänglich. Andere Spezialseiten werden nicht auf der Liste der Spezialseiten angezeigt und nur durch den Wiki intern verwendet.

Allgemeine Information[edit]

Alle der ~75 eingebauten Spezialseiten, die mit MediaWiki kommen, werden SpezialIrgendeinname.php genannt und befinden sich im includes/specials Verzeichnis. Spezialseiten die von Drittanbieter-Entwicklern erstellt wurden, werden allgemein im extensions Verzeichnis in ihrer eigenen Datei oder als Teil einer großen Erweiterung gespeichert. Alle Spezialseiten erben von einer Klasse namens Spezialseite die in includes/SpecialPage.php definiert ist. Wenn eine neue Spezialseite erstellt wird, können die erforderlichen Benutzerrechte definiert werden, um auf die Seite zuzugreifen. Diese Rechte geben unter anderem an, ob die Seite auf Spezial:Spezialseiten erscheint und ob die Seite in anderen Seiten einbindbar ist.

Spezialseiten haben zudem einzigartige Namen, die auf einem Wiki individuell angepasst werden können. Die allgemeine Form ist "Spezial:Seitenname", wobei beide "Spezial" und "Seitenname" anpassbar sind. Der Spezial-Pseudo-Namensraum kann in andere Sprachen übersetzt werden. Dieser übersetzte Namensraum kann mit dem Wikitext {{ns:special}} erzeugt werden, in diesem Wiki gibt es "Special". Der Name von der Spezialseite kann auch in einer Systemnachricht neu definiert werden, für die Seitensprache, mit dem generischen Namen von der Spezialseite als die ID.

Eine Spezialseite kann oder auch nicht Eingaben zulassen. Zum Beispiel, Spezial:Exportieren erlaubt einem Benutzer, eine spezifische Seite zu definieren, um diese durch aufrufen von Spezial:Exportieren/Sun zu exportieren. Wenn eine Spezialseite komplizierte Eingaben erlaubt, werden weitere Parameter an die Query String-Komponente zum verarbeiten gesendet, z.B. http://www.mediawiki.org/w/index.php?title=Special:Recentchanges&days=3&limit=250.

Infos:
  • Es gibt verschiedene Möglichkeiten, um Spezialseiten zu machen, aber die eine unten wird von der Mehrheit der offiziellen Erweiterungen verwendet, und die Einhaltung dieses Stil wird empfohlen. Außerdem, seien Sie sicher, einen Credits-Block in der neuen Spezialseite für 'Spezialseite' einzubeziehen. Siehe $wgExtensionCredits für weitere Details.
  • Nachdem Sie eine neue Spezialseite gemacht haben, achten Sie darauf, sie zur Category:Special page extensions/de hinzuzufügen, so dass andere Leute sie finden können.
  • Diese Methode ist nur für MediaWiki gültig, das auf PHP5 und höher läuft. Wenn Sie eine frühere Version von MediaWiki nutzen, auf einer mehr-letzteren Version von PHP, upgraden Sie MediaWiki.
  • Spezialseiten können nicht innerhalb von Frames aufgenommen werden, es sei denn Sie verwenden $wgOut->allowClickjacking();.

Grundlegende Spezialseitenvorlage[edit]

Die meisten Erweiterungen mit einer Spezialseite benötigen drei Dateien, die im Folgenden genannt werden: eine kleine Setup-Datei, welche jedes Mal geladen wird, sobald MediaWiki beginnt, eine Internationalisierungsdatei und eine Datei mit dem Großteil des Codes. Alle zusammen sollten in einem neuen Verzeichnis innerhalb des Verzeichnis extensions/ platziert werden. Die MediaWiki Programmierungskonventionen definieren die vier Dateien wie folgt:.

  • <Erweiterungsname>.php - Die Setup-Datei.
  • Special<Spezialseitenname>.php - Der Spezialseitencode.
  • <Erweiterungsname>.i18n.php - Die Internationalisierungsdatei.
  • <Erweiterungsname>.alias.php - Die Spezialseitenaliasdatei.

Allgemein sollten Spezialseiten nach der Erweiterung benannt werden, so hat die Gadgets-Erweiterung die Datei Gadgets.php und SpecialGadgets.php. Wenn Ihre Erweiterung mehr als eine Spezialseite hat, benötigen Sie natürlich mehr Namen.

Im Beispiel unten, <Spezialseitenname> ist MeineErweiterung. Eine funktionierende Kopie steht zum herunterladen zur Verfügung, siehe weiter unten.

Nach dem Erstellen der unten aufgeführten Dateien, fügen Sie die folgende Zeile in LocalSettings.php ein

  • require_once( "$IP/extensions/MeineErweiterung/MeineErweiterung.php" );

Die Installationsdatei[edit]

The setup file (in this example, named MyExtension.php) looks like this:

<?php
# Alert the user that this is not a valid entry point to MediaWiki if they try to access the special pages file directly.
if (!defined('MEDIAWIKI')) {
	echo <<<EOT
To install my extension, put the following line in LocalSettings.php:
require_once( "$IP/extensions/MyExtension/MyExtension.php" );
EOT;
	exit( 1 );
}

$wgExtensionCredits['specialpage'][] = array(
	'path' => __FILE__,
	'name' => 'MyExtension',
	'author' => 'My name',
	'url' => 'https://www.mediawiki.org/wiki/Extension:MyExtension',
	'descriptionmsg' => 'myextension-desc',
	'version' => '0.0.0',
);

$dir = dirname(__FILE__) . '/';

$wgAutoloadClasses['SpecialMyExtension'] = $dir . 'SpecialMyExtension.php'; # Location of the SpecialMyExtension class (Tell MediaWiki to load this file)
$wgExtensionMessagesFiles['MyExtension'] = $dir . 'MyExtension.i18n.php'; # Location of a messages file (Tell MediaWiki to load this file)
$wgExtensionMessagesFiles['MyExtensionAlias'] = $dir . 'MyExtension.alias.php'; # Location of an aliases file (Tell MediaWiki to load this file)
$wgSpecialPages['MyExtension'] = 'SpecialMyExtension'; # Tell MediaWiki about the new special page and its class name

This stub file registers several important things:

  • The location of the SpecialMyExtension class
  • The location of a messages file
  • The location of an aliases file
  • The new special page and its class name

You may also want to set a value for $wgSpecialPageGroups so that your special page gets put under the right heading in Special:SpecialPages, e.g.:

$wgSpecialPageGroups['MyExtension'] = 'other';

If your special page doesn't seem to fit into any of the preconfigured headings, you can add a new heading by adding it to your .i18n.php file (see below, The Messages/Internationalization File).

Die Spezialseitendatei[edit]

The body file (in this example, named SpecialMyExtension.php) will contain a subclass of SpecialPage. It will be loaded automatically when the special page is requested. In this example, the subclass MyExtension is called:

<?php
class SpecialMyExtension extends SpecialPage {
	function __construct() {
		parent::__construct( 'MyExtension' );
	}

	function execute( $par ) {
		global $wgRequest, $wgOut;

		$this->setHeaders();

		# Get request data from, e.g.
		$param = $wgRequest->getText('param');

		# Do stuff
		# ...
		$output = 'Hello world!';
		$wgOut->addWikiText( $output );
	}
}

execute() is the main function that is called when a special page is accessed. The function overloads the function SpecialPage::execute(). It passes a single parameter $par, the subpage component of the current title. For example, if someone follows a link to Special:MyExtension/blah, $par will contain "blah".

Wikitext and HTML output should normally be run via $wgOut -- do not use 'print' or 'echo' directly when working within the wiki's user interface.

However if you're using your special page as an entry point to custom XML or binary output, see Taking over output in your special page.

Die Nachrichten/Internationalisierungsdatei[edit]

All special pages must specify a title to appear in the title and <H1> elements of the extension's page and on Special:SpecialPages. The extension specifies the title through a message. The structure of the message is a key-value pair. The ID, 'myextension', must be in all lowercase when specified in the key portion of the key-value pair, even if everywhere else it is MyExtension. The title, 'My Extension', can be anything, however it is convenient if the page title is the same as the ID. A good example of a message/internationalization file (in this example, named MyExtension.i18n.php) would be:

<?php
/**
 * Internationalisation for myextension
 *
 * @file
 * @ingroup Extensions
 */
$messages = array();

/** English
 * @author <your username>
 */
$messages['en'] = array(
	'myextension' => 'My Extension', // Ignore
	'myextension-desc' => "Extension's description",
);

/** Message documentation
 * @author <your username>
 */
$messages['qqq'] = array(
	'myextension-desc' => "{{desc}}",
);

Note that IDs should not start with an uppercase letter, and that a space in the ID should be written in the code as an underscore.

Die Aliasesdatei[edit]

We can also internationalize the name of the special page by creating aliases for it (here, in a file called "MyExtension.alias.php"). In this example, the special page MyExtension registers an alias so the page becomes accessible via .../Special:AnotherName e.g. .../Spezial:Meine_Erweiterung in German, and so on.

<?php
/**
 * Aliases for myextension
 *
 * @file
 * @ingroup Extensions
 */

$specialPageAliases = array();

/** English
 * @author <your username>
 */
$specialPageAliases['en'] = array(
	'MyExtension' => array( 'MyExtension', 'My Extension' ),
);

/** Deutsch
 * @author <your username>
 */
$specialPageAliases['de'] = array(
	'MyExtension' => array( 'MeineErweiterung', 'Meine Erweiterung' ),
);

Again, a space in the ID should be written in the code as an underscore. For the page header and linking, the usual rules for page names apply. If $wgCapitalLinks is true, a lowercase letter is converted to uppercase, and an underscore is displayed as a space. For example: instead of the above, we could have used 'my_extension' => 'My extension', assuming we consistently identified the extension as my_extension elsewhere.

Spezialseitengruppe[edit]

As mentioned above, you can set which special page group your special page is categorized under on Special:SpecialPages by setting $wgSpecialPageGroups['YourPageName'] = 'pagegroup'. The standard page groups that come with MediaWiki are listed in the messages file (for example, the English messages are in languages/messages/MessagesEn.php) and begin with specialpages-group-. If your special page is to be categorized under, for example, users, then the message looked for is specialpages-group-users. The value for this key is the text that should appear as the name of that category, for example, Users and rights.

If your special page does not seem to fit under any of the existing categories, you can always make a new one. In your extension's internationalization file simply insert a new key for the messages array. In this example, we will define the gamification group:

<?php
[...]
$messages['en'] = array(
	'myextension' => 'My Extension', //Ignore
	'myextension-desc' => "Extension's description",
        'specialpages-group-gamification' => 'Gamification'
);
[...]

Now simply set $wgSpecialPageGroups['YourPageName'] => 'gamification' and reload Special:SpecialPages to see your new category.

Andere wichtige Dateien[edit]

SpecialPage.php[edit]

Constructor[edit]

You can overload the constructor to initialize your own data, but the main reason you would want to do it is to change the behavior of the SpecialPage class itself. When you call the base class constructor from your child class, the following parameters are available:

function MySpecialPage( $name = '', $restriction = '', $listed = true )
  • string $name Name of the special page, as seen in links and URLs
  • string $restriction User right required, e.g. "block" or "delete"
  • boolean $listed Whether the page is listed in Special:Specialpages

Spezialseite->setHeaders()[edit]

Das initialisiert das OutputPage Object $wgOut mit dem Namen und der Beschreibung der erzeugten Spezialseite. Es sollte immer von der execute() Methode aus aufgerufen werden.

Spezialseite->including()[edit]

Einige Spezialseiten können eingebunden werden innerhalb einer anderen Seite. Wenn man z.B. {{Special:RecentChanges}} zum Wikitext einer Seite hinzufügt, dann wird eine Liste der letzten Änderungen innerhalb des existierenden Inhalts der Seite angezeigt.

Das Einbinden einer Spezialseite von einer anderen Webseite ist nur dann möglich, wenn man die Seite im Konstruktor als "includable" markiert. Das lässt sich durch ein Hinzufügen des nachfolgenden Codeschnipsels in die __construct() Methode bewerkstelligen:

$this->mIncludable = true;

Man kann auch eine Spezialseitenklasse definieren, die die IncludableSpecialPage-Klasse erweitert.

Die Funktion SpecialPage->including() gibt einen booleschen Wert zurück, der angibt, in welchem Kontext die Spezialseite aufgerufen wird. Sie nimmt den booleschen Wert "falsch" an, wenn es sich um eine andere Webseite handelt und "wahr", wenn es von einer anderen Webseite eingebunden wurde. Normalerweise möchte man die Darstellung kürzen, wenn die Seite eingebunden wurde.

Spezialseite->execute()[edit]

Das ist die Funktion, welche die geerbte Klasse überladen sollte. Sie übergibt einen einzelnen Parameter, der üblicherweise als $par bezeichnet wird. Dieser Parameter ist die Unterseitenkomponente des momentanen Titels. Wenn z.B. jemand einem Link auf Special:MyExtension/blah folgt, enthält $par den Wert "blah".

OutputPage.php[edit]

Die globale Variable $wgOut (vom Typ OutputPage) ist diejenige Variable, die man am häufigsten benutzt, da sie für das Übersenden von Ausgaben an den Browser zuständig ist (bitte nutzen Sie dafür weder echo noch print). Wenn man $wgOut irgendwo nutzen möchte, sollte man sie als global definieren:

function randomFunction() {
	global $wgOut;
	$wgOut->addHTML('<b>This is not a pipe...</b>');
}

Die OutputPage Klasse findet sich unter includes/OutputPage.php, die auch einige Methoden enthält, die man definitiv kennen sollte.

OutputPage->addHTML()[edit]

Der quick-and-dirty-Ersatz für echo. Es übergibt den Parameter (in den Klammern) und übergibt ihn an den Puffer: es werden keine Sicherheitsfragen gestellt. In der unten dargestellten Aktion könnte, falls $action Nutzerdaten enthält, auch XSS, böses Zeug oder die Ausgeburt von Satan enthalten sein. Sie sind besser aufgehoben, wenn Sie escaping nutzen (wie beispielsweise mit der PHP Funktion htmlentities) oder die XML builders class zum Erstellen vertrauenswürdiger Ausgaben.

$wgOut->addHTML('<form action="'.$action.'" method="post">');

OutputPage->addWikiText()[edit]

For most output, you should be using this function. It's a bit of a black magic function: wikitext goes in, HTML comes out, and a whole lotta arcane code and demon summonings happen in between.

$wgOut->addWikiText("This is some ''lovely'' [[wikitext]] that will '''get''' parsed nicely.");

What's worth noting is that the parser will view your chunks as cohesive wholes and paragraph accordingly. That is...

$wgOut->addWikiText('* Item 1');
$wgOut->addWikiText('* Item 2');
$wgOut->addWikiText('* Item 3');

Will output three lists with one item each, which probably wasn't intended.

Warnung Warnung: If your special page is intended to be included in other pages, you should probably not use addWikiText() (or any other function that calls the parser. Message). Due to a bug in MediaWiki (Bug 16129), an included special page will mess up any inclusion before it on the same including page, showing strings like UNIQ10842e596cbb71da.

Note however, if you just want to insert a system message and have it treated like parsed wikitext, you can use code like $wgOut->addHtml( wfMessage( 'key-of-message' )->parse() ). This will not have the issue with nested parser calls mentioned above.

workaround #1[edit]

Important: these work arounds are only needed if you are making a transcludable special page. Normal special pages do not need these

As a workaround, you can have your extensions convert Wikitext to HTML using a separate Parser object and then use addHTML(). Example:

$wgOut->addHTML($this->sandboxParse("Here's some '''formatted''' text."));
# Assuming this is inside the same class as the rest of your special page code
function sandboxParse($wikiText) {
	global $wgTitle, $wgUser;
	$myParser = new Parser();
	$myParserOptions = ParserOptions::newFromUser($wgUser);
	$result = $myParser->parse($wikiText, $wgTitle, $myParserOptions);
	return $result->getText();
}
workaround #2[edit]

I tried the above, and found that the same problem now applied to any <tag>s in the transcluded text. This won't be a problem for a lot of extensions, but the extension I was writing was intended to show wikitext from another page as part of its functionality, so this was a problem.

The process for parsing a page which transcludes a special page seems to be this:

  1. Replace {{Special:MyExtension}} with a UNIQ-QINU marker (because SpecialPage output is expected to be ready-to-output HTML)
  2. Replace any <tag>s with QINU markers as above
  3. Parse everything else from wikitext to HTML
  4. Replace all QINU markers with their respective stored values, in a single pass

The process for parsing a page which transcludes a non-special page, though, is apparently like this:

  1. Replace {{:Normal Article Name}} or {{Template Name}} with contents of transcluded page (because transcluded pages contain unparsed wikitext)
  2. Replace any <tag>s with QINU markers as above
  3. Parse everything else from wikitext to HTML
  4. Replace all QINU markers with their respective stored values, in a single pass

The problem is apparently that in the earlier case, the parsing of the SpecialPage's wiki text is lacking the final QINU decoding step (why?), so all the QINU markers are left undecoded. (This may be a leftover from using the same syntax to invoke transclusion of a wikitext page, which is just pasted straight into the host page's wikitext contents and parsed, as is used to invoke transclusion of a SpecialPage, which must not be parsed at all. Wherever the code is that decides "wait, this is a special page -- replace it with a QINU", it should be doing the extra unstripGeneral before doing the QINU substitution.)

So I just did the following -- after this line:

$htOut = $wgParser->recursiveTagParse($iText);

...I added these lines (the second one is only because the function definition for the first one recommends it):

$htOut = $wgParser->mStripState->unstripGeneral($htOut);
$htOut = $wgParser->mStripState->unstripNoWiki($htOut);

Since I have now documented this, of course, I will now find a tragic flaw with it and feel really stupid... but as long as it seems to be working, I had to note it here. (It is also important to note the problem with work-around #1.) Also, I have only tested this with MediaWiki 1.10.1. The problem still exists under MW 1.14, but this solution may or may not work. --Woozle 18:26, 9 April 2009 (UTC)

wfMsg()[edit]

In most of the real special pages, you will rarely see $wgOut->addWikitext() without wfMsg() popping in.

wfMsg() is a MediaWiki internationalization (i18n) function.

OutputPage->showErrorPage()[edit]

An error page is shown. The arguments $title and $msg specify keys into wfMsg(), not text. An example:

$wgOut->showErrorPage('error','badarticleerror');
  • 'error' refers to the text "Error".
  • 'badarticleerror' refers to the text "This action cannot be performed on this page.".

WebRequest.php[edit]

The WebRequest class is used to obtain information from the GET and POST arrays. Using this is recommended over directly accessing the superglobals, since the object does fun stuff like magic_quotes cleaning. The WebRequest object is accessible from extensions by including the global $wgRequest in the code.

WebRequest->getVal($key)[edit]

Returns a string that corresponds to the form input with the name $key.

WebRequest->get*()[edit]

Returns an int, bool, etc depending on the function called. For checkboxes for example, the function getBool is useful.

WebRequest->wasPosted()[edit]

Returns true if a form was posted.

Database.php[edit]

MediaWiki has a load of convenience functions and wrappers for interacting with the database. It also has an interesting load balancing scheme in place. It's recommended you use these wrappers. Check out Database.php for a complete listing of all the convenience functions, because these docs will only tell you about the non-obvious caveats. See Manual:Database access.

wfGetDB()[edit]

As this name suggests, this function gets you a reference of the database. There is no global that contains a database object.

When you call the function, you should pass it a parameter, the constant DB_MASTER or DB_SLAVE. Generally, you interact with the slave database when you're only performing read operations, and interact with the master when you're writing to the database. It's real easy to do, so do it, even if you only have one database.

User.php[edit]

The User class is used to represent users on the system. The global $wgUser represents the currently logged in user, and is usually what you will deal with when manipulating users.

User->isAllowed($right)[edit]

Returns true or false depending on whether the user is allowed to do $right.

User->isBlocked()[edit]

Returns true if a user is blocked.

Title.php[edit]

Title represents the name of a page in the wiki. This is useful because MediaWiki does all sorts of fun escaping and special case logic to page names, so instead of rolling your own convert title to URL function, you create a Title object with your page name, and then use getLocalUrl() to get a URL to that page.

Title::makeTitle()[edit]

Title->getLocalUrl()[edit]

This method gives you the url to the page. However, in most cases you would want to use the Linker class to make links to pages.

Passgenaue Spezialseiten[edit]

There are various ways to provide your own special pages not bundled within MediaWiki:

  • One method is to install an extension that generates a form to create or edit an article. A list of extensions currently available, can be found at Category:Special page extensions.
  • You can also write an extension which provides your own special page. Writing your own extension requires PHP coding skill and comfort with object oriented design and databases also is helpful. You will also need to know how to use code to create and edit MediaWiki articles. For more information, please see this discussion.
  • You can also display a custom page through Javascript, in place of the default error message "Unknown special page". In MediaWiki:Common.js, check for wgPageName, then hide the MediaWiki-generated content (just appendCSS {visibility:hidden;} ), and inject custom HTML (innerHTML) into the document.getElementById('bodyContent') or document.getElementById('mw_contentholder'). For an example, see w:en:User:Splarka/electrocute.js.

FAQ[edit]

Einrichten eines Erweiterungstitels[edit]

MediaWiki does not set the title of the extension, which is the developer's job. It will look for the name of the extension when Special:Specialpages is called or the special page is loaded (specifically right before the registered wfSpecial*() function is called). Use $wgOut to title the extension like: $wgOut->setPagetitle("your title");

The place where the extension can be found (as specified by what is passed into the SpecialPage constructor) is the key--except that it is not capitalized because of getDescription(), the internally used function that finds out the title (or, what they call description) of the special page, strtolower the name. "ThisIsACoolSpecialPage"'s key would be "thisisacoolspecialpage."

Theoretically, getDescription can be overloaded in order to avoid interacting with the message cache but, as the source code states: "Derived classes can override this, but usually it is easier to keep the default behavior. Messages can be added at run-time--see MessageCache.php". Furthermore, this prevents the MediaWiki namespace from overloading the message, as below.

Lokalisierung des Erweiterungsnamen[edit]

So you've just installed a shiny new MediaWiki extension and realize: "Oh no, my wiki is in French, but the page is showing up as English!" Most people wouldn't care, but it's actually a quite simple task to fix (as long as the developer used the method explained on this page). No noodling around in source code. Let's say the name of the page is DirtyPages and the name comes out to "List of Dirty Pages" but you want it to be (and excuse my poor French) "Liste de Pages Sales". Well, it's as simple as this:

  1. Navigate to MediaWiki:DirtyPages, this page may not exist, but edit it anyway
  2. Insert "Liste de Pages Sales" and save

And voilà (pardon the pun), the change is applied.

This is also useful for customizing the title for your wiki within your language: for instance, the developer called it "List of Dirty Pages" but you don't like that name, so you rename it "List of Pages needing Cleanup". Check out Special:Allmessages to learn more.

Also, if your extension has a large block of text that does change, like a warning, don't directly output the text. Instead, add it to the message cache and when the time comes to output the text in your code, do this:

$wgOut->addWikiText( wfMsg( 'dirtypageshelp' ) );

Then this message too can be customized at MediaWiki:Dirtypageshelp.

See also Help:System message.

Seitenzugriff beschränken[edit]

Nichtanzeigen der Spezialseite auf der Seite Spezial:Spezialseiten[edit]

Sometimes you may want to limit the visibility of your SpecialPage by removing it from the Special:SpecialPages page and making it visible to only a set group of users. You can do this in the constructor by passing in a restriction parameter; e.g., “editinterface”, a right only assigned to sysops by default; see the User rights manual for other available user rights.

function __construct() {
	parent::__construct( 'MyExtension', 'editinterface' ); // restrict to sysops
}

Or you can create your own right in the setup file and assign it to sysops, e.g.:

$wgGroupPermissions['sysop']['myright'] = true;
$wgAvailableRights[] = 'myright';

and then call the constructor with your right:

function __construct() {
	parent::__construct( 'MyExtension', 'myright' );
}

URL-Zugriff auf Ihre Spezialseite verbieten[edit]

Achtung! Achtung: Even if you restrict your page, your extension should check that the proper right is present, because a user can still access it directly if you use the constructor to require a specific right:

function execute( $par ) {
	// ...
	if (  !$this->userCanExecute( $this->getUser() )  ) {
		$this->displayRestrictionError();
		return;
	}
	// ...
}

Deaktivieren der Spezial:UserLogin und Spezial:UserLogout Seiten[edit]

In LocalSettings.php you can use the SpecialPage_initList hook to unset unwanted built-in special pages. See "making a few SpecialPages restricted" if you need conditional unsetting of special pages for example for certain user groups. The general message "You have requested an invalid special page." is shown if users try to access such unset special pages.

function disableSomeSpecialPages(&$list) {
	unset($list['Userlogout']);
	unset($list['Userlogin']);
	return true;
}
$wgHooks['SpecialPage_initList'][]='disableSomeSpecialPages';

Logs hinzufügen[edit]

On MediaWiki, all actions by users on wiki are tracked for transparency and collaboration. See Manual:Logging to Special:Log for how to do it.

Sprache:Project:Language policy English  • Deutsch • Bahasa Indonesia • 日本語 • русский • 中文