GET /rest.php/[domain]/v3/page/html/Main_Page/95?redirect=false&stash=true HTTP/1.1" 403

"Error contacting the Parsoid/RESTBase server (HTTP 403)"

I have installed MediaWiki using the tarball.

@D3nnis3n: Calls to rest.php need to be parsed by the PHP parser. Please make sure, in your server configuration, that such calls go through the PHP parser.

Let me add a few aspects. Each one of these first had to be configured correctly - before that, each single one produced an error for me:

Hi Andre, this is about the release version of the Collection extension for MediaWiki 1.35. PHP is 7.4.

Thanks for the hint!

The problem can be described more clearly: $wgDBprefix is not set, so there should not be a table prefix.

$wgActorTableSchemaMigrationStage is set to MIGRATION_NEW as recommended by https://www.mediawiki.org/wiki/Manual:$wgActorTableSchemaMigrationStage.

Reedy wrote on IRC:

The above patch has been reverted.

Thanks for pushing this one, DJ!

You can see the languages in Gerrit, e.g. see SyntaxHighlight_GeSHi.lexers.php.

See T156573 for the update to the next version.

Obviously it was cached, but not on my side. I even downloaded to the local PC to check (which I had not done before) and it still was the old file.

I have tried with mediawiki-1.26.4.tar.gz and also a new download still gives me the old file.

Actually the tarballs for 1.26 are still unchanged...

In T143635#2574310, @demon wrote:

@Joergi123 As a quick workaround, you can swap [ for array( and ] for )

T137264 added the according change. Interestingly, the changeset in Gerrit as well as the file in Git (https://github.com/wikimedia/mediawiki/commit/1b24793be41dad9543f65d4ec61b917d1c845be6) contain the correct syntax.

In the meantime, I have adjusted my configuration, so that I am no longer hit by this problem.

It should in fact be the latest HEAD from master. The release versions do not yet contain support for typoscript, the language I need.

Thanks for taking care, aaron!

Thanks for pointing this out; it is not much of an effort and it would solve the bug.

Thanks a bunch, guys!

If you could do that, it would be amazing!

Thanks for digging out the history of this bug! This is more a cosmetical issue - I don't care, which of the two solutions you take. Just pick one. But if you ask me, I would make the index unique again. The content is unique so let's also call it unique. As pointed out this can be done without causing technical issues for the user. The overhead of the (unique) constraint compared to the non unique index is insignificant.

Yes, for upgraders to 1.24.