Project:Support desk

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:

• Chat rooms
  • Wikimedia Chat (Mattermost)
  • MediaWiki unofficial (Discord)
  • Outreachy chat (Zulip)
  • Hackathon chat - (Telegram @wmhack group)
• Email groups
• StackOverflow (third-party)
• Unofficial MWUsers forum (third-party)

Before you post

• Check the basic How does MediaWiki work? guide.
• Check the FAQ and Errors and symptoms .
• If your question is about a specific feature, check the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• For issues about the mediawiki.org website, report to Current issues instead.
• For trying out wiki editing, use the Sandbox instead.

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".

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 https://encyclopedia.irkutskicetruckers.com/ or image of it https://i.imgur.com/0TGNy3T.jpg

Thanks,

James

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?

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?

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

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.

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?

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

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

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:

• intl (more information)

What is unclear with the error message and its instructions?

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

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".

At https://www.php.net/intl there are only a lot of links. At https://www.php.net/manual/ro/intl.installation.php there is no step-by-step guide about from where to download the files and how to install.

Which exact operating system is running on that machine?

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

The problem is that I do not know how to install intl, and I do not understand how from https://www.php.net/intl.

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

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.

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

intl

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

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

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

so I can use

https://www.mediawiki.org/wiki/Extension:HTMLets

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

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?

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.

if you want to dig, if its on wikimedia end it might be listed in https://wikitech.wikimedia.org/wiki/Server_Admin_Log . If its on your end it will be pretty hard to tell.

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

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

There is some advice on manual:combatting spam

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

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

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

{{!}} for |

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.

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

• {{#if: condition | yeah }} will work.

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.

try

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

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.

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}}

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!

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

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.

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

Hi!

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?

TIA,

GreatOom

Extension:PdfHandler#Troubleshooting

Manual:How_to_debug#Logging

Tracked in Phabricator
Task T235554

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?

If it helps, the wiki is at https://www.finiki.org

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 https://www.finiki.org/w/index.php?title=Special:Version&mobileaction=toggle_view_mobile

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.)

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"?

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.

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).

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.

$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.

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:

• Updated guzzlehttp/guzzle from 6.3.3 to 6.5.4.

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.

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 (wikimedia.org)

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

I just noticed Redirection fails in Webikit browsers with NSPOSIXErrorDomain: 100 on Project:Support desk (mediawiki.org) that seems to describe similar issues.

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?

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.

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.

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?

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.

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

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 = "//quik.wiki";

$wgCanonicalServer = "https://quik.wiki";

EDIT:

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.

EDIT #2

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.

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 (https://beijerpedia.com/wiki/Home) work again is the fix mentioned at:

https://www.mediawiki.org/wiki/Topic:Vzxi8uroe2eo23gk

---

Temporary fix:

Comment out exactly this line:

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

in: includes/MediaWiki.php

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?

@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.

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!

@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.

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

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!

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.

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.

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

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.

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 :/

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?

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