Mediawiki installation: Difference between revisions
m (using an external editor) |
m (using an external editor) |
||
Line 174: | Line 174: | ||
In addition one also could add more sophisticated custom items (instead of hand editing the skin files, to do ....) | In addition one also could add more sophisticated custom items (instead of hand editing the skin files, to do ....) | ||
== Subpages == | === Subpages === | ||
According to the [http://www.mediawiki.org/wiki/Subpages MediaWiki help pages] Subpages can be useful for three major purposes. | According to the [http://www.mediawiki.org/wiki/Subpages MediaWiki help pages] Subpages can be useful for three major purposes. |
Revision as of 11:11, 29 September 2011
I will describe here installation procedure of EduTechWiki and some extensions. We got a brand new server that we'll put online by the end of August:) - Daniel K. Schneider 11:59, 12 August 2009 (UTC)
See also:
- Older more chaotic installation hints can be found in ManageMediaWiki
- General information about MediaWiki and nice extensions can be found in the Mediawiki article
- Mediawiki collection extension installation (tips for the "PDF/Pediapress books extension)
- Semantic MediaWiki and Semantic Forms (some stuff about these very ambitious extensions)
- Category:Mediawiki documentation (everything)
Installation tips are for Ubuntu. The old version runs under Solaris (IMHO a superior but much more difficult environment, this is why we decided to switch).
First time installation
(To do, I will make this short, since it's not difficult...)
Configuration
The main configuration file
Unless you use some configuration extension, all the configuration (except for styles and user messages) is done in file LocalSettings.php (in the top-level directory of the distribution)
Reading: http://www.mediawiki.org/wiki/Manual:Configuration_settings
LocalSettings.php will read first the file includes/DefaultSettings.php and then override with your own settings. Below are a few settings (also read "nice URLs" below).
// also used as namespace for certain pages, so select with care
$wgSitename = "EduTech Wiki";
// Use the file cache
$wgUseFileCache = true;
$wgFileCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false;
// Rights
$wgEnableCreativeCommonsRdf = true;
$wgRightsPage = "EduTech_Wiki:Copyrights"; # Set to the title of a wiki page that describes your license/copyright
$wgRightsUrl = "http://creativecommons.org/licenses/by-nc-sa/3.0/";
$wgRightsText = "CC BY-NC-SA Licence";
$wgRightsIcon = "$wgStylePath/monobook/tecfa/somerights.png";
// Permissions - editing users need to have a login
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['createaccount'] = true;
# $wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['read'] = true;
// Strongly suggest to keep this (enabled by default). Puts all the messages in the database // (easier to edit and edits will survive upgrades $wgUseDatabaseMessages = true;
// What file uploads to you accept, e.g. $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ogg', 'pdf', 'mp3', 'svg', 'doc', 'xls', 'ppt', 'pub', 'txt', 'ps', 'zip' );
Messages
Configuring interface messages is quite easy. Use the following procedure, if you can't recall the names of the appropriate Mediawiki pages (each message is defined in its own page).
- List all messages with the special page Special:Allmessages
- You then can customize each Mediawiki message, by clicking on a message and edit
Notice:
- Works by default, i.e. $wgUseDatabaseMessages = true;
- If you are not using database messages, you can edit the languages/Language.php file (for English) or languages/LanguageXX.php for non-English languages, where XX is the two-letter language code for your language
- Be careful: entering wrong data may disable some messages ....
Each of the Mediawiki:XXX pages you may configure are listed in Special:Allmessages as we said above. The ones you did redefine will be in green. Below are two examples:
- A slogan message
The page MediaWiki:Sitesubtitle will allow you to add some sort of slogan (you also can kill this default page). Has the same effect as setting the $wgExtraSubtitle variable.
- Sitenotices (e.g. to annonce an important event)
Read: http://www.mediawiki.org/wiki/Manual:Interface/Sitenotice
Another way way of using it is to define $wgSiteNotice = " ........ "; in LocalSettings.php
Nice URLs
You don't want ugly default URLs (e.g. http://edutechwiki.unige.ch/en/Mediawiki_installation instead of http://edutechwiki.unige.ch/mediawiki/index.php?title=Mediawiki_installation).
Reading: http://www.mediawiki.org/wiki/Manual:Short_URL
Here is an easy way to do achieve this for the content pages. The method described below is probably not exactly the one that is now being suggested by the manual, but we have to stick to our old solution since we believe in stable URLS !
In httpd.conf:
Redirect /portails/mediawiki "http://edutechwiki.unige.ch/en" Redirect /mediawiki "http://edutechwiki.unige.ch/en" Redirect /portails/fmediawiki "http://edutechwiki.unige.ch/fr" <VirtualHost *:80> ServerName edutechwiki.unige.ch DocumentRoot "/data/portails/edutechwiki" # ALIASES for edutechwiki: THREE alias for each WIKI Alias /mediawiki "/data/portails/mediawiki" Alias /en "/data/portails/mediawiki/index.php" Alias /en/index.php "/data/portails/mediawiki/index.php" Alias /fmediawiki "/data/portails/fmediawiki" Alias /fr "/data/portails/fmediawiki/index.php" Alias /fr/index.php "/data/portails/fmediawiki/index.php" < /VirtualHost >
Then in LocalSettings.php:
$wgSitename = "EduTech Wiki";
$wgScriptPath = "/mediawiki"; $wgScript = "$wgScriptPath/index.php"; $wgRedirectScript = "$wgScriptPath/redirect.php";
## If using PHP as a CGI module, use the ugly URLs # $wgArticlePath = "$wgScript/$1"; # DKS 3/2006 $wgArticlePath = "/en/$1";
Therefore only "normal" pages look nice. Special pages remain ugly, but this doesn't matter IMHO.
Also consider excluding all or most special pages in robots.txt. No reason that these should be indexed and they really eat away CPU cycles if you need another argument.
User-agent: * Disallow: /mediawiki/ Disallow: /en/Special:Search Disallow: /en/Special:Random
etc ....
Skins and CSS
Unless you have time to spend, I suggest to use the standard Monobook skin. Other skins are not as well supported. E.g. some extensions just won't work with other skins.
You should define CSS (in particular class or id selectors for extensions) in MediaWiki:Common.css. Do not edit CSS files in the server if you can avoid. This strategy makes maintenance much easier.
Reading: Navigation bar help
Configuration: Edit MediaWiki:Sidebar in your wiki
Since version 1.14 (or earlier) you may use keywords to change the order of portlets (boxes with menu items). E.g.
* SEARCH * navigation and help ** mainpage|Mainpage ** EduTech_Wiki:About|about <!-- ** portal-url|portal --> <!-- ** currentevents-url|currentevents --> ** randompage-url|randompage ** helppage|Help ** Help:Editing rules|Editing rules ** Blog:DKS|Blog (D.K.S.) * categorytree-portlet * TOOLBOX * LANGUAGES * big brother ** Special:Newpages|New Pages ** recentchanges-url|recentchanges ** Special:Guestbook|Guestbook ** Special:Popularpages|Popular Pages ** Special:WhosOnline|Who is online ? * TECFA links ** http://tecfa.unige.ch/ |TECFA ** http://tecfaseed.unige.ch/door/ |TECFA Portal
In addition one also could add more sophisticated custom items (instead of hand editing the skin files, to do ....)
Subpages
According to the MediaWiki help pages Subpages can be useful for three major purposes.
- to create archives of old discussions under a talk page
- to create scratchpad editing spaces under a user page
- to create other language versions of a document in multilingual wikis
Slashes (/) within a page name break the page into parent and subpages, recursively
Avoid subpages for regular pages and for two reasons: It's against the wiki/hypertext philosophy and some crucial extensions (like the book creator) can't find them !
Read:
It you plan to enable supages everywhere, use:
# Enable subpages in all namespaces $wgNamespacesWithSubpages = array_fill(0, 200, true);
Else use something like:
$wgNamespacesWithSubpages = array( NS_TALK => true, NS_USER => true, NS_USER_TALK => true, NS_PROJECT_TALK => true, NS_IMAGE_TALK => true, NS_MEDIAWIKI_TALK => true,
NS_TEMPLATE => true,
NS_TEMPLATE_TALK => true, NS_HELP_TALK => true, NS_CATEGORY_TALK => true,
102 => true, 103 => true
)
Extensions
See also the Mediawiki article where we list extensions we find useful to have. Here, we only document installation and/or configuration of the more difficult ones.
Download and documentation: You will find most extensions on MediaWiki.org. The Extensions category page will provide several entry points. I sort of like the Extension_Matrix page.
General extension installation principles
Most extensions are well documented, just read the instructions and follow them. However, since some are badly maintained you sometimes will have to read the discussion page for finding appropriate patches...
A checklist of things to look at and to do:
(1) Check if the extension is compatible with your MW version (this is not always obvious, therefore you also should look for hints in its dicussion page).
(2) Read the discussion page that will tell you something about the quality of an extension.
(3) Download the extension either as archive (zip etc.) or via subversion. Some simple extensions are just available as code section from the wiki page that you must copy to a file.
- To use subversion you must install a client, then for example just type: svn co http:the_subversion_URL_of_the_extension'
- Make sure that the files sit in a directory unless its a simple single file extension
- Move the extension directory to the extensions folder of your installation
- Add all the extra stuff an extension may need. This can sometimes be a lot (e.g. a days work!), sometimes nothing). Most extensions are simple and don't need other server-side programs.
- If the extension needs a cache, you may have to change write permissions in some subdirectory.
- Load and configure:
- Edit LocalSettings.php to configure and to load the extension.
- You may have to define configuration variables in the LocalSettings.php file and/or by defining Mediawiki:XXX pages
- You may have the option to add CSS definitions to the MediaWiki:Common.css pages
- Sometimes you need to define templates.
Server modifications
Some extensions, e.g. the book creation tools need a lot of RAM and CPU. You may have to increase, e.g.
In php.ini:
max_execution_time = 600 max_input_time = 600 memory_limit = 100M
In httpd:conf:
Timeout 600
Collection extension
There exist two ways of using this PDF/OO/DocBook book generator. Just install the extension files and use the PediaPress server for generating the PDF or OO documents. This strategy did not work out well and we use our own server. Installation is fairly complex.
- Most important documentation and download pages
- Extension page Collection: http://www.mediawiki.org/wiki/Extension:Collection
- Extension page PDF_Writer: http://www.mediawiki.org/wiki/Extension:PDF_Writer
- MwLib/Collection server installation guide (if needed): http://code.pediapress.com/wiki/wiki/mwlib-install
- See Mediawiki collection extension installation for our own installation notes
Additional software needed if you install your own MwLib (at least)
- Dependencies
- Perl => 5
- g++
- Latex
- Also compile texvc in mediawiki/math directory
- Blahtexml
- Python => 2.5
- Python setuptools http://pypi.python.org/pypi/setuptools
- python imaging library (PIL) http://www.pythonware.com/products/pil/
- odfpy 0.7.0 http://odfpy.forge.osor.eu/
- rec2c
- ocaml
- Pygments
- Fribidi - both a library and the Python bindings
- The mwlib server and tools
PDFExport and PDF Book
Generate PDF for a page or all articles in a category page. These extensions use a free (and old version) of Htmldoc. The result is much inferior to what the collection extension can do, but it does have one advantage. Since it just translates the generated HTML to PDF, it will not loose any contents. The collection extension parses the raw wiki text and (for now) cannot handle formats such as ".dot" or "MetaUML".
- Most important documentation and download pages
- http://www.mediawiki.org/wiki/Extension:Pdf_Book
- http://www.mediawiki.org/wiki/Extension:Pdf_Export
- Additional installs
- Htmldoc
- Dependencies
- FLTK
Changes I made to the source of PdfBook.php (make pictures larger and add a title page):
$cmdext = " --browserwidth 1000 --titlefile $wgUploadDirectory/PDFBook.html"; $cmd = "htmldoc -t pdf --charset iso-8859-1 $cmd $cmdext $file";
Graphviz
This extension can generate graphs with the dot syntax.
- Most important documentation and download pages
- Extension page: http://www.mediawiki.org/wiki/Extension:GraphViz
- Additional installs: Graphviz from http://www.graphviz.org/Download.php plus needed libraries that you may or may not have on your server
- Dependencies
Graphviz itself needs several libraries like GD, Zlib, Freetype, PNG, JPEG, EXPAT, etc. (read http://www.graphviz.org/Download_source.php Requirements).
There exist binary packages for most systems (not yet tested)
Tag cloud
There are several tag cloud extensions, we use the following one (at the time of writing)
Extension page: http://www.mediawiki.org/wiki/Extension:WikiCategoryTagCloud
Extension page (old): http://wiki-tools.com/wiki/Wiki_Category_Tag_Cloud
Additional installs: None
Hints:
- If you want an accurate cloud, you should edit MediaWiki:Tagcloudpages and add the pages to invalidate the cache for.
UML extension
UML is an extension that allows to generate graphs from MetaUML format. This extension dates back to 2007, but still seems to work. MetaUML also was kind of sleeping, but seems to be an active project again (Aug 2009).
- Most important documentation and download pages
- Extension page: http://www.mediawiki.org/wiki/Extension:UML
- Additional installs
- MetaUML from http://metauml.sourceforge.net/
- Dependencies
- ImageMagick and Ghostscript
SVG visualization
See: Mediawiki SvGViz extension
Other extensions
As we said before, many extensions are really simple to install and don't need any difficult work. See the Special:Version page for the ones we currently use. Most extensions provide an URL that will directly lead you to the extensions download and documentation page.