MediaWiki bugs and solutions
From WhyNotWiki
Also includes some things that are not bugs per se, but are problems.
MediaWiki edit (Category edit)
Contents |
[edit] [Problems (category)]: Problems with titles
These problems appear to be well-documented here: http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(technical_restrictions) .
- Useful templates for dealing with the problem:
List of affected articles: Category:Articles for which MediaWiki won't let us use our desired title
Workaround: For articles for which MediaWiki won't let you give the title you want, you can encode your desired title with this template:
{{title is actually|svn_load_dirs.pl}}
[edit] Can't include # characters in titles
| Can't call it: | Comparison of Escape class and String#shell_escape |
|---|---|
| Had to settle for: | Comparison of Escape class and String.shell escape |
Workaround: I ended up duplicating the (auto) title with my own h1 ... just so I could provide some nicer formatting...
=Comparison of <code>Escape</code> class and <code>String#shell_escape</code>=
[edit] Can't include + characters in titles
I realize that + characters in URLs need to be escaped. But what escapes me is why it still doesn't work even when I escape it (as %2B)!
When I go to http://whynotaskwhy.com/wiki/C/C%2B%2B , the server responds with a redirect:
Location: http://whynotaskwhy.com/wiki/C/C
... which takes me to an edit page, since of course C/C doesn't exist.
Um...why? That's retarded.
Oh well. In the meantime (until this bug gets fixed -- or maybe it's a problem with my mod_rewrite rules??), I'll just rename it to C/C-plus-plus. Yummy.
It's also interesting that it let me create the article in the first place if it is in fact invalid. This was the URL used to create the article: http://whynotaskwhy.com/wiki/index.php?title=C/C%2B%2B&action=edit . It created it just fine. But now all links (which MediaWiki generates, and correctly -- with %2B -- I might add) do not work.
I can't move it, because the move link (shown on http://whynotaskwhy.com/wiki/index.php?title=C/C%2B%2B&action=edit) is to http://whynotaskwhy.com/wiki/Special:Movepage/C/C%2B%2B which, again, just redirected me to the un-urlencoded-URL (http://whynotaskwhy.com/wiki/Special:Movepage/C/C).
Fortunately, however, I could delete it (http://whynotaskwhy.com/wiki/index.php?title=C/C%2B%2B&action=delete).
[edit] Can't include formatting/styles in titles
| Can't call it: | Comparison of <code>Escape</code> class and <code>String.shell_escape</code> |
|---|---|
| Had to settle for: | Comparison of Escape class and String.shell escape |
Workaround: I ended up duplicating the (auto) title with my own h1 ... just so I could provide some nicer formatting...
=Comparison of <code>Escape</code> class and <code>String#shell_escape</code>=
[edit] Can't start a title with a lowercase letter
Sometimes one wants to have both a lowercase name and an uppercase version of the same name, because there can be a difference between them.
Examples: Unfortunately, we currently can't have both of these...
| A | B |
|---|---|
| internet | Internet |
| semantic web | Semantic Web |
In the meantime: Could just have a single article with separate page sections for each...
[edit] Problem: Page fragment identifier (anchor) is automatically named after the section heading text
But sometimes you might put some symbols or flags or tags or parenthetical remarks in the section heading text that you don't want included in the page fragment identifier (because it makes the identifier uglier, less user-friendly)...
For example, the fragment identifier created for this heading:
===** Whatever (the band)===
[edit] ** Whatever (the band)
is this lovely piece of URL-encoded beauty:
MediaWiki bugs and solutions#.2A.2A_Whatever_.28the_band.29
... when actually I'd like to be simple and just strip out any punctuation it can't handle.
MediaWiki bugs and solutions#Whatever_the_band
MediaWiki bugs and solutions#Whatever_(the_band) (What? () characters are totally allowed as page anchor names. Why does it try to URL-encode them for me then?)
Option 1: it could automatically strip out any punctuation it can't handle.
Option 2: it could let you override the default with whatever anchor name you want. (currently my preference)
Maybe this is already possible by just embedding an <a name="..."/> tag in the wikitext? ... Nope, it totally doesn't allow <a /> tags....
<a name="Whatever_the_band"/>
[edit] Problem: Can't view source if not logged in
The problem with that is that there are a lot wikis out there and I don't want to create a user account for each of them! Ignoring for the moment the fact that the real problem here (having to create a gazillion user accounts, one for every web site) could probably be solved with with OpenID... it seems like I ought to be able to view the source of a page without logging in. It's not like the source should be considered "private" ... should it? Unless there's some non-rendered wikitext (rather unlikely), then the wikitext itself should be no more private than the rendered output (which is not private at all).
Part of the problem is that MediaWiki uses the same action (index.php...&action=edit) to view source as to edit the page. Even if there were a "view source" link (there isn't one) on non-read-only pages, it wouldn't help any, because it would link to the same place as the "edit" link.
Proposed solution: Have a separate action for viewing source (action=view-source), which doesn't require logged-in permissions to use.
I like the way Wifty does it [1]:
You don't have permission to edit this page. Perhaps logging in would help. In the mean time, though, you're welcome to view and copy the source of this page.
Why do I care to see the source?
- Sometimes I want to quote a section of a wiki in my wiki and copying and pasting from the rendered output causes all formatting (and hyperlinks) to be lost. I don't want to re-add all that wiki markup by hand -- so it only makes sense to just copy and paste their source.
[edit] Problem: How do I make a multi-paragraph blockquote?
[edit] Workaround
You can do it like this, wrapping your blockquote in a div (or vice versa):
<blockquote> <div> paragraph 1 paragraph 2 </div> </blockquote>
Or prefixing each paragraph with : (instead of doing blockquote tag).
[edit] [Patch (category)] real solution
Solved by: http://bugzilla.wikimedia.org/show_bug.cgi?id=6200
My patch is based on http://bugzilla.wikimedia.org/attachment.cgi?id=2260&action=diff :
Index: includes/Parser.php
===================================================================
--- includes/Parser.php (revision 56)
+++ includes/Parser.php (working copy)
@@ -2134,10 +2134,12 @@
wfProfileIn( "$fname-paragraph" );
# No prefix (not in list)--go to paragraph mode
// XXX: use a stack for nestable elements like span, table and div
- $openmatch = preg_match('/(<table|<blockquote|<h1|<h2|<h3|<h4|<h5|<h6|<pre|<tr|<p|<ul|<ol|<li|<\\/tr|<\\/td|<\\/th)/iS', $t );
+ //{ Applied bug fix --Tyler
+ $openmatch = preg_match('/(<table|<h1|<h2|<h3|<h4|<h5|<h6|<pre|<tr|<p|<ul|<ol|<li|<\\/tr|<\\/td|<\\/th)/iS', $t );
$closematch = preg_match(
- '/(<\\/table|<\\/blockquote|<\\/h1|<\\/h2|<\\/h3|<\\/h4|<\\/h5|<\\/h6|'.
+ '/(<\\/table|<\\/h1|<\\/h2|<\\/h3|<\\/h4|<\\/h5|<\\/h6|'.
'<td|<th|<\\/?div|<hr|<\\/pre|<\\/p|'.$this->mUniqPrefix.'-pre|<\\/li|<\\/ul|<\\/ol|<\\/?center)/iS', $t );
+ //} Applied bug fix --Tyler
if ( $openmatch or $closematch ) {
$paragraphStack = false;
#Â TODO bug 5718: paragraph closed
(change spaces to tabs)
If it is patched, then this will work:
<blockquote> paragraph 1 paragraph 2 </blockquote>
paragraph 1
paragraph 2
[edit] Problem: PNG images aren't showing up on the page!
[Debugging stories (category)]
I viewed the source of the page for clues as to keywords to search for in the source...
My search soon took me to: ./includes/ImagePage.php
if ( $this->img->allowInlineDisplay() and $width and $height) {
...
$params['width'] = $width;
$thumbnail = $this->img->transform( $params );
./includes/Image.php
function canRender() {
$handler = $this->getHandler();
return $handler && $handler->canRender();
}
./includes/media/Generic.php
static function getHandler( $type ) {
global $wgMediaHandlers;
echo "\$type = $type";
if ( !isset( $wgMediaHandlers[$type] ) ) {
wfDebug( __METHOD__ . ": no handler found for $type.\n");
return false;
}
...
}
When I do that and visit the image page, I see $type = text/plain, which of course is not right.
./includes/DefaultSettings.php
/**
* Plugins for media file type handling.
* Each entry in the array maps a MIME type to a class name
*/
$wgMediaHandlers = array(
'image/jpeg' => 'BitmapHandler',
'image/png' => 'BitmapHandler',
'image/gif' => 'BitmapHandler',
'image/x-ms-bmp' => 'BmpHandler',
'image/svg+xml' => 'SvgHandler',
'image/vnd.djvu' => 'DjVuHandler',
);
Meanwhile, I also did some searching on the Web...
http://www.lunarpedia.org/index.php?title=Help:Maintenance_and_Setup
Why are all PNG files not being turned into thumbnails?After upgrading to a more recent version of PHP, it is possible a different MimeMagic.php function is being used to detect file MIME types, particularly the built-in PHP function mime_content_type, which fails to detect PNG files. Search the web for mime_content_type png for information on fixing this bug at the PHP level, possibly by editing your magic.mime file.
Contents of my /usr/share/magic.mime
#PNG Image Format 0 string \x89PNG image/png
Um, looks good to me... (?)
http://meta.wikimedia.org/wiki/Uploading_files
Q: Why do I get this error, what can I do? Is there something I can put into LocalSettings.php?Fatal error: mime_mMagic.php on line 506
A: Try adding the following line to the LocalSettings.php:
$wgMimeDetectorCommand = "file -bi";
While I'm not having the same symptom as they describe, the recommended solution might help me too...
http://www.google.com/search?q=wgMimeDetectorCommand
http://mywiki.ncsa.uiuc.edu/wiki/MediaWiki_Servers
Problems Rendering PNG ImagesIf png files don't render in wiki pages, then check the MIME type of the file by looking at the description page of the file. If it says text/plain, then try the following:
- Edit LocalSettings.php and add the following:
$wgMimeDetectorCommand = "file -bi";
- then rebuilding the images:
# cd <mediawiki_install_loc>/maintenance # php rebuildImages.php Processing image... Finished image... 3 of 4 rows updated Processing oldimage... Finished oldimage... 2 of 2 rows updated
http://hg.seoparts.com/dir/www.2emediawiki.2eorg/wiki/Manual:.24wgMimeDetectorCommand
Sets an external mime detector program. The command must print only the mime type to standard output. The name of the file to process will be appended to the command given here. If not set or NULL, the PHP function mime_content_type()willbeusedifavailable(PHP>=4.3.0).Example (Linux):
$wgMimeDetectorCommand = "file -bi"
Found in includes/DefaultSettings.php. Added to LocalSettings.php:
/** Sets an external mime detector program. The command must print only * the mime type to standard output. * The name of the file to process will be appended to the command given here. * If not set or NULL, mime_content_type will be used if available. */ #$wgMimeDetectorCommand= NULL; # use internal mime_content_type function, available since php 4.3.0 $wgMimeDetectorCommand= "file -bi"; #use external mime detector (Linux)
That seems to have fixed it!
I wonder what was up with PHP's mime_content_type function! (?)
Aliases: MediaWiki / Problems and solutions, MediaWiki / Bugs and solutions
