Dec 4 2023
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.)
Apr 6 2023
The comments in MainConfigSchema.php still also say that port 80 is the default for CdnServers:
Jan 11 2023
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.
Dec 16 2022
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.
Nov 28 2022
Jun 20 2022
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.
Jun 15 2022
Is there any work being done on this issue? Any idea of how significant of a risk it is?
Apr 6 2022
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.
Apr 5 2022
Any ideas about this issue?
Feb 23 2022
@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.
Feb 11 2022
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.
Feb 10 2022
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.
Jan 5 2022
Dec 1 2021
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.
Oct 22 2021
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).
Oct 4 2021
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.
Sep 21 2021
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.
Sep 8 2021
Aug 3 2021
Jul 26 2021
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?
Jul 21 2021
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.
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:
Mar 1 2021
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.