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

issue with migrating database on a new

1
Nevarim (talkcontribs)

i have this issue on altervista domain


if i use same files and same database in local i dont have the problem


what i have to do for to check?


thanks

Neva



MediaWiki internal error.

Original exception: [f26951ce9561258fe9cca016] /wiki/index.php?title=Pagina_principale Error from line 393 of /membri/pfita/wiki/includes/resourceloader/ResourceLoader.php: Class 'ResourceLoaderFilePath' not found

Backtrace:

#0 /membri/pfita/wiki/includes/ServiceWiring.php(973): ResourceLoader->register(string)

#1 /membri/pfita/wiki/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices)

#2 /membri/pfita/wiki/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string)

#3 /membri/pfita/wiki/includes/MediaWikiServices.php(1088): Wikimedia\Services\ServiceContainer->getService(string)

#4 /membri/pfita/wiki/includes/OutputPage.php(3155): MediaWiki\MediaWikiServices->getResourceLoader()

#5 /membri/pfita/wiki/includes/OutputPage.php(2930): OutputPage->getResourceLoader()

#6 /membri/pfita/wiki/includes/OutputPage.php(2974): OutputPage->getRlClientContext()

#7 /membri/pfita/wiki/includes/OutputPage.php(3201): OutputPage->getRlClient()

#8 /membri/pfita/wiki/includes/skins/Skin.php(681): OutputPage->getBottomScripts()

#9 /membri/pfita/wiki/includes/skins/SkinTemplate.php(388): Skin->bottomScripts()

#10 /membri/pfita/wiki/includes/skins/SkinTemplate.php(127): SkinTemplate->prepareQuickTemplate()

#11 /membri/pfita/wiki/includes/skins/SkinTemplate.php(144): SkinTemplate->generateHTML()

#12 /membri/pfita/wiki/includes/OutputPage.php(2615): SkinTemplate->outputPage()

#13 /membri/pfita/wiki/includes/MediaWiki.php(947): OutputPage->output(boolean)

#14 /membri/pfita/wiki/includes/MediaWiki.php(960): MediaWiki->{closure}()

#15 /membri/pfita/wiki/includes/MediaWiki.php(543): MediaWiki->main()

#16 /membri/pfita/wiki/index.php(53): MediaWiki->run()

#17 /membri/pfita/wiki/index.php(46): wfIndexMain()

#18 {main}

Exception caught inside exception handler: [f26951ce9561258fe9cca016] /wiki/index.php?title=Pagina_principale Error from line 393 of /membri/pfita/wiki/includes/resourceloader/ResourceLoader.php: Class 'ResourceLoaderFilePath' not found

Backtrace:

#0 /membri/pfita/wiki/includes/ServiceWiring.php(973): ResourceLoader->register(string)

#1 /membri/pfita/wiki/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer->{closure}(MediaWiki\MediaWikiServices)

#2 /membri/pfita/wiki/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string)

#3 /membri/pfita/wiki/includes/MediaWikiServices.php(1088): Wikimedia\Services\ServiceContainer->getService(string)

#4 /membri/pfita/wiki/includes/OutputPage.php(3155): MediaWiki\MediaWikiServices->getResourceLoader()

#5 /membri/pfita/wiki/includes/OutputPage.php(2930): OutputPage->getResourceLoader()

#6 /membri/pfita/wiki/includes/OutputPage.php(2974): OutputPage->getRlClientContext()

#7 /membri/pfita/wiki/includes/OutputPage.php(3201): OutputPage->getRlClient()

#8 /membri/pfita/wiki/includes/skins/Skin.php(681): OutputPage->getBottomScripts()

#9 /membri/pfita/wiki/includes/skins/SkinTemplate.php(388): Skin->bottomScripts()

#10 /membri/pfita/wiki/includes/skins/SkinTemplate.php(127): SkinTemplate->prepareQuickTemplate()

#11 /membri/pfita/wiki/includes/skins/SkinTemplate.php(144): SkinTemplate->generateHTML()

#12 /membri/pfita/wiki/includes/OutputPage.php(2615): SkinTemplate->outputPage()

#13 /membri/pfita/wiki/includes/exception/MWExceptionRenderer.php(153): OutputPage->output()

#14 /membri/pfita/wiki/includes/exception/MWExceptionRenderer.php(65): MWExceptionRenderer::reportHTML(Error)

#15 /membri/pfita/wiki/includes/exception/MWExceptionHandler.php(106): MWExceptionRenderer::output(Error, integer)

#16 /membri/pfita/wiki/includes/exception/MWExceptionHandler.php(185): MWExceptionHandler::report(Error)

#17 /membri/pfita/wiki/includes/MediaWiki.php(579): MWExceptionHandler::handleException(Error, string)

#18 /membri/pfita/wiki/index.php(53): MediaWiki->run()

#19 /membri/pfita/wiki/index.php(46): wfIndexMain()

#20 {main}

Reply to "issue with migrating database on a new"

Text and footnote alignment in infoboxes

1
Esszet (talkcontribs)

See here; footnotes in infoboxes aren't aligning properly in Safari on Mac OS, and links in the same header render slightly below everything else. I'll also add that getting rid of the link doesn't fix the issue with footnotes.

Reply to "Text and footnote alignment in infoboxes"

Error contacting the Parsoid/RESTBase server: http-bad-status in Closed Wikis

27
89.26.47.65 (talkcontribs)

Is there any way to get VisualEditor working in a closed 1.35 Wiki (Account required for read access)?

Maybe there is a way to force VisualEditor to use a certain Useraccount?

MarkAHershberger (talkcontribs)
89.26.47.65 (talkcontribs)

Thanks for the reply.


i tried to understand that documentation, which is really difficult for a newbie


I have added to the end of my LocalSettings.php :

$PARSOID_INSTALL_DIR = 'vendor/wikimedia/parsoid';

$wfLoadExtension( 'Parsoid', "$PARSOID_INSTALL_DIR/extension.json" );

$wgVisualEditorParsoidAutoConfig = false;

$wgParsoidSettings = [

   'useSelser' => true,

   'rtTestMode' => false,

   'linting' => false,

];

$wgVirtualRestConfig['modules']['parsoid'] = [];

$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;


Now the wiki stopped responding completly (only serves a white page with no HTML at all)

MarkAHershberger (talkcontribs)

Blank or white pages are the first item on Common errors and symptoms.

In any case, your problem is the like that begins $wfLoadExtension. You should not have a $. It should read simply wfLoadExtension.

89.26.47.65 (talkcontribs)

Thanks for your patience


I corrected the line wfLoadExtension( 'Parsoid', "$PARSOID_INSTALL_DIR/extension.json" ); and enabled the printing of fatal php errors. (thanks for the tip)


Sadly trying to edit pages with visual editor still returns the same error message. Creating a new page works fine.

89.26.47.65 (talkcontribs)

Additon: the troubleshooting for VisualEditor also recommendended giving the server read-access with the following code in LocalSettings


if ( $_SERVER['REMOTE_ADDR'] == '127.0.0.1' ) { (note: I also tested this line with the server IP and server IP + port)

$wgGroupPermissions['*']['read'] = true;

$wgGroupPermissions['*']['edit'] = true;

}

But the error message doesnt change.

2003:C9:9F19:B900:20D:B9FF:FE49:6549 (talkcontribs)

"Error contacting the Parsoid/RESTBase server: (curl error: 60) SSL peer certificate or SSH remote key was not OK" from here. Private Network and secure http connection. VisualEditor do not work.

MarkAHershberger (talkcontribs)
Error contacting the Parsoid/RESTBase server: (curl error: 60) SSL peer certificate or SSH remote key was not OK

I'm confused about "SSH remote key" but it looks like you're using a self-signed or otherwise un-recognized cert.

Try the following:

$wgVirtualRestConfig['modules']['parsoid'] = array(
    'url' => 'http://127.0.0.1' . $wgScriptPath . '/rest.php',
);
89.26.47.65 (talkcontribs)

Even with this added to the localsettings.php still the same error message.

MarkAHershberger (talkcontribs)

What is the error message you're getting?

What happens is you remove these lines

$PARSOID_INSTALL_DIR = 'vendor/wikimedia/parsoid';
$wfLoadExtension( 'Parsoid', "$PARSOID_INSTALL_DIR/extension.json" );
$wgVisualEditorParsoidAutoConfig = false;
$wgParsoidSettings = [
   'useSelser' => true,
   'rtTestMode' => false,
   'linting' => false,
];
$wgVirtualRestConfig['modules']['parsoid'] = [];

but keep this one:


$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;
89.26.47.65 (talkcontribs)

Thank you so much for replying.


Error contacting the Parsoid/RESTBase server: http-bad-status


That is the complete error message.


Right now this is all the options set for Visual Editor.


$wgDefaultUserOptions['visualeditor-enable'] = 1;

$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;

50.73.98.161 (talkcontribs)

Were you able to resolve your issue? I'm having the same problem

MarkAHershberger (talkcontribs)

Can you see any references to rest.php in your wiki's access logs?

TreiberO (talkcontribs)

I added the following to the LocalSettings

$wgDebugLogFile = "C:\Apache24\htdocs\mediawiki_IT\debug-{$wgDBname}.log";

TreiberO (talkcontribs)

had to use pastebin beacuse posting this was deemed harmful because of "linkspam".

I am sorry

pastbin ID: NHrwFqCZ

MarkAHershberger (talkcontribs)
TreiberO (talkcontribs)

The Message i get is:

"The requested relative path (/192.168.2.73/v3/page/html/Hauptseite/42) did not match any known handler"

404 - "not found".

MarkAHershberger (talkcontribs)
89.26.47.65 (talkcontribs)

I get the exact same message


404 - Did not match any known handler.

MarkAHershberger (talkcontribs)

I don't know enough to help you further. Could you post a task to Phabricator pointing back here?

89.26.47.65 (talkcontribs)

Thank you for all your help,

I will do that.

Sorry for the late replies.

MarkAHershberger (talkcontribs)

I should have asked you to post the task # here, as well.

109.208.148.21 (talkcontribs)

Hi,

I get exactly the same issue, i was following this topic...

Can you give me the Phabricator's URL where i can follow your issue?

Thx

109.208.148.21 (talkcontribs)

Sorry but i just found for my issue.

$wgGroupPermissions['*']['read'] = false;

if ( !isset( $_SERVER['REMOTE_ADDR'] ) OR $_SERVER['REMOTE_ADDR'] == '127.0.0.1>

$wgGroupPermissions['*']['edit'] = true;

$wgGroupPermissions['*']['read'] = true;

}

Order is important !!!

37.201.6.225 (talkcontribs)

109.208.148.21's code snippet didn't work for me, I had to alter it a bit because in my environment, the server used it's actual IP instead of localhost. Here's a snippet for your LocalSettings.php that _might_ just work on a couple systems more because it covers both cases:


$wgGroupPermissions['*']['read'] = false;

$wgGroupPermissions['*']['write'] = false;

if (in_array($_SERVER['REMOTE_ADDR'],

   [

       $_SERVER['SERVER_ADDR'],

       '127.0.0.1',

       'localhost',]

)) {

   $wgGroupPermissions['*']['read'] = true;

   $wgGroupPermissions['*']['write'] = true;

}


Hope the time I had to invest in this saves some of someone else's time in the future.

37.201.6.225 (talkcontribs)

Please note that above solution is not ideal for wikis with sensible data, someone with restricted access to your server will be able to access the entire wiki. If you're on a shared hoster, you won't have control over that. The only sensible option is to wait until this "LTS" version is in an actually usable state, or to install parsoid by yourself.

Blake.Milam (talkcontribs)

I had this error message and I was able to correct it by changing the server path to not use https. In LocalSettings under "## The protocol and server name to use in fully-qualified URLs" I had fat-fingered an https into the link

Reply to "Error contacting the Parsoid/RESTBase server: http-bad-status in Closed Wikis"

Visual Editor Image upload with Wiki family

2
94.174.26.183 (talkcontribs)

We have a Wiki family, the images and users are shared under commons.

$wgForeignFileRepos is set and the sites are loading the images from commons without problem, we can also upload images on commons.

However when we try to upload/insert images with Visual Editor, we get the error message: File uploads are disabled.

Please let me know how we can enable file uploads with Visual Editor to commons. Thanks!

This post was hidden by Clump (history)
Reply to "Visual Editor Image upload with Wiki family"

Is there a default way for rate limiting?

9
182.232.128.233 (talkcontribs)

For my principally all-core, all-default MediaWiki website I use an about 24-characters root password and yet, by principle, I would still want to rate limit the number of times per x amount of time in which people can try to log in with my user name.

Is there a default, all-core way for rate limiting?

I don't want to set anything manually myself, just follow a rate limiting convention of the community, if there is one.

182.232.128.233 (talkcontribs)

A simple, "turn on and keep going" approach for all sorts of rate limiting.

It is good for me because in my website there is, at least at this moment, only one registered user profile, which I myself operate and I wish to protect my profile from being hacked.

Of course, I protect as much as I can from DDoS, SQL injections, backdoors etc. but in the BFA/Rate limiting context I think that my website is still not fully covered and I seek a simple solution for that.

Ciencia Al Poder (talkcontribs)
182.232.153.210 (talkcontribs)

Hello @Ciencia Al Poder

Because the webpage you mentioned, Manual:$wgPasswordAttemptThrottle is much smaller and simpler I would like to try to start to implement what it describes; the problem is that I found any sentence in it unclear.

Limit password attempts to count attempts per seconds per IP per username.

Does this mean that a built in password tries rate limiting mechanism is on by default in all 1.14.0 and above MediaWikis?

Bawolff (talkcontribs)

> Does this mean that a built in password tries rate limiting mechanism is on by default in all 1.14.0 and above MediaWikis?

Yes, although on some versions it may only be enabled if $wgMainCacheType is set to something like CACHE_MEMCACHED or CACHE_ACCEL (and the cache is functioning correctly). I dont remember what the current cache backend for password throttle so im not sure if its still neccesary.


Lots of people also use extension:ConfirmEdit to add captchas to the login page after X failed attempts.

49.230.193.21 (talkcontribs)

@Bawolff


From both your comment and from reading the first warning on Manual:$wgRateLimits I understand that in general, MediaWiki websites must have some version of caching in order to have rate limiting and that this is further true with specific types of caching for the default caching (enabled as long as $wgPasswordAttemptThrottle wasn't set to false).

49.230.193.21 (talkcontribs)

I would like to ask MediaWiki developers here, why is caching even needed for rate limiting? From a modular standpoint, shouldn't these two features of a program be totally independent? Asked with desire to understand "what's going on" in this context.

49.230.193.21 (talkcontribs)

for the default caching === for the default rate limiting*

Ciencia Al Poder (talkcontribs)

Rate limiting in general works by tracking each time some actor does some action, and counting if it reaches a specific rate. This tracking needs to be saved somewhere. Devs may have decided to create specific tables in the database to store those values, but instead they decided to use the existing cache architecture for that. And that's why it requires a persistent caching.

Reply to "Is there a default way for rate limiting?"

Mediawiki 1.35.1 and VisualEditor behind a proxy not working

4
Shahim Essaid (talkcontribs)

I'm trying MW 1.35.1 in a docker compose setup. The visual editor is working as expected without any additional configuration when the docker image is port mapped to port 80 on the host as it is also on port 80 in the docker image.


However, if I try to reach the Mediawiki docker container (where MW is running on port 80) through an HAProxy container that forwards port 8080 from the browser to port 80 on the Mediawiki container the visual editor breaks. I think it has something to do with having to configure the URLs for Parsoid, RESTBase, etc. but I'm not sure how to do this. Most of the existing documentation is for previous versions that needed manual installation and configuration of VE and its dependencies.

Any hints for what is needed in LocalSettings.php to deal with the proxying from port 8080 to 80, or any other proxy related configuration on the MW side? Thanks!

Shahim Essaid (talkcontribs)

It appears that simply removing the port from the $wgServer value might have fixed this problem. It was set to the port from the proxy (8080) but MW was running under Apache on port 80. I'd still like to understand how this works for MW 1.35 in terms of adjusting ULRs/Ports for the Parsoid/RESTBase auto configuration that is part of 1.35.

Jeroen De Dauw (talkcontribs)

Similar issue when using the stock MediaWiki 1.35 Docker image and enabling VisualEditor. Would be nice to have some docs on this!

Dragan Espenschied (talkcontribs)

Here is running Mediawiki 1.35.0 via the default Docker container on my local dev laptop, and added VisualEditor. Upon launching, VE complains: Error contacting the Parsoid/RESTBase server: (curl error: 7) Couldn't connect to server -- apparently the auto configutation is getting something wrong.


This is the apache log entry that apparently produces the error:


172.22.0.1 - - [25/Jan/2021:13:54:10 +0000] "GET /w/api.php?action=visualeditor&format=json&paction=parse&page=Main_Page&uselang=en&formatversion=2&oldid=144730 HTTP/1.1" 200 858 "http://localhost:8181/w/index.php?title=Main_Page&veaction=edit" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0"


Enabling or disabling short URLs doesn't seem to make a difference.


The documentation is a bit confusing so I am at a loss of how to find the error. There is no entry in the apache log or the browser console that would hint at what URL VE is trying to access.


Any help greatly appreciated!

Reply to "Mediawiki 1.35.1 and VisualEditor behind a proxy not working"

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

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

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

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.

85.148.240.76 (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?

84.183.223.240 (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 = "//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.

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

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

Saving main page fills it with source code chaos

5
31.16.193.224 (talkcontribs)

Hi everybody,

i just set up a new mediawiki on our webspace. Copied the files to the webspace, followed the installation routine, set up a mysql database, all permissions granted. So far, all this worked out fine.

Now if i try to edit the main page and save anything, it's overwritten by some source code, which leaves the page in chaos. The actual text i entered is also not saved in it, it's just replaced.

This is what it looks like: https://www.dropbox.com/s/rv6r3kcsnmzcyim/wiki_error.jpg?dl=0

Any idea what might cause this? Couldn't find any help searching the web so far. Thanks in advance!

Malyacko (talkcontribs)

Is this a public installation that you could link to?

31.16.193.224 (talkcontribs)

Hi! No, so far it's a private one. But, if necessary, i could make it public, as it doesn't have any content yet anyway.

31.16.193.224 (talkcontribs)

Should also add: No errors in dev logs and version history shows the source code as the actual contents of the page.

31.16.193.224 (talkcontribs)

Anybody got an idea?

I could make the page public if necessary, as it doesn't have any content yet anyway.

Reply to "Saving main page fills it with source code chaos"
Johnywhy (talkcontribs)

i haven't updated any part of this wiki for at least two years. Any suggestions?


NON-VERBOSE ERROR MESSAGE:

MediaWiki internal error.

Original exception: [YA4P2hqluUbuv96omr44FQAAAUM] 2021-01-25 00:24:59: Fatal exception of type "UnexpectedValueException"

Exception caught inside exception handler.

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

=========

VERBOSE ERROR MESSAGE:

Notice: Undefined index: hideroot in /home/gunsywtx/public_html/LocalSettings.php on line 288

Warning: Use of undefined constant DB_SLAVE - assumed 'DB_SLAVE' (this will throw an Error in a future version of PHP) in /home/gunsywtx/public_html/extensions/ApprovedRevs/includes/ApprovedRevs_body.php on line 49

MediaWiki internal error.

Original exception: [YA4qJ--S@vJPOyAaBZI-1AAAAdA] /index.php/Main_Page UnexpectedValueException from line 462 of /home/gunsywtx/public_html/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Invalid server index index #DB_SLAVE

Backtrace:

#0 /home/gunsywtx/public_html/includes/libs/rdbms/loadbalancer/LoadBalancer.php(896): Wikimedia\Rdbms\LoadBalancer->getConnectionIndex(string, array, string)

#1 /home/gunsywtx/public_html/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1043): Wikimedia\Rdbms\LoadBalancer->getConnection(string, array, string, integer)

#2 /home/gunsywtx/public_html/includes/GlobalFunctions.php(2556): Wikimedia\Rdbms\LoadBalancer->getMaintenanceConnectionRef(string, array, string)

#3 /home/gunsywtx/public_html/extensions/ApprovedRevs/includes/ApprovedRevs_body.php(49): wfGetDB(string)

#4 /home/gunsywtx/public_html/extensions/ApprovedRevs/includes/ApprovedRevs.hooks.php(192): ApprovedRevs::getApprovedRevID(Title)

#5 /home/gunsywtx/public_html/includes/Hooks.php(174): ApprovedRevsHooks::showApprovedRevision(Title, NULL, RequestContext)

#6 /home/gunsywtx/public_html/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)

#7 /home/gunsywtx/public_html/includes/page/Article.php(167): Hooks::run(string, array)

#8 /home/gunsywtx/public_html/includes/page/Article.php(193): Article::newFromTitle(Title, RequestContext)

#9 /home/gunsywtx/public_html/includes/MediaWiki.php(411): Article::newFromWikiPage(WikiPage, RequestContext)

#10 /home/gunsywtx/public_html/includes/MediaWiki.php(300): MediaWiki->initializeArticle()

#11 /home/gunsywtx/public_html/includes/MediaWiki.php(854): MediaWiki->performRequest()

#12 /home/gunsywtx/public_html/includes/MediaWiki.php(527): MediaWiki->main()

#13 /home/gunsywtx/public_html/index.php(44): MediaWiki->run()

#14 {main}

Exception caught inside exception handler: [YA4qJ--S@vJPOyAaBZI-1AAAAdA] /index.php/Main_Page MWException from line 183 of /home/gunsywtx/public_html/includes/MagicWord.php: Error: invalid magic word 'lst'

Backtrace:

#0 /home/gunsywtx/public_html/includes/MagicWordFactory.php(222): MagicWord->load(string)

#1 /home/gunsywtx/public_html/includes/parser/Parser.php(5288): MagicWordFactory->get(string)

#2 /home/gunsywtx/public_html/extensions/LabeledSectionTransclusion/LabeledSectionTransclusion.class.php(13): Parser->setFunctionHook(string, array, integer)

#3 /home/gunsywtx/public_html/includes/Hooks.php(174): LabeledSectionTransclusion::setup(Parser)

#4 /home/gunsywtx/public_html/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)

#5 /home/gunsywtx/public_html/includes/parser/Parser.php(476): Hooks::run(string, array)

#6 /home/gunsywtx/public_html/includes/cache/MessageCache.php(1189): Parser->firstCallInit()

#7 /home/gunsywtx/public_html/includes/cache/MessageCache.php(1165): MessageCache->getParser()

#8 /home/gunsywtx/public_html/includes/language/Message.php(1280): MessageCache->transform(string, boolean, LanguageEn, Title)

#9 /home/gunsywtx/public_html/includes/language/Message.php(884): Message->transformText(string)

#10 /home/gunsywtx/public_html/includes/language/Message.php(944): Message->toString(string)

#11 /home/gunsywtx/public_html/includes/OutputPage.php(888): Message->text()

#12 /home/gunsywtx/public_html/includes/OutputPage.php(937): OutputPage->setHTMLTitle(Message)

#13 /home/gunsywtx/public_html/includes/OutputPage.php(2610): OutputPage->setPageTitle(string)

#14 /home/gunsywtx/public_html/includes/exception/MWExceptionRenderer.php(125): OutputPage->prepareErrorPage(string)

#15 /home/gunsywtx/public_html/includes/exception/MWExceptionRenderer.php(53): MWExceptionRenderer::reportHTML(UnexpectedValueException)

#16 /home/gunsywtx/public_html/includes/exception/MWExceptionHandler.php(121): MWExceptionRenderer::output(UnexpectedValueException, integer)

#17 /home/gunsywtx/public_html/includes/exception/MWExceptionHandler.php(195): MWExceptionHandler::report(UnexpectedValueException)

#18 /home/gunsywtx/public_html/includes/MediaWiki.php(558): MWExceptionHandler::handleException(UnexpectedValueException)

#19 /home/gunsywtx/public_html/index.php(44): MediaWiki->run()

#20 {main}

Charitwo (talkcontribs)

Your version of ApprovedRevs needs updating, it's not recognizing DB_SLAVE when it should be DB_REPLICA.

Reply to "Wiki Won't Load"

NAS-based private Wiki search function not working

7
70.187.64.138 (talkcontribs)

Hello,

Just installed MediaWiki 1.27.1.1 on my QNAP NAS so I could build a private Wiki for some research I am doing. One of my primary needs is to search all the documents at once for specific keywords.

My trouble is that plain text search does not seem to be working (i.e. page contains the word "Panama", search for "Panama" yields 0 results and suggests I create a page by that title).

The only searches that return any results are those that reference a specific page name. (i.e. page name is "Main Page", search for "Main Page" yields 0 results but offers hyperlink to the Main Page).


I have done no configuration beyond the initial install. Is there something specific I need to do to make it work? I would have expected the feature to be ready right out of the box, so to speak.

Thanks for any help you can provide.

Bawolff (talkcontribs)

Why 1.27? That's years out of date. Also 1.27.1.1 isnt a version number we use.

In theory those features should work out of the box.

It could be an issue with the job queue. You could try setting $wgRunJobsAsync to false in LocalSettings.php (this is default 1.27.2 and later) and try running runJobs.php

You can rebuild the search index with Manual:rebuildtextindex.php

70.187.64.138 (talkcontribs)

v. 1.27.1.1 is what QNAP offered in their App Store to install.

I will try those later today and see if either helps.

Bawolff (talkcontribs)

We have no association with QNAP and have never heard of it. Its possible they changed mediawiki in arbitrary ways and caused the search to be broken. We can really only offer effective help for the official versions of MediaWiki.

70.187.64.138 (talkcontribs)

Thank you for the help.

Perhaps I'll investigate things further with them. Maybe someone else has had similar trouble.

70.187.64.138 (talkcontribs)

Ok. Here's what I found. I have no clue what I'm doing. I'm technically minded, but this stuff is way above my experience. Why couldn't there just be a "Rebuild Text" link in the Special Pages section or something like that?

First, I have no memory of ever using Terminal services before. So, I thought I'd try the Maintenance Shell extension... except I can't get it to accept me as an Administrator to allow me access to it. I even told it to give access as a User... no dice.

Second, I don't know how I'm supposed to access the mediawiki through a terminal connecting to my NAS. Windows Terminal was no help, so I tried Putty. That got me as far as logging in, but once I got logged in, I was presented with a menu system. After getting out of it, I'm just at a "#" prompt. I tried maneuvering the directory structure to follow the instructions on the Maintenance Scripts page and got nowhere fast. None of the stuff I found looked familiar at all.

I'm not giving up, but you should understand that you'll need to talk down to me so I can understand what needs to be done to fix it.

Makes me wish I could get ScrewWiki on my NAS... that thing works for me on my webspace (this project is different, it needs to be private).

70.187.64.138 (talkcontribs)

Correction: Screwturn Wiki.

Reply to "NAS-based private Wiki search function not working"