I just ran into this yesterday after upgrading my MW 1.39.7 wikis from MySQL 5.7 (Aurora 2.11.5) to 8..0.36 (Aurora MySQL 3.07.1). Servers are running PHP 7.4.3 on Ubuntu 20.04.

I'll add my voice to MGChecker's comments, as we use Variables (and Loops to a lesser extent) in multiple wikis totalling around 300k content pages (and growing) that use 100s of templates that use Variables. Further, all of our wikis' contents are managed not by me or my company but by the wikis' respective communities and a small-ish set of editors who would be forced to completely rework all their use of the affected extensions somehow. (It's my understanding that the generally expected alternative would be Scribunto/Lua, meaning the editors would need to learn Lua if they don't already know it.)

The comments in MainConfigSchema.php still also say that port 80 is the default for CdnServers:
https://github.com/wikimedia/mediawiki/blob/master/includes/MainConfigSchema.php#L4434

I've opened a SMW GitHub issue in case that is a more appropriate avenue, given that these issues appear to be at the intersection of extensions managed here and there.

I would like to add that, while we have been able to work around the unparsed queries issue, the empty and incomplete query results are a significant problem for us. It would be nice to at least have an idea if this is more likely either a software bug (regardless of which component) or some kind of configuration or content-related issue that we would somehow need to address ourselves. Right now we have no idea and are completely stuck.

I'm working on redesigning our wikis to use a family design so I'm testing this again. I have each wiki's compiled widgets in $IP/compiled_templates/$wikiId/. I can see some widgets getting recompiled every time I hit a new page (e.g. via the Random page link) by watching the files' timestamps on the command-line via ls -l --full-time. Is there any further information I can provide to help diagnose this? Is this possibly just normal behavior, or could it be due to how the widgets are written? It would certainly be nice to resolve this before I'm ready to go live with the family redesign.

Is there any work being done on this issue? Any idea of how significant of a risk it is?

Is this task being worked? I have several custom namespaces that I need to renumber on several large wikis so that I can convert them into a wiki family design, and not having the ability to renumber a namespace is a showstopper for that larger project.

Any ideas about this issue?

@Revansx I don't know for sure that they're related, but IIRC the conversation in the MW Stakeholders channel suggested that they are, and I'm not really knowledgeable on the details of how the extension works and what it all does, as it's our editors that manage all of our wikis' contents.

FWIW I've also been told that SQL injections may be possible with this issue, though I don't have an example query/URL yet to demonstrate that.

Ok, thanks for the confirmation. I'll keep a close eye on this issue and I have a dev environment in which I can do further testing if needed.

HTML injection. The link I provided in our wiki shows an example of that, but the sec team (and me) weren't sure if this was in some way maliciously exploitable or if MW/SMW is more restrictive in e.g. the HTML tags it allows.

I don't know if there actually is one. Our security team reported this was discovered during some testing and wanted to know if this was normal behavior for the wikis or if it was some kind of exploitable bug.

I was told that an issue we discovered during some security testing may be related to this, so I figured I should post it here.

This bug is referenced by the docs for $wgCdnServers, and I'd just commented on T291768 about needed to add port 80 to my list of Varnish servers. However, the purges seem to be working whether or not I also add the IPs to $wgCdnServersNopurge. I am on MW 1.36.2, so maybe this issue was resolved with 1.36 (or even 1.35)?

I just found this bug report. I'd always been confused why I'd never see any PURGE requests coming into my wiki web servers' Varnish processes (via varnishlog -q 'ReqMethod eq PURGE'), and why I was seeing port 1080 instead of the expected 80 when viewing page purges through tcpdump. I can confirm that adding :80 to each of the IP addresses in my $wgCdnServers setting does indeed resolve the problem for me.

I had it working with REL1_35 using elasticsearch/elasticsaerch 6.7.*. Semantic MediaWiki wanted 6.8 but seemed to work fine when I specified the 6.7 limit in my composer.local.json. I didn't restrict elastica but it installed 6.1 (currently on 6.1.3 with REL1_36).

I'm following up on @Revansx, who may have been replying here due to me bringing this up on a live channel the same day he posted based on reviewing the documentation for all of the extensions we use as I prepare for a major version upgrade to 1.36. We use Variables extensively on our five Guild Wars 1 and 2 wikis.

I'm hitting this as well in testing rebuildData.php on MW 1.36 with SMW 3.2.3 and Page Forms 5.2.1. It appears to duplicate https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4330. Also, --ignore-exceptions does not skip over it.

PHP Warning: preg_match(): Empty regular expression in $IP/includes/Linker.php on line 1826

@Aklapper My bad, thanks. I'm still new to using Phabricator. Should I do anything to change this? And is further information needed regarding this issue?

In T276854#7227840, @Reedy wrote:

If you're letting it install based on the SMW version constraints alone, probably.

If you're combining (using composer-merge-plugin) your composer.json files, it should try and make sure it validates and meets all constraints

I'm seeing the same problem in the original post where Elastica requires ruflin/elastica 6.1.5, which requires elasticsearch/elasticsearch: ^6.0 and conflicts with 6.8.1. However, I also just noticed that Semantic MediaWiki requires elasticsearch/elasticsearch ^5.3|^6.0, so I think that's why I'm getting 6.8.1.

In T276854#7227492, @Reedy wrote:

In T276854#7227486, @Justin_C_Lloyd wrote:

This still doesn't seem to work. I'm on MediaWiki 1.35.3, trying to get AWS Elasticsearch v6.5.4 working with CirrusSearch. I've got Elastica 6.1.3 (de9fe84) and elasticsearch/elasticsearch 6.8.1 but when I run the maintenance script I get the error in T267106:

# php ./extensions/CirrusSearch/maintenance/UpdateSearchIndexConfig.php 
indexing namespaces...
PHP Fatal error:  Declaration of Elasticsearch\Endpoints\Indices\Exists::getParamWhitelist() must be compatible with Elasticsearch\Endpoints\AbstractEndpoint::getPar
amWhitelist(): array in $IP/extensions/Elastica/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Endpoints/Indices/Exists.php on line 45

But that error is completely different (it's not from missing classes), and is detailed in T267106: PHP fatal error while searching index: Declaration of Elasticsearch\Endpoints\Indices\Exists::getParamWhitelist() must be compatible with Elasticsearch\Endpoints\AbstractEndpoint::getParamWhitelist():

This still doesn't seem to work. I'm on MediaWiki 1.35.3, trying to get AWS Elasticsearch v6.5.4 working with CirrusSearch. I've got Elastica 6.1.3 (de9fe84) and elasticsearch/elasticsearch 6.8.1 but when I run the maintenance script I get the error in T267106:

This PHP restriction is completely breaking MediaWiki installation on Ubuntu 20.04 (focal) since that currently has PHP 7.4.3 in its repo. Fortunately, I have a version of MW downloaded from Feb 8, so I can use that, but this patch prevents upgrading MediaWiki as long as Ubuntu doesn't have a new enough version of PHP.