Code Primjeri
Template NEWS
To Do | |||
---|---|---|---|
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 17.3.2006 | ||
Informationen | |||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 1.3.2007 | ||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 1.9.2006 | ||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 3.1.2007 | ||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 1.6.2006 | ||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 1.4.2006 | ||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 1.7.2006 | ||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 1.9.2006 | ||
Update | |||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | |||
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | 23.3.2006 |
Template ToDo
Testlauf eines bugtrackers: BugZilla |
Menu Primjer
News Primjer
To Do | |||
---|---|---|---|
PC Infos aktualisieren | 07.02.2008 | ||
Animal Crossing Geheimcodes weiter machen | 26.06.2007 | ||
Futurama – Episode List sortieren | ?.?.???? | ||
Paperport Einstellungen dokumentieren | ?.?.???? | ||
Informationen | |||
Arbeitzeit | 17.7.2007 | ||
Update | |||
Lager – Jumbo / Mara. | 01.05.2008 | ||
Zum mitneme in Ferien | 30.06.2008 | ||
Verbenliste Französisch erweitert mit "travailler". | 10.02.2008 | ||
2 SMW Hack gemacht. | 10.02.2008 |
Willkommen. Wer gerne lernen möchte, wie ein Wiki funktioniert, soll in der sandbox herumtoben.
Siehe die Dokumentation zur Anpassung der Benutzeroberfläche und das Benutzerhandbuch für Hilfe zur Benutzung und Konfiguration.
Administrativ
[edit] Entwicklung
Projekte
Menu1 | Menu2 | Menu3 | Menu4 |
---|---|---|---|
Menu1 | Menu1 | Menu1 | Menu1 |
Menu2 | Menu2 | Menu2 | Menu2 |
Menu3 | Menu3 | Menu3 | Menu3 |
Menu4 | Menu4 | Menu4 | Menu4 |
Menu5 | Menu5 | ||
Menu6 | |||
Menu7 | |||
Menu8 |
Diverses
MediaWiki to slow
Just to tell that I installed and activated:
– MySQL Query Cache – The APC PHP cache (APC at PECL)
It runs a little bit faster now. Loading time is now around 6-8 s, instead of the initial 10-20s.
User:Robchurch/Performance tuning
MediaWiki is capable of scaling to meet the needs of large wiki farms such as those of the Wikimedia Foundation, Wikitravel and Wikia and can take advantage of a wide number of methods including multiple load-balanced database servers, memcached object caching, front-end Squid caches and multiple application servers.
For smaller wikis, however, which MediaWiki seems to attract more of each month, it isn't so tuned out of the box. This page contains a few useful tips on performance tuning for sites using MediaWiki.
Install APC
One of the best immediate performance improvements that can be made is to speed up execution of the application itself. This is done using a PHP accelerator, such as APC.
APC ("Alternative PHP Cache") is a bytecode cache, that is, it stores the compiled bytecode from the PHP interpreter for future runs of the same script file. A large application such as MediaWiki, which has a not insignificant initialisation time, benefits from using such an extension rather noticeably.
The exact preferred method for installing APC depends on your platform; it can be installed from PECL in the standard fashion, or compiled and installed manually. Many Linux distributions offer packages for APC which are typically installed in the same fashion as PHP itself.
Once APC is installed and running, which can be verified in the output of the phpinfo(); function, MediaWiki needs no special configuration to benefit from the bytecode caching capabilities it offers. However, APC also offers a "user cache", which allows application developers to store object data in the in-memory cache, rather like a "mini memcached", and MediaWiki can take advantage of this to use as a parser, message and general-purpose cache.
To configure MediaWiki to use the APC user cache, edit LocalSettings.php and add the following line:
-
$wgMainCacheType = CACHE_ACCEL;
A script, apc.php is bundled with the APC package which can be used to inspect the status of the cache, and also examine the contents of the user cache to verify that MediaWiki is correctly using it.
Caveats
- The APC user cache is not suitable for use in environments where multiple application servers are used.
- All PHP applications on the server are able to access the same user cache, thus, if multiple users are using the server to run web applications, they are able to read the values of the user cache, which could lead to information being taken from the cache. This might include serialized user objects, for example, containing email addresses, password hashes and edit tokens.
MediaWiki will still benefit from APC's bytecode caching features if you decide not to configure it to use the user cache, however, so it is still well worth installing.
Dynamically defining an href target
I didn't want to change the behavior in a static way, but sometimes wanted to define an alternate target. To open a link in a new window, one should be able to define target='_new' or target='_blank'. The following changes allow doing so.
php changes
Open "includes/Linker.php"
1. function getExternalLinkAttributes
find the function getExternalLinkAttributes
function getExternalLinkAttributes( $link, $text, $class='' ) { $link = htmlspecialchars( $link ); $r = ($class != '') ? " class='$class'" : " class='external'"; $r .= " title=\"{$link}\""; return $r; }
change it to
function getExternalLinkAttributes( $link, $text, $class='' ) { $targ = ""; $pos = strpos( $link, '|' ); if ( $pos !== false ) { $targ = " target='" . substr ( $link, $pos + 1 ) . "'"; $link = substr ( $link, 0, $pos ); } $link = htmlspecialchars( $link ); $r = ($class != '') ? " class='$class'" : " class='external'"; $r .= $targ . " title=\"{$link}\""; return $r; }
2. function makeExternalLink
find the function makeExternalLink
function makeExternalLink( $url, $text, $escape = true, $linktype = '' ) { $style = $this->getExternalLinkAttributes( $url, $text, 'external ' . $linktype ); global $wgNoFollowLinks; if( $wgNoFollowLinks ) { $style .= ' rel="nofollow"'; } $url = htmlspecialchars( $url ); if( $escape ) { $text = htmlspecialchars( $text ); } return '<a href="'.$url.'"'.$style.'>'.$text.'</a>'; }
change it to
function makeExternalLink( $url, $text, $escape = true, $linktype = '' ) { $style = $this->getExternalLinkAttributes( $url, $text, 'external ' . $linktype ); global $wgNoFollowLinks; if( $wgNoFollowLinks ) { $style .= ' rel="nofollow"'; } $pos = strpos( $url, '|' ); if ( $pos !== false ) { $url = substr ( $url, 0, $pos ); } $url = htmlspecialchars( $url ); if( $escape ) { $text = htmlspecialchars( $text ); } return '<a href="'.$url.'"'.$style.'>'.$text.'</a>'; }
usage
- Default behavior hasn't changed. Thus the following link should still open in the same window:
[http://en.wikipedia.org/wiki/Main_Page wikipedia main page]
- To open the same link in a new window, add _new or _blank to the link, separated from the link by a pipe:
[http://en.wikipedia.org/wiki/Main_Page|_new wikipedia main page in new window]
- Inside of a table, the pipe symbol must be put into a nowiki-tag:
[http://www.wikipedia.org<nowiki>|_new]</nowiki>
MediaWiki versions
tested in 1.6.6
tested in 1.8.3
The Newest Pages
The Newest Pages extension provides a flexible dual-use special page which lists the most recently created pages on the wiki. This code doesn't use the recentchanges table, and so items do not expire, as with Special:Newpages.
Requirements
The Newest Pages extension requires MediaWiki 1.6.0 or later.
Note
The developer and former maintainer of this extension, Rob Church, is no longer an active MediaWiki developer. The final version of this extension which can be considered released/approved by him is that of r23533. Users experiencing problems with the latest files may wish to try this version; this affects users of pre-1.11 wikis in particular.
Installation
- Check out all extension files from Subversion and place them in a NewestPages subdirectory within your MediaWiki extensions directory
- Add the line
require_once( "{$IP}/extensions/NewestPages/NewestPages.php" );
to your LocalSettings.php file
Installation can be verified through the Special:Version page on the wiki.
Usage
The list can be accessed as a conventional special page, or through inclusion into another page.
Special page
The special page is located at Special:Newestpages and provides a full interface to filter according to namespace, limit the number of results, and toggle the inclusion of redirect pages.
Inclusion
You can include a list of pages into another page using the inclusion mechanism, e.g.
:{{Special:Newestpages/User}}
will produce a list of the newest pages in the User namespace. To select the main namespace, use - as the namespace name, e.g.
:{{Special:Newestpages/-}}
You can also limit the number of results listed, e.g.
:{{Special:Newestpages/-/5}}
will produce a list of (at most) the five newest articles.
Customizing mediawiki for internal use
After Internet Librarian, ricklibrarian was jazzed up about using a wiki for an internal knowledge base. I should have called him “wiklibrarian.” So, last night I installed Mediawiki on the TFML website. I’ve done a few installs of Mediawiki which made this one fast and smooth.
What did, however, take a little bit of searching and a little bit of time was to find what I needed to add to LocalSettings.php to secure the site. Here’s what needed to be done, in order of security strength:
- Only registered users can comment
- Only registered users can see the wiki
- No non-user can register to be a user
This will allow for staff to post freely, and will keep the library’s internal business internal. To perhaps save you all some time, I’ll list here the code I added to LocalSettings.php to achieve the above results. This will give you a private wiki without having to mess with .htaccess or other authentication. Yay. Note: If you prevent user registration, you’ll have to pre-register people and give them usernames and passwords.
Stuff i'm adding (ADS) :
# This snippet prevents editing from anonymous users $wgGroupPermissions['*']['edit'] = false;
# This lists ages anonymous (not-logged-in) users may see (only the log-in) $wgWhitelistRead = array("Special:Userlogin", "-", "MediaWiki:Monobook.css" ); $wgGroupPermissions['*']['read'] = false;
# This snippet prevents anonymous users registering $wgGroupPermissions['*']['createaccount'] = false;
For the sake of transparency, a case could be made for having this wiki’s content open for all to see. In fact, I’m sure library users would enjoy browsing some of the sections like “Staff Recipes,” and “Sure fire books” in the YA section, but it might be best to start with it protected. If the content turns out to have any utility for the public, perhaps we could move to protecting only specific pages.