- Blog: https://timotijhof.net
- Mastodon: @krinkle
(Photo by Niek Hidding.)
(Photo by Niek Hidding.)
It's good to record the user demand here, but moving Less.js 4.x feature to Radar for now as we'd want to do T288498: Update less.php port to support Less.js 3.13 behaviours first.
Task descriptionLog messageCould not send confirmation email: Unknown error in PHP's mail() function.
In T290932#10490510, @matmarex wrote:Can you explore a path forward where we discourage all except the existing localBasePath, and derive remoteBasePath automatically?
I don't see how that could be done without breaking backwards compatibility. It's already valid to omit all of remoteBasePath/remoteExtPath/remoteSkinPath, it has the same effect as specifying remoteBasePath' => $wgResourceBasePath. […]
Tagging Unstewarded-production-error since MediaWiki-Uploading is unassigned on mw:Maintainers.
+1 for waiting until PHP 8.4. I believe @TK-999 has tried this back at Fandom, and filed several issues upstream where it crashed with MediaWiki.
@Daimona This makes sense to me and seems worth trying.
After:
The message types are still mixed up, but with one less piece of evidence remaining to make this obvious. Following up in T384524: Installer message types are mixed up (warnings are notices and notices are warnings).
In T290932#10471468, @matmarex wrote:I was reminded of this today, and I had a thought.
The idea in the task description is to allow omitting (remoteExtPath|remoteSkinPath|remoteBasePath), and computing it from the (localExtPath|localSkinPath|localBasePath)[…]
[…]why not just allow omitting them both and specifying a basePath instead, and then computing both the local and remove base path from it […]
@phuedx Two things to check:
In T383916#10471466, @Tgr wrote:[…] This reminds me of when WMF supported a mixed HTTP/HTTPS setup and […] adopting a protocol-relative URL, […]
This is actually a somewhat different issue […]
In T383128#10457319, @hashar wrote:[…] I haven't dig into details, we should probably remove those old versions anyway.
I've added the case as number 14 to https://www.mediawiki.org/wiki/Extension:Math/Native_MathML/Reported_Cases.
I'd rather not start patching core to support variable values for $wgArticlePath, that would go pretty deep and would imply that developers aren't permitted to cache this anywhere else (or it becomes an untested and WMF-specific hack for only things that we need, which seems unsustainable long-term as a continous whack-a-mole we can never retire from). Core either supports it or it doesn't. E.g. edit notices, footer, copyright editpage messages are/were also cached at various points (including e.g. as parsed message in a data module for JavaScript). This would go pretty deep.
@bd808 Is there a deprecation warning or other production error from TemplateStyles on PHP 8.1? I could not find one in Logstash.
There appears to be some versions that are much larger than others.
The specific scenario here is:
With the patch applied locally, it renders bold in both (top Chrome, bottom Firefox):
I've added this as case 13 at https://www.mediawiki.org/wiki/Extension:Math/Native_MathML/Reported_Cases.
@cscott I found this warning in the logs just now when doing some PHP 8.1 testing via WikimediaDebug.
In T381070#10366396, @SalixAlba wrote:See also T270348 with the same title.
This problem has been around for a long time. It does tend to cure itself after a while when pages get re-rendered. We have tracking categories https://en.wikipedia.org/wiki/Category:Articles_with_math_errors that will pick up the error.
You can force a page to rerender with a purge, which normally fixes it
Rates of this error used to be much higher than now.