Project:Support desk

Jump to navigation Jump to search

About this board

Welcome to the MediaWiki Support desk, where you can ask MediaWiki questions!

(Read this message in a different language)

See also

Other places to ask for help:

Before you post

Post a new question

  1. To help us answer your questions, please indicate which versions you are using, as found on your wiki's Special:Version page:
    • MediaWiki version
    • PHP version
    • Database type and version
  2. Please include the web address (URL) to your wiki if possible. It's often easier for us to identify the source of the problem if we can see the error directly.
  3. To start a new thread, click "Start a new topic".

MediaWiki Installation Shows Only Random Alphanumeric Characters

JamesGreenWY (talkcontribs)

My installation of MediaWiki 1.36 shows only random alphanumeric characters on every page whenever I access any page.

I saw this topic with the same problem Topic:W1n42n5jvaahw9wy but it seems like there wasn't a solution referenced on this page.

$wgDisableOutputCompression was suggested as having something to do with it, but I've tried every version of this comment multiple times and it doesn't change anything.

I have rechecked my local settings.php file multiple times, reinstalled MediaWiki (trying different versions such as 1.31 besides 1.36 but I'm still getting the same problem.

Could it be something to do with my PHP installation or with Namecheap hosting?

Link to what I see here or image of it



Malyacko (talkcontribs)

Works without a problem in Firefox, so this is indeed $wgDisableOutputCompression. What does "every version of this comment multiple times" mean? What exactly *did* you do and where, without paraphrasing?

Reply to "MediaWiki Installation Shows Only Random Alphanumeric Characters"

Accessing the wiki with ZeroTier

Magibon-san (talkcontribs)

I am trying to access my wiki running on XAMPP with ZeroTier. I have changed its address $wgServer in LocalSettings.php from localhost to the address ZeroTier gave me, but the wiki's main page still seems to be running on localhost. Some pages point to the IP address but ultimately time out. How should I proceed?

Tanbirzx (talkcontribs)

What is the main problem of your wiki's main page? Please notify that.

Magibon-san (talkcontribs)

Currently, the wiki opens up as normal at localhost (although the ZeroTier address is set). Sometimes a setup.php error appears on the main page but I can't reproduce it at the moment. Interestingly, when I click "Printable version" in the sidebar, on the very bottom of the print preview it shows the proper address.

Bawolff (talkcontribs)

Is apache (or whatever web server) setup to listen on the zerotier ip? Can you verify that your computer is actually accessible from that ip?

Magibon-san (talkcontribs)

Yes. It still does not work. Wiki just times out. Any other server I create using that IP works just fine.

Bawolff (talkcontribs)

to me this sounds like something wrong on a layer below mediawiki. Try and see if the tcp connection actually is succesfully established.

Reply to "Accessing the wiki with ZeroTier"
NGC 54 (talkcontribs)

I try to install MediaWiki 1.36.0, and I receive this error:

MediaWiki 1.36 internal error

Installing some PHP extensions is required.

Required components

You are missing a required extension to PHP that MediaWiki requires to run. Please install:

Malyacko (talkcontribs)

What is unclear with the error message and its instructions?

NGC 54 (talkcontribs)

What instructions? I have already installed MediaWiki 1.35.0 and 1.35.1, and I did not received this error.

Majavah (talkcontribs)

As noted in the MediaWiki 1.36 upgrade notes, 1.36 and newer require the php intl extension. What instructions? "You are missing a required extension to PHP that MediaWiki requires to run. Please install: intl".

NGC 54 (talkcontribs)
Malyacko (talkcontribs)

Which exact operating system is running on that machine?

NGC 54 (talkcontribs)

MediaWiki files are installed on my computer, that uses a version of Windows 10.

NGC 54 (talkcontribs)
Jonathan3 (talkcontribs)

This is from my notes of setting up an Ubuntu 18.04 Digital Ocean VPS recently:

sudo apt install php-intl

I think after that you need:

sudo systemctl restart apache2 (talkcontribs)

Similar issue here, intl is installed, but WikiMedia does not recognize it as such. Extension is enabled in php.ini, extension dir is set correctly, other extension prerequisites that wikimedia reported run fine, but intl does not. (talkcontribs)

Even though intl is installed, wikimedia reports the extension as missing. Does it need a default_locale?


Internationalization support => enabled

ICU version => 68.1

ICU Data version => 68.1

ICU Unicode version => 13.0

Directive => Local Value => Master Value

intl.default_locale => no value => no value

intl.error_level => 2 => 2

intl.use_exceptions => Off => Off

Bawolff (talkcontribs)

check if its enabled on the webserver. Whether intl is enabled in commandline php is separate from if its enabled on the webserver.

Reply to "intl"

How do I redirect a MediaWiki page to a folder with html?

Wikedneeded (talkcontribs)
Malyacko (talkcontribs)

@Wikedneeded That extension does not require redirecting some MediaWiki page to make that extension work. What makes you think so?

Reply to "How do I redirect a MediaWiki page to a folder with html?"
George Ho (talkcontribs)

Five or ten minutes ago, the project sites connected to the server weren't working properly. Meanwhile, the Internet in my area overall has been fine. Right now, I'm able to connect Wikipedia and other projects. What went wrong with the servers or whatever?

Malyacko (talkcontribs)

Hi, this is the support desk for the MediaWiki software. In case you refer to some Wikimedia websites (?), then feel free to ask on meta:Tech or IRC or such if you have good reasons to think that something wasn't "working properly" (whatever that means) server-side.

Bawolff (talkcontribs)
Reply to "Timed out connection?" (talkcontribs)

Hello, I have been using wiki for a short time with the intention of having a collective creation space for 7 people.

This month it has been hacked and there are more than 18 thousand users who upload hundreds of pages of irrelevant content.

What do I do to?:

1 Retrieve my content

2 Eliminate the rubbish introduced

3 Prevent new users with or without registrations from uploading content

Thanks for the help

Bawolff (talkcontribs)

as an aside, getting spammed and getting hacked are different things.

There is some advice on manual:combatting spam

Reply to "hacked" (talkcontribs)

A wikitia page was created from a draft wikipedia page of mine. Is there a way to delete the wikitia page as we ended up deleting the wikipedia draft.

thank you

TheDJ (talkcontribs)

Have you tried contacting wikitia ? While they might run MediaWiki, the MediaWiki software, nor Wikipedia are affiliated in any sort of way with wikitia. (talkcontribs)

Thanks. Let me try. I haven't been able to figure out how to contact them.

Reply to "Delete Page"

Doubt with #if function

Summary by Jonathan3

{{!}} for |

MauCavans (talkcontribs)

Sorry if this is a stupid question, but I'm kinda new to mediawiki and couldn't find any useful info online.

I created a simple template, and wanted to make it so, when the first field is empty ({{{1|}}}), both colums are merged into one, showing "N/A".

Can't use colspan because of the #if funcion, and <span> doesn't seem to work either, acting only on the word and not on the whole field.

Here's an example on what the template looks like at the moment:

{| width="100%" class="sortable" style="text-align:center; background: #e1e1e1; border:3px solid #5b5a5a"

|- ! colspan="2" | Name |-

| style="background:#FFF" width="50%" | {{#if {{{1|}}}| {{{1|}}} | N/A}}

| style="background:#FFF" width="50%" | {{#if {{{2|}}}| {{{2|}}} | N/A}}


Thank you in advance for the help.

PerfektesChaos (talkcontribs)

If you provided a literal copy, the reason is obvious: every parser function is separating by : from (first) parameter.

  • {{#if: condition | yeah }} will work.
MauCavans (talkcontribs)

No, this isn't a literal copy, my bad for the mistype.

My doubt was another:

- if the text string {{{1|}}} is not empty, I want the value to only occupy its column (as it does)

- if the text string {{{1|}}} is empty, I want one "N/A" to occupy both the columns

Doing {{#if: {{{1|}}}| {{{1|}}} |colspan="2"| N/A}} doesn't seem to work, as #if: function will take colspan="2" as third parameter.

As I said before, I'm pretty new to mediawiki, so sorry if there's an obvious way to do it that I don't know yet.

Bawolff (talkcontribs)


{{#if: {{{1|}}}| {{{1|}}} {{!}}colspan="2"|N/A }}

Bawolff (talkcontribs)

sometimes it will be easier to use html-style table syntax.

Also remember when using wiki style table syntax, you can use {{!}} if you need the | to go to the table layer.

Jonathan3 (talkcontribs)

This seems to do what you want:

{| class="wikitable"
! colspan="2" | Name
| {{#if: {{{1|}}} | {{{1}}} 
{{!}} {{{2|}}} | colspan="2" {{!}} N/A }}

I've tested it with:

{{test template|a|b}}
{{test template|c|}}
{{test template||d}}
{{test template}}
MauCavans (talkcontribs)

Yes, thank you, that's exactly what I was looking for!

Strangely enough, the | style="background:#FFF" at the start of the line is what seems to be causing the bug. I'll have to look for another way around it.

Thanks a lot to all of you for the help!

Jonathan3 (talkcontribs)

Maybe it's the # symbol. You could try "background: white" or use a class and Common.css

MauCavans (talkcontribs)

Thank you, I fixed it by setting the same backgroun to every line:

{| width="100%" class="sortable" style="text-align:center; background: #e1e1e1; border:3px solid #5b5a5a"

|- ! colspan="2" | Name |- style="background=#FFF" | {{#if: {{{1|}}} | width="50%"{{!}}{{{1|}}} {{!}} width="50%"{{!}}{{{2|}}} | colspan="2"{{!}}N/A}} |}

Again, really really thanks for the help. This little thing was bugging me for so long.

Jonathan3 (talkcontribs)

You're welcome. It's nice to hear that something has helped.

GreatOom (talkcontribs)


I use MadieWiki 1.35.2 on Ubuntu. Everything works fine including image upload.

Now I allowed also PDF upload via

$wgFileExtensions = [ 'png', 'gif', 'jpg', 'jpeg', 'webp', 'pdf' ];

Unfortuately it does not work. I get the error

Fehler beim Hochladen

Das Verzeichnis „mwstore://local-backend/local-public/5/5f“ konnte nicht angelegt werden.

The permissions seems to be Ok since I can actually upload images.

Enabling the "PdfHandler" extension (of course with all needed packages installed) makes no difference. I get the same error.

Any clue about the reason of this issue i.e. why does especially an upload of a PDF gives this error?



TheDJ (talkcontribs)
Reply to "PDF upload failure"

Has MW 1.35 changed when/how the HTTP header, Content-Length, are used?

Summary by Peculiar Investor
Peculiar Investor (talkcontribs)

I recently upgraded my wiki from MediaWiki 1.31 (PHP 7.3) to MediaWiki (PHP 7.4) on a shared hosting plan. We use the Extension:MobileFrontend. Since the upgrade a subset of my mobile device users (seems to be iPhone and iPad) are reporting that pages won't fully load and/or they get a "cannot parse response" error.

I cannot reproduce the problem on a localhost server (CentOS 8.2 with PHP 7.4).

We cannot reproduce the issue with a desktop browser (Chrome or Edge) DevTools emulating these devices, which is frustrating to say the least.

I've recreated my MediaWiki 1.31 in another directory on the shared hosting service and looked for differences in the network traffic. One difference we're noticed is that MediaWiki 1.35's initial header response includes a content-length parameter which isn't present when the same page is loaded from MediaWiki 1.31. We're using the Special:Version page for testing, so our wiki content isn't a factor (other than common interface elements such as logo and sidebar).

As a double-check, we checked the Special:Version page with The W3C Markup Validation Service and it reports "IO Error: Premature end of Content-Length delimited message body (expected: 55542; received: 11585" which we think might explain why the mobile devices are also giving an error.

I've tried changing the PHP version back to 7.3 for the MediaWiki 1.35 wiki and the problem persists.

Does MediaWiki 1.35 code include something that sets the Content-Length parameter in the HTTP headers? Is there a configuration setting involved?

Peculiar Investor (talkcontribs)
Lady G2016 (talkcontribs)

For the Project: support template:

MediaWiki 1.35.0
PHP 7.4.11 (cgi-fcgi)
MySQL 5.6.41-84.1

I forced the W3C Markup Validation Service check to use mobile view. The page has no output except for this single entry:

IO Error: Premature end of Content-Length delimited message body (expected: 51697; received: 11318

I can view the page in my desktop Chrome browser in both desktop and mobile views.

(This doesn't answer your question, but it's additional information to help identify the problem.)

Rom2cu (talkcontribs)

Our installation:

MW1.35.0, PHP 7.4.3 (cgi-fcgi), MySQL 5.7.29-log

It works fine except that Safari users get a blank screen with a "NSPOSSIXErrorDomain:100" and iPads and iPhones also get blank screens. No error with Chrome on the Macs. Is this the upstream bug the MW 1.35 system requirements warn against "MediaWiki is not compatible with PHP 7.4.0 to 7.4.2 due to an upstream bug"?

Peculiar Investor (talkcontribs)

To address the above point, I'm seeing the problem with PHP 7.4.11 so the not compatible issue mentioned in Compatibility does not apply. As mentioned, changing the PHP version back to 7.3.23 doesn't change the behaviour so I am thinking it is a MediaWiki related issue.

I've already worked though Manual:Common errors and symptoms and in particular the 'You see a Blank Page' section and it doesn't help identify any of the mentioned issues or help resolve the problem.

I don't know whether or not the HTTP header information for content-length appearing only with MediaWiki 1.35 and not with MediaWiki 1.31 on the same shared hosting server is a a symptom of the problem or a cause, but everything else that has been checked or investigated can explain why the Apple mobile devices are having issues with blank pages or giving "cannot parse response" errors.

Bawolff (talkcontribs)

Try setting $wgDisableOutputCompression = true;

MediaWiki will set a content length header if the HTTP version is 1.0 and gzipping is enabled

There are also certain situations where if MW wants to stay executing after it does output, and is not running as fast-cgi, where it will set a content-length header (4f11b614544be).

Peculiar Investor (talkcontribs)

Made the change and now Apple mobile devices seem to be loading pages correctly. The W3C validator page isn't reporting an IO error. Thanks. This seems more like a workaround as I'd question why a default MediaWiki configuration setting needs to be overridden.

Did something in MediaWiki between 1.31 and 1.35 change MediaWiki's setting of a content length header if the HTTP version is 1.0 and gzipping is enabled? I had reviewed all the Release Notes between 1.31 and 1.35 looking for configuration changes that need to be considered and I don't recall seeing any indication of this change.

For reference sake, I've checked our PHP configuration and it is using the default zlib.output_compression = Off and cgi-fcgi which is an alternative PHP FastCGI implementation.

Based on what phpinfo reports, the Apple mobile devices are using HTTP/2.0.

Bawolff (talkcontribs)
$wgDisableOutputCompression is super old, way before mw 1.31. It might just be that http/2 is incompatible and its just recently that http/2 is starting to be enabled by default.
Peculiar Investor (talkcontribs)

I've done some further testing on the testing environment that I'd setup to try and isolate the issue a bit further. The testing environment is running on the same shared hosting service and uses the last database backup when the wiki was running MediaWiki 1.31.10 (PHP 7.3.23, MySQL 5.6.41-84.1).

  1. Running MediaWiki 1.31.10 the Special:Version and then two or three clicks of Random page
    1. Windows 10 desktop and using Edge Chromium ✔
    2. iPhone XR (iOS 14.1) Safari ✔
    3. iPad Pro (iPadOS 14.1) Safari✔
  2. Upgraded to MediaWiki 1.32.6, updated Extension:MobileFrontend and Skin:MinervaNeue (REL1_32 versions).
    1. Windows 10 desktop and using Edge Chromium ✔
    2. iPhone XR (iOS 14.1) Safari ✔
    3. iPad Pro (iPadOS 14.1) Safari✔
  3. Upgraded to MediaWiki 1.33.4, updated Extension:MobileFrontend and Skin:MinervaNeue (REL1_33 versions).
    1. Windows 10 desktop and using Edge Chromium ✔
    2. iPhone XR (iOS 14.1) Safari ✔
    3. iPad Pro (iPadOS 14.1) Safari✔
  4. Upgraded to MediaWiki 1.34.4, updated Extension:MobileFrontend and Skin:MinervaNeue (REL1_34 versions).
    1. Windows 10 desktop and using Edge Chromium ✔
    2. iPhone XR (iOS 14.1) Safari ✔
    3. iPad Pro (iPadOS 14.1) Safari✔
  5. Upgraded to MediaWiki 1.35.0, updated Extension:MobileFrontend and Skin:MinervaNeue (REL1_35 versions).
    1. Windows 10 desktop and using Edge Chromium ✔
    2. iPhone XR (iOS 14.1) Safari - spinning wheel and Special:Version never loads
    3. iPad Pro (iPadOS 14.1) Safari - spinning wheel and Special:Version never loads

Clearly something has changed between MediaWiki 1.34.4 and MediaWiki 1.35.0 that is causing problems for Apple devices for my wiki. Checking Release notes/1.35 there is an item:

  • Fix GuzzleHttpRequest request headers.

There is no Task link for this, so I cannot trace it any further. Perhaps someone with more knowledge could locate the changes and review them to see if they could be responsible for the issue I'm seeing.

There is also:

FritzG (talkcontribs)

I can confirm the problem after upgrading my Wiki to 1.35. Interestingly only the "frame" of the pages was missing (logo, menu, search field etc.), the content part was visible.

The solution $wgDisableOutputCompression = true; worked. I post this because the thread is lacking the error code NSURLErrorDomain:-1017 which I had been googling, and others might do it too.

Peculiar Investor (talkcontribs)

After updating my iPhone and iPad to 14.2 the problem persists. I also had the opportunity to test this using iPadOS 13.3 and the wiki loads and functions properly.

Based on the various testcases I've now run it leads me to believe there is some serious MediaWiki 1.35, Extension:MobileFrontend and Skin:MinervaNeue and iOS (iPadOS) 14.x interaction problem.

Filed bug report, ⚓ T267619 MediaWiki 1.35 with Extension:MobileFrontEnd and Skin:MinervaNeue seem to have problems with iOS 14 devices if output_compression is enabled (

Reedy (talkcontribs)

The Guzzle things won't be relevant. MediaWiki uses Guzzle for making HTTP requests to other sites/services, rather than serving to users

Peculiar Investor (talkcontribs)
George Ho (talkcontribs)

Have your or anyone else tested MediaWiki 1.35 under either an Android device or an iPhone/iPad running 12.4.9, the latest version (i.e. newly and recently released) of iOS 12 for iPhones and iPads not compatible with iOS/iPadOS 13 or 14?

Peculiar Investor (talkcontribs)

Other wiki users have tested and reported, "Samsung Android, OS 8.0.0, latest patches, Chrome browser.... works just fine." and "Pixel 3A with Android 11 and Chrome. Seems to work.".

I cannot report anything further because I had to implement the $wgDisableOutputCompression = true; workaround. Given that an Apple device using iPadOS 13.3 didn't have issues I'm guessing the anything pre-iOS 14 is okay and the specific problem is specific to MediaWiki 1.35 and iOS 14. Running a search for OS 14 on Wikimedia Phabricator shows lots of results.

Peculiar Investor (talkcontribs)

A note of caution to anyone using the $wgDisableOutputCompression = true; workaround. I updated our wiki to MediaWiki 1.35.1 and for reasons I've been unable to figure out, there is some interaction between the setting and my shared hosts webserver configuration that results in pages being displayed as random symbols (encoding error). I works fine on my localhost testbed.

One the production site the only solution was to comment out the $wgDisableOutputCompression = true; so I'm back to the original problem, iPhones and iPads running iOS 14.x can never load any of our wiki pages.

Appropriate bug reports have been updated to reflect this information. (talkcontribs)

as of upgrading to 1.35.1 im getting the same result as above, pages being displayed as random symbols (encoding error) in Safari, Internet explorer, Edge and Chrome. Mozilla Firefox works fine..

Setting $wgDisableOutputCompression = true; gave no solution

Tested PHP 7.3 and 7.4

Any other ideas? (talkcontribs)

The $wgDisableOutputCompression = true;fixed a very similar problem at my completely new MW system, which had a nasty content-length mismatch which caused white pages in chrome and safari (desktop), Firefox worked. Main problem was that the content-length mismatch troubled the reverse proxy in front of MW.

NemesisAT (talkcontribs)

I've had the same issue, and setting $wgDisableOutputCompression = true; appears to fix it.

WillC93 (talkcontribs)

I am having the same issue. If I set $wgDisableOutputCompression = true; then I get a bunch of random symbols and errors. I have also tried adjusting my $wgServer and $wgCanonicalServer. I'm not sure if that is the right area to work on but that also did not work.

This is what I did for the server:

$wgServer = "//";

$wgCanonicalServer = "";


Adding that the Chrome app on my iPhone also does not work. The load bar gets about half way, everything freezes, then I get a site cannot be reached error. I have no idea what's going on. My site works fine in Chrome on PC.


I removed $wgCanonicalServer and kept $wgServer as //sitename and now both Safari and Chrome work, HOWEVER, they load on unsecure pages. If I add the https , the problems appear again. I'd like to have all my pages with https so this is only a temporary solution.

MichaelBeijer (talkcontribs)

After upgrading to 1.35.1. in the Softaculous auto-installer in my Namecheap cPanel, all text is garbled symbols. The ONLY way to make my wiki ( work again is the fix mentioned at:

Temporary fix:

Comment out exactly this line:

$response->header( 'Content-Encoding: identity' );

in: includes/MediaWiki.php

Longjebb (talkcontribs)

Nothing in this topic is working for iOS devices. Very few help topics for this I can find for such a monumental bug which prevents a huge swath of people from accessing the software via apple mobile. Can anyone shed light on a definitive answer?

Peculiar Investor (talkcontribs)

@Longjebb to the best of my knowledge and experience with my wiki this remains unsolved. From my reading of the discussion, some admins have had success changing MediaWiki code as a workaround, but that a) isn't widespread and b) right or wrong, my admin policy is to ONLY use officially released software on my websites. The published workarounds might work for some but unless they get released by the MediaWiki development team as a maintenance fix or perhaps a hotfix, then I'm not using them.

Given the severity of T235554 I had hoped this would be resolved and a maintenance release containing a fix would have come sooner. As an Apple device user I'm stuck waiting on the resolution.

Longjebb (talkcontribs)

Thanks for the info. I am ready to roll a MW site which will get tens of thousands of visitors a week and can't launch until this is remedied for good. Not a great first experience w this software!

Peculiar Investor (talkcontribs)

@Longjebb have you considered using MediaWiki 1.31.x which according to Version lifecycle is a current long-term support (LTS) version that will be supported until June 2021. My wiki was running very smoothly on 1.31 before we upgraded to 1.35.

Longjebb (talkcontribs)

Not sure I feel comfortable with a downgrade. Also a fan of getting it officially patched.

Longjebb (talkcontribs)

Can anyone shed light on whether or not a fix for this issue will be released....either via patch or next release? Not getting much traction mentioning on the discord support channel to date. Thanks!

Peculiar Investor (talkcontribs)

I received notice today that T235554 has been marked as "Resolved". There are two commits on the REL1_35 branch.

I've never 'patched' my MediaWiki install so I'm trying to figure out what steps would be required to deploy the fix(es) on a MediaWiki 1.35.1 site.

Reedy (talkcontribs)

Depends how you install/maintain MW....

There should be a Maintenance/Security release probably this week, but might be next week depending on schedules and progress. That will contain the fix for that resolved bug.

Peculiar Investor (talkcontribs)

My wiki's are always installed/maintained using Download to provide the tar.gz file of the release.

Supasaru (talkcontribs)

Has there been any movement on this topic?

I've noticed the problem while using HTTPS on Safari, macOS 11 (HTTP seems to work, but I'd rather use the encrypted connection.)

wgDisableOutputCompression = true; produced a page of unreadable characters (like others have described above) and deleting $response->header( 'Content-Encoding: identity' ); in mediawiki.php had no effect.

Reedy (talkcontribs)

What version of MediaWiki are you using? This should be fixed in 1.35.2, which was released at the start of April.

It would look like it was missed from 1.36 though :/

Supasaru (talkcontribs)

I skipped from 1.34.x to 1.36, so that's probably the problem. Has anybody tagged this as something that needs to be fixed for 1.36 and future versions?

Reedy (talkcontribs)

It's been backported and merged. It will be in 1.36.1 (possibly at the end of the month).

Reply to "Has MW 1.35 changed when/how the HTTP header, Content-Length, are used?"