MediaWiki upgrade problems: Difference between revisions
No edit summary |
|||
| Line 1: | Line 1: | ||
== The Problem == | == The Compressed Output Problem == | ||
[[File:Kondor Fate compressed output.jpeg|thumb|400px|<div align="center">Unintelligible ASCII symbol characters after upgrade.</div>]] | [[File:Kondor Fate compressed output.jpeg|thumb|400px|<div align="center">Unintelligible ASCII symbol characters after upgrade.</div>]] | ||
My wiki is hosted on GoDaddy. I used Installatron to create the original installation. | My wiki is hosted on GoDaddy. I used Installatron to create the original installation. | ||
| Line 5: | Line 5: | ||
When I upgraded to version 1.35 and 1.36 of MediaWiki, all I saw on the welcome page was undecipherable strings of ASCII characters and symbols. The page was completely illegible and unintelligible. The image in the thumbnail is from a [https://discord.com/channels/178359708581625856/178361769750822912/796327619385753630 MediaWiki discussion on Discord.] | When I upgraded to version 1.35 and 1.36 of MediaWiki, all I saw on the welcome page was undecipherable strings of ASCII characters and symbols. The page was completely illegible and unintelligible. The image in the thumbnail is from a [https://discord.com/channels/178359708581625856/178361769750822912/796327619385753630 MediaWiki discussion on Discord.] | ||
== Solution for MediaWiki 1.35 upgrade == | === Solution for MediaWiki 1.35 upgrade === | ||
Disable output compression in ''LocalSettings.php'': | Disable output compression in ''LocalSettings.php'': | ||
| Line 14: | Line 14: | ||
</pre> | </pre> | ||
== Solution for MediaWiki 1.36 upgrade == | === Solution for MediaWiki 1.36 upgrade === | ||
If you already have an .htaccess file in the root folder of your MediaWiki installation, add this line to it: | If you already have an .htaccess file in the root folder of your MediaWiki installation, add this line to it: | ||
| Line 24: | Line 24: | ||
Or create an .htaccess file with that line. | Or create an .htaccess file with that line. | ||
I do not understand why ''$wgDisableOutputCompression'' was not sufficient. I had my 1.35 installation running side-by-side with the 1.36 installation. The two versions each had their own folder, but both connected to the same database through the configuration in ''LocalSettings.php''. 1.35 worked perfectly while 1.36 produced gobbledeygook | I do not understand why ''$wgDisableOutputCompression'' was not sufficient. I had my 1.35 installation running side-by-side with the 1.36 installation. The two versions each had their own folder, but both connected to the same database through the configuration in ''LocalSettings.php''. 1.35 worked perfectly while 1.36 produced gobbledeygook. | ||
== Loss formatting and images == | |||
It is essential that ''$wgScriptPath'' be set correctly. If not, the software can't find the image and skins folders. | |||
I am not sure how I caused this problem, but I saw it a couple of times while trying to solve the main problem of seeing encrypted content instead of a properly formatted wiki page. | |||
<pre> | |||
$wgScriptPath = '/mywiki'; | |||
</pre> | |||
[[Category:Wiki management]] | [[Category:Wiki management]] | ||
Revision as of 11:13, 5 June 2021
The Compressed Output Problem
My wiki is hosted on GoDaddy. I used Installatron to create the original installation.
When I upgraded to version 1.35 and 1.36 of MediaWiki, all I saw on the welcome page was undecipherable strings of ASCII characters and symbols. The page was completely illegible and unintelligible. The image in the thumbnail is from a MediaWiki discussion on Discord.
Solution for MediaWiki 1.35 upgrade
Disable output compression in LocalSettings.php:
## Uncomment this to disable output compression $wgDisableOutputCompression = true;
Solution for MediaWiki 1.36 upgrade
If you already have an .htaccess file in the root folder of your MediaWiki installation, add this line to it:
SetEnv no-gzip 1
Or create an .htaccess file with that line.
I do not understand why $wgDisableOutputCompression was not sufficient. I had my 1.35 installation running side-by-side with the 1.36 installation. The two versions each had their own folder, but both connected to the same database through the configuration in LocalSettings.php. 1.35 worked perfectly while 1.36 produced gobbledeygook.
Loss formatting and images
It is essential that $wgScriptPath be set correctly. If not, the software can't find the image and skins folders.
I am not sure how I caused this problem, but I saw it a couple of times while trying to solve the main problem of seeing encrypted content instead of a properly formatted wiki page.
$wgScriptPath = '/mywiki';