Mediawiki: Difference between revisions

From miki
Jump to navigation Jump to search
Line 1: Line 1:
== Install ==
=== Install on Debian ===
MediaWiki is available as a regular package. This is the recommendation way to keep security patches up-to-date:

<source lang=bash>
sudo apt install mediawiki
</source>

=== Install a 2nd wiki on Debian ===
On debian, the mediawiki installed with the package is installed in {{file|/var/lib/mediawiki}}. This folder contains many symlinks to the package files in {{file|/usr/share/mediawiki}} directories.

We can create a second mediawiki instance, but it needs some copy and clean up. Let's assume we want to create a second wiki instance at {{file|/var/lib/mediawiki-bis}}.

* We basically copy everything in {{file|/var/lib/mediawiki}}, preserving existing symlinks.
* We clean up folder {{cache}}.
* We clean up folder {{config}}.
* We clean up folder {{images}}.
* We clean up folder {{upload}}.
* We delete {{file|LocalSettings.php}}.
* We start installation again.
* Install {{file|LocalSettings.php}} in {{file|/etc/mediawiki}} and symlink to it

<source lang=bash>
mkdir /var/lib/mediawiki-bis
cd /var/lib/mediawiki-bis
cp -rp /var/lib/mediawiki/* .
rm -rf cache/*
rm -rf config/*
rm -rf images/*
rm -rf upload/*
cp /var/lib/mediawiki/images/README images/
rm LocalSettings.php
# ... Run install via browser, and copy LocalSettings to /etc/mediawiki/LocalSettings-bis.php
ln -sf /etc/mediawiki/LocalSettings-bis.php LocalSettings.php
</source>

;Troubleshoot
* If during install, script detects that a mediawiki instance is already running, just temporarily rename file {{file|/etc/mediawiki/LocalSettings.php}}.

== Hints and Tips ==
== Hints and Tips ==
=== Purge wiki page cache ===
=== Purge wiki page cache ===

Revision as of 00:16, 28 December 2017

Install

Install on Debian

MediaWiki is available as a regular package. This is the recommendation way to keep security patches up-to-date: 

sudo apt install mediawiki

Install a 2nd wiki on Debian

On debian, the mediawiki installed with the package is installed in /var/lib/mediawiki. This folder contains many symlinks to the package files in /usr/share/mediawiki directories.

We can create a second mediawiki instance, but it needs some copy and clean up. Let's assume we want to create a second wiki instance at /var/lib/mediawiki-bis.

  • We basically copy everything in /var/lib/mediawiki, preserving existing symlinks.
  • We clean up folder Template:Cache.
  • We clean up folder Template:Config.
  • We clean up folder Template:Images.
  • We clean up folder Template:Upload.
  • We delete LocalSettings.php.
  • We start installation again.
  • Install LocalSettings.php in /etc/mediawiki and symlink to it
mkdir /var/lib/mediawiki-bis
cd /var/lib/mediawiki-bis
cp -rp /var/lib/mediawiki/* .
rm -rf cache/*
rm -rf config/*
rm -rf images/*
rm -rf upload/*
cp /var/lib/mediawiki/images/README images/
rm LocalSettings.php
# ... Run install via browser, and copy LocalSettings to /etc/mediawiki/LocalSettings-bis.php
ln -sf /etc/mediawiki/LocalSettings-bis.php LocalSettings.php
Troubleshoot
  • If during install, script detects that a mediawiki instance is already running, just temporarily rename file /etc/mediawiki/LocalSettings.php.

Hints and Tips

Purge wiki page cache

When changing templates, purge the browser & mediawiki cache. To purge the cache of a single page, add &action=purge to the URL (see [1] for more)

Increase default font size

The easiest way is to add the following to wiki common stylesheet (MediaWiki:Common.css): 

/***** Increase default text size ****/
#content {font-size: 1.2em}
body.page-Main_Page #content {font-size: inherit}

The second line overrides effect of first line so that the new font size does not apply to the Main Page.

There are in fact several ways to increase the font size. Using Opera's DragonFly debug environment (Ctrl-Shift-I), it is easy to see how the font size of a normal wiki text is computed (css is filtered for property font-size): 

Computed Style
    font-size: 15.36px;

Inherited from div
#bodyContent {
    font-size: 0.8em
}

Inherited from div
#content {
    font-size: larger
}

Inherited from body
body {
    font-size: 1.0em
}

Inherited from html
html {
    font-size: 1.0em
}

Note that em refers to the size of the current font, after application of all inherited styles. In the case above it means that the size of a standard wiki text is not 0.8em as given by div#bodyContent, but well 16px * 1.0 * 1.0 * 1.2 * 0.8 = 15.36px.

One can edit any CSS property above to change the default size of the wiki text. We choose to edit #content so that it only affects the wiki text part (including first header).

Keyboard shortcuts

  • Reference page in wikipedia
  • Page explaining how to change keyboard shortcut using user custom stylesheet.
  • Most frequently-used HTML access keys (default access-key shortcut is alt+shift for Firefox and shift+Esc for Opera):
Action Key
accesskey-edit e
accesskey-preview p
accesskey-save s
accesskey-search f

Access Restriction

See these pages for implementing access restriction in MediaWiki:

  • A page that implement per-page access restriction [2].
  • Another way to hide pages [3].
  • Yet another extension [4].
  • Security problem with access restriction extension:
  • Some information on how to create custom namespaces [7].

Miscellaneous

Page Special:Version
produces a complete list of all extensions installed on the wiki.

Troubleshooting

Fix templates that always produce {{{1}}}

Update
No longer an issue on recent MW apparently (at least >=1.27).

Templates in Mediawiki will fail if the parameters contains an equal sign. Consider for instance the template nb: 

<div class="noborder">
{{{1}}}</div>

Let's enclose a <source> tag:

{{nb|<source lang=bash>echo Hello</source>}} 
echo Hello

The fix is simply to prepend 1= to the parameter value:

{{nb|1=<source lang=bash>echo Hello</source>}} 
echo Hello

Tag attributes not expanded in templates

To have tag attributes expanded in wiki templates (in particular when these attributes contain template parameters), use the special construction {{#tag:tagname|content|attr1=val1|attr2=val2}}. See also #tag magic word and bugzilla 61341 for more information.

This is used in template Template:Rawfiledownloadexample: 

You can download file "{{{name}}}" below, just click this link: {{#tag:file|{{{name}}}|name={{{name}}}|tag=pre}}.
{{#tag:pre|{{{content}}}}}

The example 

{{Rawfiledownloadexample|name=myfile.txt|content=Once upon a time
There was a Tag
Tag was clickable
And clicked it was}}

expands into to the following with action ?action=raw&templates=expand: 

You can download file "myfile.sh" below, just click this link: <file|name="myfile.sh" tag="pre">myfile.sh</file>.
<pre>Once upon a time
There was a Tag
Tag was clickable
And clicked it was</pre>

Can't upload file

Error message: 

Could not create directory mwstore://local-backend/local-public/ when Uploading.

The problem is due to wrong ownership / permission in mediawiki folder [8]: 

sudo chown -R www-data /var/www/mediawiki

MediaWiki for developers

References
Tips
  • In 99% of cases, extensions just need to use the method recursiveTagParse of the parser instead of Parser::parse (apparently this function is not re-entrant).

Debugging

To see PHP errors, add to LocalSettings.php (or can also edit php.ini or .htaccess Mediawiki - How to debug): 

error_reporting( -1 );
ini_set( 'display_errors', 1 );

Globals

Some global variables defined by Mediawiki. Note that to use these variables, we must first declare them as global: 

global $wgExtensionAssetsPath;
Name Default Description
$IP MW_INSTALL_PATH env var IP stands for Install Path. The variable holds the local file path to the base installation of your wiki.
$wgScriptPath /wiki The base URL path (in relation to DOCUMENT ROOT).
$wgExtensionAssetsPath {$wgScriptPath}/extensions URL to extensions directory. Used to provide a base URL for extension assets like extension-specific images and scripts. Note the difference between
  • $IP/extensions (points to the extensions directory on the server filesystem) and
  • $wgScriptPath/extensions (points to the URL of the extensions directory).

Modules

ResourceLoader

References
Quick walkthrough, registering modules, etc.
Add a CSS style module
For instance, from Extension::Cite
$wgHooks['BeforePageDisplay'][] = 'wfCiteBeforePageDisplay';
$wgResourceModules['ext.rtlcite'] = array(
	'localBasePath' => __DIR__ . '/modules',
	'remoteExtPath' => 'Cite/modules'
	'styles' => 'ext.rtlcite.css',
	'position' => 'top',
);

function wfCiteBeforePageDisplay( $out, &$sk ) {
	$out->addModuleStyles( 'ext.rtlcite' );
	return true;
}
In the following example we add the module only if a tag is present
$wgHooks['ParserFirstCallInit'][] = 'onParserSetup';
$wgResourceModules['ext.fentt'] = array(
    // ...
);
static function onParserSetup( Parser $parser ) {
    $parser->setHook( 'fentt', 'renderFenTT' );
}

$module_added = false;
function renderFenTT( $input, array $args, Parser $parser, PPFrame $frame ) {
    global $module_added;
    if( ! $module_added ) {
        $parser->getOutput()->addModuleStyles('ext.fentt');
        self::$module_added = true;
    }
    // ...
}
Troubleshoot
  • Module is listed in the <head> element, but corresponding CSS/JS does not appear in downloaded content
Try to register the module (add to $wgResourceModules) at global level (i.e. not in the hook handle function that calls $addModuleStyles).

Hooks

How-To

Add an extension stylesheet in HTML head element

The goal is to add a stylesheet <link> tag in the HTML <head> element, either ALWAYS or CONDITIONALLY, and/or STATIC link or DYNAMIC link (from page content). 

<head>
  ...
  <link rel="stylesheet" href="..." />
  ...
</head>
Criteria
  • Must work with recent MW version, and use stable API.
  • Must be page-caching friendly.
  • If link is added conditionally, avoid parsing twice the page content. Can we use some context information?
Relevant hooks
Relevant example extensions
list of extensions designed to modify information in the HTML <head> element
For MW 1.16.x and above. Use hook RawPageViewBeforeOutput to sanitize CSS, and ParserFirstCallInit to add a head item with $parser->getOutput()->addHeadItem( $headItem );.
For MW 1.16+. Use a ParserFirstCallInit hook, then add a <style> element using $wgParser->mOutput->addHeadItem when it encounters a <css> tag. Looks an excellent candidate for our stuff!
Inserts <script> (i.e. Javascript) or <link> (i.e. CSS) code at the bottom of the page's head or within the page's body. Securely inserts arbitrary code to the page's head using <addtohead>.
For MW 1.10, 1.11. Likely too complex for our use. Insert a metatag as an HTML comment, which is then parsed again (via preg_match_all) in OutputPageBeforeHTML hook.
Found simply by ... looking for .css files in MW extensions/ directory!
Uses hooks ParserFirstCallInit (to register parser hooks for Cite tags like <ref>) and BeforePageDisplay (to add modules, including the call to addModuleStyles). But... checking the page source it turns out that Cite css file is *always* loaded by the dynamic resource loader, even when the tag is not used on the page. Is that a problem?
Troubleshooting
  • $parser->getOutput()->addHeadItem( "..." ) not working on mobile device.
It works on desktop, on my tablet, but not on my smartphone. Why?
The fix is to load the module with addModuleStyles()($modules), as done for instance in Extension:Cite
Questions
  • On Wikimedia, there is a link at the bottom to toggle between mobile / desktop view. Handy to test a site in mobile mode. How can we get it installed? By upgrading to the latest MW? or installing Mobile extension
The Solution
if (defined('MEDIAWIKI')) {
    $wgHooks['ParserFirstCallInit'][] = 'MWFenTT::onParserFirstCallInit';

    $wgResourceModules['ext.FenTT'] = array(
	    'localBasePath' => __DIR__,
	    'remoteExtPath' => 'FenTT',
	    'styles'        => 'FenTT.css',
	    'position'      => 'top',
    );

    class MWFenTT {
        private static $css_module_added = false;

        static function onParserFirstCallInit( Parser $parser ) {
            // Register parser handler for tag <fentt>
            $parser->setHook( 'fentt', 'MWFenTT::renderFentt' )
        }

        static function renderFentt( $input, array $args, Parser $parser, PPFrame $frame ) {
            if( ! self::$css_module_added ) {
                // Tell ResourceLoader that we need our css module
                $parser->getOutput()->addModuleStyles( 'ext.FenTT' );
                self::$css_module_added = true;
            }
            return FenTT::renderFentt($input,$args);
        }
    }
}

Extensions

MediaWiki for Mobile

References
CSS

Extensions for Mobile

See also Writing a MobileFrontend friendly ResourceLoader module

Administration

Delete a page permanently

This procedure allows for permanently deleting a page from the wiki database, including the whole history. After this, there will be no trace left of the content of that page, except for a trace in the delete log indicating the date when the page was deleted and the reason (if any given).

  • First, as admin user, go to the page to delete.
  • In the menu, select 'Delete', select and type in a reason, then click "Delete page".
From now on, the page is deleted, but history is still in the database. Deletion can be reverted by going to the delete log page (Special:Log/delete)
  • On the wiki server, run the maintenance script named deleteArchivedRevisions.php. This will permanently delete the page history from the wiki db.
cd /var/lib/mediawiki/maintenance
php ./deleteArchivedRevisions.php --delete

Upload lots of file at once

Use local command importImages.php [9]. 

php maintenance/importImages.php --comment "Rubik's cube position, better perspective" /opt/www/daemenj/web/kiwi.noekeon.org/miki/rb png

Or to force a specific user: 

sudo -u www-data php maintenance/importImages.php --comment "Rubik OLL cases, from http://www.cubewhiz.com/oll.php" tmp/
Retrieved from "https://miki.immie.org/mediawiki/index.php?title=Mediawiki&oldid=9909"