![]() |
Error messages and solutions.
See also:
- 1 Call to a member function getPrefixedDBkey() on a non-object
- 2 Cannot use an & in a page title
- 3 Visiting anything gives a blank page
- 4 A page with a gallery item gives a blank page
- 5 Other MediaWiki Issues
- 5.1 Internal Error — The upload directory (public) is not writable by the webserver.
- 5.2 Saving or previewing says “Forbidden”
- 5.3 Could not rename file
- 5.4 Database error
- 5.5 Internal Error — Could not copy file (/images/temp)
- 5.6 The file you uploaded seems to be empty.
- 5.7 Saving a page gives a preview instead
- 5.8 The upload directory ($/images) is not writable by the webserver.
- 5.9 Endless “Please set up the wiki first.” loop
- 5.10 Error creating thumbnail: Unable to create destination directory
- 6 PHP errors
- 7 MediaWiki upgrading MySQL4 to MySQL5 gives “Specified key was too long”
- 8 MediaWiki 1.11.0 breaks the login link
- 9 Logging in or previewing pages prompts to download index.php
Call to a member function getPrefixedDBkey() on a non-object ∞
Fatal error: Call to a member function getPrefixedDBkey() on a non-object in /path/to/htdocs/includes/parser/Preprocessor_DOM.php on line 994
A known issue with DynamicPageList: https://followthescore.org/dpldemo/index.php?title=Issue:Call_to_a_member_function_getPrefixedDBkey%28%29_on_a_non-object [ 1 ] was https://followthescore.org/dpldemo/index.php?title=Issue:Call_to_a_member_function_getPrefixedDBkey()_on_a_non-object
- MediaWiki 1.13.0
-
DynamicPageList 1.7.4
Solution?: I updated to MediaWiki 1.14.0 and followed no special patch procedure and everything seemed to be working fine, but now when visiting a page which has a DynamicPageList usage, I get:
Fatal error: Call to a member function getPrefixedDBkey() on a non-object in /path/to/htdocs/includes/parser/Preprocessor_DOM.php on line 996
No solution is known.
Cannot use an & in a page title ∞
Visiting the page truncates the title and shows a blank page.
This is a problem with your rewrite rules. Apache unescapes the string, including the ampersand, so when you place it into the query string it counts as two separate parameters.
To avoid this you can:
- Use an Alias directive instead of mod_rewrite; this is the simplest in most cases.
-
Use the
ampescapepatch to Apache (inmaintenance/) to add a rewrite modifier function which can properly re-escape the ampersand.
Visiting anything gives a blank page ∞
<html><body></body></html>
Verify you have correct versions of MySQL and PHP as required by your MediaWiki version.
If MediaWiki or extension PHP code exits with an error, such as a syntax error in the sourcecode, you may get nothing at all – not even the <html> headers. This is common when developing or installing new code; see your web server’s error_log file to find the specific cause of the error.
If correct no solution is known.
- Second sighting:
I saw this when upgrading my installation. I deleted LocalSettings.php and set things up again and it works.
There is crap in your LocalSettings.php .. the most common culprit will be a misbehaving addon. Try disabling them one by one.
I saw this with the recaptcha extension.
A page with a gallery item gives a blank page ∞
This one was caused by some World of Warcraft screenshots. I’m not sure what’s going on with this one..
I’ve seen this before, and it’s been solved by editing the picture(s) and re-saving them. This must have something to do with the graphic being odd enough to cause problems with the server imaging software so when it tries to create the thumbnail it explodes.
Other MediaWiki Issues ∞
Internal Error — The upload directory (public) is not writable by the webserver. ∞
a solution is not known!
1.11.1
It’s a permissions issue on your /images directory.. if you did a recent upgrade make sure you did the proper chown to set things up right.
Something like:
chown --reference=LocalSettings.php * -R
This doesn’t work, but then I do:
chmod 777 images/* -R
Now I get Could not rename file. One contributor says:
Make sure your LocalSettings.php setting is correct:
$wgUploadDirectory = "$IP/images";
The $IP variable resolves to your mediawiki installation directory. The images directory is the one found within that directory (i.e. /mediawiki/images) and should be writable by the user the web server is running as.
Saving or previewing says “Forbidden” ∞
a solution is not known!
1.11.1
Forbidden You don't have permission to access /index.php on this server. software/version (OS) Server at example.com Port 80
I’ve reproduced the problem with these strings:
- The string
/tmp/phpcauses this on v1.11.1 - wget (with no characters before/after it)
nmap(with a space after it)-
to:(with two spaces after it)
This has nothing to do with SSL or non-SSL encryption. BUT…
This section is previewable:
example.com/index.php?title=some_page/subpage&action=edit§ion=15 non-SSL
And yet this is not!:
example.com/index.php?title=some_page/subpage&action=edit§ion=15 SSL
And I’ve also seen this problem with sections of text which preview fine but don’t save.
I’ve seen this with large pages.
I’ve also seen this happen INCONSISTENTLY with certain pages. I’d try again and it would work the second try with the exact same content / length of content. It’s frustrating..
Try editing this link:
example.com/index.php?title=some_page/subpage&oldid=12345
try editing this page, and copying its content into a new one. It won’t work, but it’ll work if you copy it piece-by-piece:
example.com/some_page/subpage
I believe this is a server and server security issue, and not a MediaWiki issue.
1.12.0
I’ve seen this come and go with no explanation.. I’ll just keep re-trying and it might eventually work.
At this point in testing, I’ve been plagued with a bad net connection so perhaps that’s related.
Could not rename file ∞
a solution is not known!
1.11.1
[[MediaWiki:Filerenameerror]]
Internal error Could not rename file "<you>/images/e/e6/<file>" to "<you>/images/archive/e/e6/<file>".
It’s a permissions issues accessing your <you>/images/archive/e/e6/ folder. Check ownership and such.
One contributor has a suggestion. See Internal Error — The upload directory (public) is not writable by the webserver.
Database error ∞
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "SearchMySQL4::update". MySQL returned error "1016: Can't open file: 'searchindex.MYI' (errno: 145) (localhost)".
Repair the searchindex table.
1. Login to MySQL command prompt
2.
REPAIR TABLE searchindex
Internal Error — Could not copy file (/images/temp) ∞
Could not copy file "/tmp/phpS46WOS" to "<you>/images/temp/a/ae/<file>"
It’s a permissions issue accessing your /images/temp/ folder. Check ownership and such.
v1.6.8: The directory didn’t exit. I made it and set all the permissions various ways, and uploading still doesn’t work..
I’ve also heard that this could be an issue with PHP “safe mode” being on. Only a new installation would tell you this. It’s sad that this error message isn’t expanded into a set of tips.
The file you uploaded seems to be empty. ∞
[[MediaWiki:Emptyfile]]
The file you uploaded seems to be empty. This might be due to a typo in the file name. Please check whether you really want to upload this file.
; Maximum allowed size for uploaded files. upload_max_filesize = 2M # Note: post_max_size =<Number>M # https://meta.wikimedia.org/wiki/Uploading_files # Safe mode will not permit you to create new files in directories # which have different owner than the owner of the script. That is, # in safe mode, images/archive, images/thumb and images/temp must be # owned by the user that also owns the apache process. # If not set, the system default is used, which isn't appropriate since # the system default (/tmp) won't have the right privilages. upload_tmp_dir = /tmp/http
Also:
mkdir /tmp/http chmod 777 /tmp/http
Saving a page gives a preview instead ∞
I’ve faced this problem before. One time I just rebooted (or rather the filesystem aborted after the HD became read only on its own — long story) and things are working fine again.
1.5 has a feature to do this on purpose, but it is turned off.
The upload directory ($/images) is not writable by the webserver. ∞
Using XAMPP on Windows XP.
In LocalSettings.php, you remove the “$/” from the $wgUploadDirectory setting, so it reads:
$wgUploadDirectory = "images";
This was probably a problem with “$/” which perhaps should have been “$\“.
Endless “Please set up the wiki first.” loop ∞
This is seen on a new installation or an upgrade.
Solution: Check your file permissions. If you’re overwriting your mediawiki files with the new files then check the ownership. You may have to do some kind of:
chown user:group * -R
.. overtop of the entire directory. Maybe just try:
chown --reference=LocalSettings.php * -R
Error creating thumbnail: Unable to create destination directory ∞
I deleted my LocalSettings.php and did a new config, using my old wiki. Now I get this error.
Solution:
php maintenance/rebuildImages.php
PHP errors ∞
Fatal error: Allowed memory size ∞
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 80629 bytes) in /path/to/htdocs/includes/Parser.php on line 206
While editing pages with lots of content.
php.ini – increase the memory limit from 8M, like:
memory_limit = 20M
or edit .htaccess with something like:
php_value memory_limit 20M
MediaWiki upgrading MySQL4 to MySQL5 gives “Specified key was too long” ∞
mysql Ver 12.22 Distrib 4.0.25, for pc-linux-gnu (i686) mysql Ver 14.12 Distrib 5.0.46, for redhat-linux-gnu (i686) using readline 5.0
Just do a regular dump, no special switches. Ignore all that crap about the character set that you might find out there.
Try importing the dump file, and get the error. I get this:
ERROR 1071 (42000) at line 121: Specified key was too long; max key length is 1000 bytes
I went to line 121 and deleted that block of code. It had something to do with links. The import works fine, and all my pages are there and are healthy.
I then did a complete upgrade from mediawiki 1.6.10 to 1.10.1 as well as an upgrade from php 4 to 5.1.6 .. so basically everything got upgraded, and it did work. Sigh, this was rough to figure out.
notes:
- bug 4541 with a status of “we hate our users”
- https://wiki.gentoo.org/wiki/MySQL/Migrate_to_5.0 — ungh, too tough.
-
Importing with a different character set might work, but it would also potentially obliterate some information. YAY!
MediaWiki 1.11.0 breaks the login link ∞
Simplifying rewriting doesn’t help.
I have no clue what’s going on. Sigh.
—
I later fiddled around and got it working again with 1.11.1 but I don’t remember what I did.
Logging in or previewing pages prompts to download index.php ∞
It turned out to be an issue with Firefox. I recently updated my PCLinuxOS system and just continued using Firefox. Rebooting solved this problem.


ported