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".
Wiwit-mh (talkcontribs)

i am doubt for information,

  saya ragu akan informasi

is there any untruth ?

  apakah ada dustanya ?


waiting for reply,

sincerely yours,

wiwit muchamad hidayat

WhatsApp Business :

+62-831-4177-1874 (indonesia - AXIS https://axis.co.id/)

WhatsApp Messanger:

+62-813-5256-4610 (indonesia - simPATI (Telkomsel) https://www.telkomsel.com/

Reply to "wiki : small but the key"

Issues with Installing WikiBase

3
Kommandantjut (talkcontribs)

I have been having issues with installing wikibase (required for infoboxes)

I believed I followed the instructions correctly, however, following the installation my wiki goes to a white screen. Upon turning on error reporting I get the following error :

Fatal error: Uncaught Error: Class 'Wikimedia\AtEase\AtEase' not found in /home/archive.xxxxxxx.org/includes/registration/ExtensionRegistry.php:171 Stack trace: #0 /home/archive.xxxxxxx.org/includes/GlobalFunctions.php(88): ExtensionRegistry->queue('/home/...') #1 /home/archive.xxxxxxx.org/LocalSettings.php(133): wfLoadSkin('MonoBook') #2 /home/archive.xxxxxxx.org/includes/Setup.php(143): require_once('/home/...') #3 /home/archive.xxxxxxx.org/includes/WebStart.php(89): require_once('/home/...') #4 /home/archive.xxxxxxx.org/index.php(44): require('/home/...') #5 {main} thrown in /home/archive.xxxxxxx.org/includes/registration/ExtensionRegistry.php on line 171


I have tried installing this twice and have had zero luck so far.

Any help would be greatly appreciated!

Bawolff (talkcontribs)

Check if stuff is missing in the vendor directory. Make sure all your files are from the same version of mediawiki.

Kommandantjut (talkcontribs)

How would I know if something is missing in the vendor directory?

I did ensure that the versions were matched up with mediawiki

Reply to "Issues with Installing WikiBase"

"Passwords must be at least 10 characters" even though I have an 8 character password policy

7
Vicarage (talkcontribs)

Mediawiki 1.35.0, LocalSettings.php has

$wgPasswordPolicy['policies']['default']['MinimalPasswordLength'] = 8;

But when I try to change my (administrator account) password, I get the red text 'Passwords must be at least 10 characters', and it won't accept the 8 character password I want

Ammarpad (talkcontribs)

That is the 'default' only as the name suggests. Any more specific policy will override it. You're being asked for 10 because that's the requirement for users in 'sysop' group. You must to change it there too: $wgPasswordPolicy['policies']['default']['MinimalPasswordLength'] = 8;. If you're in interface-admin or bureaucrat groups you must also change it for each group.

Vicarage (talkcontribs)

That occurred to me, though its hardly obvious, as a default I specify should override something set inside code so I added the lines to correspond to Special:ActiveUsers

$wgPasswordPolicy['policies']['default']['MinimalPasswordLength'] = 8; $wgPasswordPolicy['policies']['administrator']['MinimalPasswordLength'] = 8; $wgPasswordPolicy['policies']['interface administrator']['MinimalPasswordLength'] = 8; $wgPasswordPolicy['policies']['bureaucrat']['MinimalPasswordLength'] = 8;

And nothing changed. I even added sysop, in case that was some daft hidden group

Only by editing includes/DefaultSettings.php and changing all the 10s to 8s did I manage to beat it into submission. Grrrr

Bawolff (talkcontribs)

$wgPasswordPolicy['policies'] = [ 'default' => ['MinimalPasswordLength' => 8]];

Alternatively, you can put var_dump( $wgPasswordPolicy); die(); at the very end of LocalSettings.php to figure out the final value and see if its what you expect.

Ammarpad (talkcontribs)

There's no group 'administrator', so that line would not do any anything. The canonical name of the group is 'sysop'. You're not supposed to edit DefaultSettings.php. You better copy the relevant lines to LocalSettings.php

Vicarage (talkcontribs)

Basic information

Username:John: Member of groups:Administrators, Autoconfirmed users, Bureaucrats, Interface administrators, Users

No sign of sysop here

$wgPasswordPolicy['policies'] = [ 'default' => ['MinimalPasswordLength' => 12];

makes my system lock up. I will stick with editing includes/DefaultSettings.php and moaning

TheDJ (talkcontribs)

"No sign of sysop here"

Sysop is the technical name of the administrators group in the software. The 'human' name value of it is "Administrator". This fact is arguably so well hidden in the interface these days, that it is hard to know if you don't know about the old name. A place where you can still see it is in the url of list users: Special:ListUsers/sysop

$wgPasswordPolicy['policies'] = [ 'default' => ['MinimalPasswordLength' => 12];

[] need to be balanced. you are missing a ] at the end there.

Reply to ""Passwords must be at least 10 characters" even though I have an 8 character password policy"
87.219.208.43 (talkcontribs)

When I try to upload a jpg file I get the following inernal error:

[YEDUqJPL20dJg2DZY8BFbgAAAHw] /index.php?title=Special:Upload TypeError from line 694 of /home/spatialm/mediawiki/includes/media/Exif.php: abs(): Argument #1 ($num) must be of type int|float, string given

Backtrace:

#0 /home/spatialm/mediawiki/includes/media/Exif.php(694): abs(string)

#1 /home/spatialm/mediawiki/includes/media/Exif.php(716): Exif->isSlong(string)

#2 /home/spatialm/mediawiki/includes/media/Exif.php(801): Exif->isSrational(string)

#3 /home/spatialm/mediawiki/includes/media/Exif.php(336): Exif->validate(string, string, string)

#4 /home/spatialm/mediawiki/includes/media/Exif.php(308): Exif->makeFilteredData()

#5 /home/spatialm/mediawiki/includes/media/BitmapMetadataHandler.php(96): Exif->__construct(string, string)

#6 /home/spatialm/mediawiki/includes/media/BitmapMetadataHandler.php(192): BitmapMetadataHandler->getExif(string, string)

#7 /home/spatialm/mediawiki/includes/media/JpegHandler.php(105): BitmapMetadataHandler::Jpeg(string)

#8 /home/spatialm/mediawiki/includes/utils/MWFileProps.php(87): JpegHandler->getMetadata(FSFile, string)

#9 /home/spatialm/mediawiki/includes/upload/UploadBase.php(547): MWFileProps->getPropsFromPath(string, string)

#10 /home/spatialm/mediawiki/includes/upload/UploadBase.php(482): UploadBase->verifyPartialFile()

#11 /home/spatialm/mediawiki/includes/upload/UploadBase.php(390): UploadBase->verifyFile()

#12 /home/spatialm/mediawiki/includes/upload/UploadFromFile.php(95): UploadBase->verifyUpload()

#13 /home/spatialm/mediawiki/includes/specials/SpecialUpload.php(516): UploadFromFile->verifyUpload()

#14 /home/spatialm/mediawiki/includes/specials/SpecialUpload.php(214): SpecialUpload->processUpload()

#15 /home/spatialm/mediawiki/includes/specialpage/SpecialPage.php(600): SpecialUpload->execute(NULL)

#16 /home/spatialm/mediawiki/includes/specialpage/SpecialPageFactory.php(635): SpecialPage->run(NULL)

#17 /home/spatialm/mediawiki/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext)

#18 /home/spatialm/mediawiki/includes/MediaWiki.php(940): MediaWiki->performRequest()

#19 /home/spatialm/mediawiki/includes/MediaWiki.php(543): MediaWiki->main()

#20 /home/spatialm/mediawiki/index.php(53): MediaWiki->run()

#21 /home/spatialm/mediawiki/index.php(46): wfIndexMain()

#22 {main}


Any ideas?

Ammarpad (talkcontribs)

This has been fixed on master branch and has been backported to MW 1.35

87.219.208.43 (talkcontribs)

Ok, thanks. It only happens with large images, with small ones I don't get this error, can it be?

TiltedCerebellum (talkcontribs)

I think Ammarpad is suggesting you update your mediawiki to the fixed version to prevent this?

Bawolff (talkcontribs)

or use php7 instead.

Reply to "Error uploading jpg"

Error creating image thumbnail

3
87.219.208.43 (talkcontribs)

When I try to upload an image I get the following error:


Error creating thumbnail: Error code: -1


Any ideas?

Malyacko (talkcontribs)
87.219.208.43 (talkcontribs)

Thanks, I have searched in the link you have recommended but I have not found any case like mine, could anyone help me?

Reply to "Error creating image thumbnail"

Sidebars on both sides of the site

3
2A02:587:B421:3700:9825:5461:ED71:EA54 (talkcontribs)

I was wondering if there was a way to add a sidebar to both sides of a site. The default one on the left, and another one on the right that shows the RecentChanges.

Ciencia Al Poder (talkcontribs)

There's no way to do that with configuration. I'm not aware of an extension to provide that functionality. You'll have to code something to do that.

TiltedCerebellum (talkcontribs)
Reply to "Sidebars on both sides of the site"

Problem with the position of the sidebar

6
90.40.182.3 (talkcontribs)

After upgrading Mediawiki from version 1.30 to 1.35, the sidebar is no longer on the left, it is at the bottom of the page.


Who can help me correct this problem?


See the home page

Bawolff (talkcontribs)

please set $wgShowExceptionDetails=true; after doing that, https://www.gennievre.net/wiki/load.php?debug=false&lang=fr&modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.content.externallinks%7Cmediawiki.skinning.interface%7Cskins.monobook.styles&only=styles&skin=monobook should have a more descriptive error.


Also make sure you have the correct version of monobook for your version of mediawiki (if you got it from somewhere that wasnt the official 1.35 tar download)

Gennievre (talkcontribs)

Hello

Thanks for this help.

I added in variable in LocalSettings, I copied the url for the test and here are the answers:

[YDtHdNYsMHvBvodBtonPdQAAANQ] /wiki/load.php?debug=false&lang=fr&modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.content.externallinks%7Cmediawiki.skinning.interface%7Cskins.monobook.styles&only=styles&skin=monobook Error from line 657 of /home/clients/16e57d37cb3303adbeb9d6dbf80efffb/web/wiki/includes/exception/MWExceptionHandler.php: Class 'FormatJson' not found

Backtrace:

#0 /home/clients/16e57d37cb3303adbeb9d6dbf80efffb/web/wiki/includes/exception/MWExceptionHandler.php(195): MWExceptionHandler::logError(ErrorException, string, string)

#1 /home/clients/16e57d37cb3303adbeb9d6dbf80efffb/web/wiki/includes/AutoLoader.php(81): MWExceptionHandler::handleError(integer, string, string, integer, array)

#2 /home/clients/16e57d37cb3303adbeb9d6dbf80efffb/web/wiki/includes/AutoLoader.php(81): require()

#3 [internal function]: AutoLoader::autoload(string)

#4 /home/clients/16e57d37cb3303adbeb9d6dbf80efffb/web/wiki/includes/resourceloader/ResourceLoader.php(141): spl_autoload_call(string)

#5 /home/clients/16e57d37cb3303adbeb9d6dbf80efffb/web/wiki/includes/resourceloader/ResourceLoader.php(752): ResourceLoader->preloadModuleInfo(array, ResourceLoaderContext)

#6 /home/clients/16e57d37cb3303adbeb9d6dbf80efffb/web/wiki/load.php(53): ResourceLoader->respond(ResourceLoaderContext)

#7 {main}

TiltedCerebellum (talkcontribs)

Are you using the MW 1.35 version of the skin as Bawolff mentioned?

Gennievre (talkcontribs)

I reverted to version 1.30 and that's when the display issue occurred.

Version 1.35 had to modify the database I think.

But I did use an official download.

TiltedCerebellum (talkcontribs)

It's unclear to me what reverted means. You went back to using MW 1.30, using the matching 1.30 version of the skin, and you reverted back to the 1.30 version of the database? (In my understanding, you can't use mismatched versions of things or errors are likely to occur as a result of that).

Reply to "Problem with the position of the sidebar"

Visual Editor Error contacting the Parsoid/RESTBase server (HTTP 404)

7
TelePointHistory (talkcontribs)

I'm trying to make the Visual Editor work in 1.35. but get this error when I click the 'edit' button. I can see the Visual Editor start to load in the background but clearly something is wrong. I am not trying to do anything unusual beyond just making the VE work.


Error contacting the Parsoid/RESTBase server (HTTP 404)


I am following the instructions on a range of different help pages and have tried adding/removing various commands. One page mentioned SSL certificates, various things to do with private servers, something else talked about config.example.yaml etc, but nothing I have tried works. I am not familiar with any of the coding required so don't actually understand the instructions but am stepping through them. This is what I have in my localsettings.php in my current attempt. I suspect the 'url' => and 'domain' => parts are wrong but don't know what else to try. I am on shared Siteground hosting if that makes a difference.


Many thanks for the help so far in setting this up.... (I never expected mediawiki to be this tricky to get started with!)


## Parsoid required configuration

$PARSOID_INSTALL_DIR = 'vendor/wikimedia/parsoid';

// For developers: ensure Parsoid is executed from $PARSOID_INSTALL_DIR,

// (not the version included in mediawiki-core by default)

// Must occur *before* wfLoadExtension()

AutoLoader::$psr4Namespaces += [

// Keep this in sync with the "autoload" clause in

// $PARSOID_INSTALL_DIR/composer.json

'Wikimedia\\Parsoid\\' => "$PARSOID_INSTALL_DIR/src",

];

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

// Enable Parsoid

$wgEnableRestAPI = true;

$wgParsoidSettings = [

'useSelser' => true,

'rtTestMode' => false,

'linting' => false,

];

// Enable VisualEditor

wfLoadExtension('VisualEditor');

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

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

'url' => 'https://history.telegraphpoint.com.au/public_html/ rest.php',

'domain' => 'https://history.telegraphpoint.com.au/',

];

TelePointHistory (talkcontribs)

I was wondering if anyone had any ideas on this? I am trying again but don't know where to start. I've read the various wiki pages on Parsoid and RESTBase but am not sure on how to set it up. Even just a link to the correct instructions would be really helpful. Thanks heaps.

Bawolff (talkcontribs)
Matthewishere0 (talkcontribs)

This is confusing. I just wanted to say that I have the same http 404 problem with the visual editor, but I want a simple way to fix this.

MBaitz (talkcontribs)

I'm also running into this problem and haven't had any luck finding a solution.

MBaitz (talkcontribs)

I just solved this problem for my own wiki hosted with SiteGround! The error occurs if your website doesn't have a SSL certificate attached to it yet.

I attached the certificate, added the following line to the localsettings.php file:

wfLoadExtension( 'VisualEditor' );

And the visual editor loaded without problem.

Good luck!

TiltedCerebellum (talkcontribs)

This is what solved our parsoid issues (we used built-in VE/Restbase so did not have to do the restbase config stuff per the manual).

We ensured we had https.

Also ensured this line had https:

$wgServer = "https://www.sitename.com";

Looked like currently VE won't work with Short URL per T270376, and it won't work on subpages if users don't have access to apache config files to do the VE doc recommended AllowEncodedSlashes NoDecode (which can't be done in .htaccess). The closest I could get to a shorter URL config was the default /wiki/ setup.

What worked in my case after ensuring https, was to have in LocalSettings.php:

$wgScriptPath = "/w"; # Folder MW is installed in on server
$wgArticlePath = "/wiki/$1"; # URL path shown in browser


And in .htaccess (apache non-root config file, at root web level, not in the w folder):

RewriteEngine on
RewriteBase /

# Rewrites all URLS without blog in them
RewriteCond %{REQUEST_URI} !^/w/

# Rewrites all URLS [Replace "example-sitename" with the actual domain, without the TLD (.com, .net, .biz, etc)]
RewriteCond %{HTTP_HOST} ^(www\.)?example-sitename\.

# Rewrite all those to insert /folder
RewriteRule ^(.*)$ /w/$1 [L]
Reply to "Visual Editor Error contacting the Parsoid/RESTBase server (HTTP 404)"

Resolving "ComposerInstalled.php" error

11
Minoa (talkcontribs)

This morning we began testing for the upgrade from MediaWiki 1.34.0 MediaWiki 1.35.0, but after upgrading, the Special:Version special page complains about not being able to modify header information, as well as trying but assumedly failing to access values in "ComposerInstalled.php".

Here is the whole log:

  • MySQL 5.7.26
  • PHP 7.4.2

I am keen to resolve this error so that it does not overwhelm the PHP error logs. Just to clarify, I have updated all the extensions to be compatible with 1.35: the extra extensions are: Disambiguator, GeoData, LabeledSectionTransclusion, MobileFrontend, TemplateStyles, TimedMediaHandler, AbuseFilter, AntiSpoof, CheckUser, ConfirmAccount, DismissableSiteNotice, Echo, SandboxLink, UploadsLink, UserMerge.

Ammarpad (talkcontribs)

On the Special:Version under the "Installed libraries" section what do you see? I guess there are some rows with empty content under the "library" column? If that's true, please post the remaining content of such rows here.

Also you can try to first delete the entire content of the vendor directory and get new one by issuing composer update --no-dev command, because probably the libraries metadata has been tempered with though I am not sure what could have caused this.

Minoa (talkcontribs)

I also made sure that I used composer under PHP 7.4.2.

AdamPloof (talkcontribs)

I came across what I believe to be a similar problem today. When I navigate to the Special:Version page I get multiple notices about unidentified indexes in:

...\libs\composer\ComposerInstalled.php (on lines 30, 31, & 32)


Under "Installed Libraries" of the Special:Version page there is nothing listed. I did try deleting the contents of the vendor directory and reinstalling with composer, but the problem did not go away. I did recently upgrade to Composer 2.0.8 which makes me suspicious that there is some incompatibility there.

TiltedCerebellum (talkcontribs)

I'm getting the same errors with Composer version 2.0.11, I'll try disabling extensions one by one and following the advice above. I had to install composer for a friend and came across this right after install and fixing Widgets extension which wouldn't install via its zip method for the friend doing it. Actually, no empty things under the library column.

Product Version
MediaWiki 1.35.0
PHP 7.4.12 (cgi-fcgi)
MySQL 5.7.28-log
ICU 57.1
Lua 5.1.5

In our case it was Extension:Widgets (Not to be confused with Gadgets which comes with MW. I had just finished filing another bug report for Article::getTouched was deprecated, so I don't think Widgets is fully 1.35 compatible... have folks here checked if they have Widgets installed?). I eliminated Disambiguator, LabeledSectionTransclusion, AbuseFilter, AntiSpoof, CheckUser, Echo and UserMerge first from our wiki by disabling one by one and retesting.

Cavila (talkcontribs)

@Minoa, did you by any chance use Composer 2 to install extensions? MediaWiki doesn't officially support it yet (maybe the merge plugin does).

TiltedCerebellum (talkcontribs)

Thank you for that. That's information I didn't see since it was only used to update an extension https://phabricator.wikimedia.org/T266417 Composer.

Funny I see a patch merged for this back in 2020 but received no message about it at all. I should have checked though.

Cavila (talkcontribs)

I'm in the same boat I'm afraid. Stuck in the middle of configuring MediaWiki because the Composer version that ships with Plesk is 2.0.7 (Plesk users are a little disgruntled about the situation). It really is unfortunate.

Widgets was a different story for me. No luck adding the extension and Smarty folder manually, but running Composer was what did it.

TiltedCerebellum (talkcontribs)

Yeah, composer install for my friend's server worked too when the zip version with manually added smarty (various versions) wouldn't work. I could use SSH to manually install an older composer version... but we had other errors from Widgets too https://phabricator.wikimedia.org/T276021 and extension conflicts in the past again emerging, so decided to just remove it for now. We were using it to embed youtube videos, screenshots linking off-site can replace that . We used it for a Sitenotice ad, replaced with theme edit. A FB widget also replaced with static image linking to FB too. Upgrade has been a bumpy process.

Admittedly, these are off-topic for this question, but, some other unanticipated stuff folks might run into during upgrade (to help prevent the goose chase we had):

Cavila (talkcontribs)

Maybe that's too many issues for one topic :) Yes, upgrading MediaWiki and its extensions can be a right pain. I hope fixes will be available soon.

@Minoa, the vital bit in your post that I missed at first is "I also made sure that I used composer under PHP 7.4.2." Unfortunately for you, "MediaWiki is not compatible with PHP 7.4.0 to 7.4.2 due to an upstream bug. Use PHP 7.4.3 or later instead." (see also https://phabricator.wikimedia.org/T246594). If you can upgrade (or downgrade) to any of the recommended versions, that might work.

So use Composer 1.* and either PHP 7.4.3 or higher, or PHP 7.3.19 or higher.

TiltedCerebellum (talkcontribs)

Yeah, sorry was just summarizing with resolutions as to some of the other stuff we ran into on upgrade in case anyone else that might run into the same issues (we had quite a goose chase finding the resolutions for these) along side composer stuff. Admittedly, I should have gone searching for individual posts about each and posted each one there... but would have been really nice for us to find a post like that all in one place while attempting to upgrade.

Reply to "Resolving "ComposerInstalled.php" error"

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

28
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

85.237.51.12 (talkcontribs)

Yet another line should be added in Parsoid permission condition for private MediaWiki-s behind reverse proxy:

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

  [

       $_SERVER['SERVER_ADDR'],

       $_SERVER['HTTP_X_FORWARDED_FOR'], # if MediaWiki behind reverse proxy

       '127.0.0.1',

       'localhost',]

)) {

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

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

}

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