Tested on PHP 8.4.12, works fine, anyone want to comment?

El T402723#11112736, @Tacsipacsi escribió:

This is a good idea, but I don’t think it should be a means of, nor a substitute for, CI/CD running on different PHP versions. It can facilitate manual testing across PHP versions, which is also important, and justifies this feature, but automated tests don’t need a publicly available environment (and the infrastructure for running automated tests across PHP versions already exists, it just doesn’t include PHP 8.4 yet).

• Security improvements: Test security patches against all supported PHP versions

I don’t think security patches should be tested on Patch Demo: https://patchdemo.wmcloud.org/ publicly lists all demo wikis, along with their patches, which should likewise be public, and this could lead to premature disclosure of security bugs.

I understand what you have said, my idea was written a bit out of ignorance :D I must debug things I wrote that were unnecessary, I opened the task mostly for issues of testing PHP compatibility, more than saying that it is for critical risk tests among other tests

Example testing the T400401 error that I reported, I had to create several environments to give details with the error even though it does not affect production but it cannot be tested with stable versions of PHP

El T400401#11104723, @Jdlrobson-WMF escribió:

Is this a production error at time of writing?

I was talking about this, I forgot.

<includeonly>{{subst:Bot bug report on [[Special:Diff/$1| review]]
|Page where the error occurred = [[$2]]
|Description and comments about the error =
}}</includeonly>

How to configure the parameters since in eswiki we only have the button active, the sending of talk messages is disabled, how do I configure the parameters button?

AutoModerator will not work because it does not have the training model endpoint loaded, as it is in the configuration for wikis

Nice job, I was confused

The issue is that the report button can be added with

?action=edit&preload=MediaWiki:AutoModerator-preload&section=new

the revision ID parameter can be received, and the issue is how it can be received

Well, for the extensions included in MediaWiki or any made by the WMF staff, this manual review is not required. I'll give you the ones made by third parties.

El T382565#10797941, @Yaron_Koren escribió:

@Danielyepezgarces - do you mean, in order to update the revision of each extension/skin automatically? If so, I disagree: part of the promise of this extension is predictability, which is tied in with security - so the revisions used should change (a) infrequently and (b) with some amount of oversight.

We can model an automatic distribution using the Wikimedia Gerrit API to update frequently

I have made a PR on Github correcting said error and it currently works now

This appears in the MediaWiki master code

A lot of time has passed and I’ve forgotten some details, but in summary, when I used that endpoint and there were deleted revisions in between, the parameters came out as null. What I half remember from what you told me is that the replication might include deleted revisions, and maybe that’s why it failed. However, in the XTools frontend, it did correctly return the original author — and that’s why I asked for that issue to be analyzed and fixed

El T391929#10742781, @Aklapper escribió:

Hi, thanks for reporting this! I do not plan to track upstream Dark Mode issues in Wikimedia Phabricator itself as I personally don't mind about dark mode. :)
Please feel ery encouraged to report any dark mode issue to https://we.phorge.it/ if this is not already covered in https://we.phorge.it/T15056 - thanks a lot!

Image uploaded to Commons
https://commons.wikimedia.org/wiki/File:Powered_by_Debian_V2.svg

Check this version, following your requests https://test.wikipeoplestats.org/w/resources/assets/poweredby_debian.svg?version=3

Opinions, I also have it in SVG version

It would not fulfill the same function, for example Cloudflare does not support SSL for subdomain wildcards, that is why I generated the certificates as I mentioned using Certbot.

DNS changed to the required one, but it constantly redirects to Help:Cloud_Services_introduction
Something else needs to be done

In passing, they could prepare to add support for most JavaScript frameworks such as React, Vite, Remix or any other since I see that the documentation to create a web service with any of the aforementioned does not exist and for many like me it is difficult :’) and perhaps it would be interesting to give support to any of these new technologies and not only static sites made with Node.js and Express

For large data sets it is better to use QLever, WDQS falls short

El T389440#10689984, @Pnlarbi escribió:

@Danielyepezgarces the Vercel deployment looks really good

I have recreated this tool by fixing most of the bugs it had and adding most of the Wikimedia projects.
Features
Added Features:

• Responsive UI
• Localization in many languages
• Sharing system via link or QR code

That sounds fine for third parties, at Wikimedia I think traditional update methods should continue to be used due to the great SysAdmin team that exists, but for novice people or those with little knowledge of complex technical topics it is better to have a Package Manager style on the frontend like Wordpress as @Samwilson mentions and the person receives notifications of stable or unstable updates as is done in other CMS.

To make those suggestions you must write it in the creator's repository
https://github.com/kaliacad/LeaderBoard/issues

My project uses recently this API: https://es.wikipeoplestats.org/event/tiempo_feminista_para_editar_wikipedia

Additionally, I believe that when include_private=false is used, a counter with the number of private users should be returned.

P.S: I have read that last_participant_id exists for pagination, but it is not the most effective for research projects or that the limit should be higher like maxlimit

We can test it so you can create a test instance before executing a command in production

And why do you want it for a specific user? If in the same way, that script fulfills the same function

After running that script, you should use initEditCount.php to update the edit counts.

@MusikAnimal when will this be patched?

You need to add a screenshot for more proofs

Unsolved task, it would also be good to add the pageid parameter

Wikipedias that use 5 events and its respective source page

• enwiki - {{Wikipedia:Selected anniversaries/{{#time:F j}}}}
• eswiki - {{Efemérides|{{CURRENTYEAR}}{{CURRENTMONTH}}{{CURRENTDAY2}}}}
• dewiki - {{Wikipedia:Hauptseite/Jahrestage/{{CURRENTMONTHNAME}}/{{CURRENTDAY}}}}
• viwiki - {{Wikipedia:Ngày này năm xưa/{{#time:m/d}}}}
• zhwiki - {{Wikipedia:历史上的今天/{{CURRENTMONTHNAME}}{{CURRENTDAY}}日}}
• idwiki - {{Hari Ini Dalam Sejarah/{{#time: F}}|{{#time:j F}}}}
• mswiki - {{Wikipedia:Hari ulang tahun pilihan/{{#time: j F}}}}
• zh-minwiki - {{Wikipedia:Tong-nî ê kin-á-ji̍t/{{CURRENTMONTH1}} goe̍h {{CURRENTDAY}} ji̍t}}
• cswiki - {{Wikipedie:Vybraná výročí dne/{{MÍSTNÍDEN}}. {{MÍSTNÍMĚSÍCJMÉNO}}}}
• euwiki
• kowiki - {{위키백과:오늘의 역사/{{#time: m월 d일|{{CURRENTTIME}}}}}}
• shwiki - {{Šablon:Na današnji dan/{{CURRENTDAY}}.{{CURRENTMONTH}}.}}
• fiwiki - {{Malline:{{#time: d. F|{{CURRENTTIME}}}}ta}}
• trwiki - {{Tarihte bugün/{{#time:j}} {{#time:F}}}}
• lvwiki - {{Vikipēdija:Izmeklēti notikumi/{{CURRENTDAY}}. {{Menesis-nom|{{CURRENTMONTH}}}}}}
• thwiki - {{วิกิพีเดีย:วันนี้ในอดีต/{{#timel:j F}}}}

El T379509#10352422, @Lucas_Werkmeister_WMDE escribió:

In T379509#10351448, @Danielyepezgarces wrote:

Reviewed in master (450427c9b27a393a1b3e174eb02b0912f7dbfea2) and REL1_43 (5dce8bb8020182a41d1f04cf73a33b64ffe3ebaa)

Fatal error: Declaration of Wikibase\Repo\ParserOutput\PlaceholderEmittingEntityTermsView::getHtml($mainLanguageCode, Wikibase\DataModel\Term\TermList $labels, Wikibase\DataModel\Term\TermList $descriptions, ?Wikibase\DataModel\Term\AliasGroupList $aliasGroups = null, ?Wikibase\DataModel\Entity\EntityId $entityId = null) must be compatible with Wikibase\View\SimpleEntityTermsView::getHtml($mainLanguageCode, ?Wikibase\DataModel\Term\TermList $labels, ?Wikibase\DataModel\Term\TermList $descriptions, ?Wikibase\DataModel\Term\AliasGroupList $aliasGroups = null, ?Wikibase\DataModel\Entity\EntityId $entityId = null) in \mediawiki\w\extensions\Wikibase\repo\includes\ParserOutput\PlaceholderEmittingEntityTermsView.php on line 86

Where did you get this error? In I9e6d4f00ec both view/src/SimpleEntityTermsView.php and repo/includes/ParserOutput/PlaceholderEmittingEntityTermsView.php were changed from AliasGroupList $aliasGroups = null, EntityId $entityId = null to ?AliasGroupList $aliasGroups = null, ?EntityId $entityId = null, but I don’t see $labels or $descriptions being nullable anywhere.

Reviewed in master (450427c9b27a393a1b3e174eb02b0912f7dbfea2) and REL1_43 (5dce8bb8020182a41d1f04cf73a33b64ffe3ebaa)

Fatal error: Declaration of Wikibase\Repo\ParserOutput\PlaceholderEmittingEntityTermsView::getHtml($mainLanguageCode, Wikibase\DataModel\Term\TermList $labels, Wikibase\DataModel\Term\TermList $descriptions, ?Wikibase\DataModel\Term\AliasGroupList $aliasGroups = null, ?Wikibase\DataModel\Entity\EntityId $entityId = null) must be compatible with Wikibase\View\SimpleEntityTermsView::getHtml($mainLanguageCode, ?Wikibase\DataModel\Term\TermList $labels, ?Wikibase\DataModel\Term\TermList $descriptions, ?Wikibase\DataModel\Term\AliasGroupList $aliasGroups = null, ?Wikibase\DataModel\Entity\EntityId $entityId = null) in \mediawiki\w\extensions\Wikibase\repo\includes\ParserOutput\PlaceholderEmittingEntityTermsView.php on line 86

Oh right, I already updated, and it's fixed :D I had forgotten to update composer

I already removed the whitespace

How do I update the patch using git push-for-review?

I think that for now, I will not touch anything, someone will correct it for me, I think my contribution was a failure

El T379509#10325533, @Reedy escribió:

No, we put things on master first, unless the bug isn’t there anymore.

I haven’t checked the patch yet, but the wiki data devs didn’t just want it doing automatically…

El T379509#10325504, @gerritbot escribió:

Change #1091588 had a related patch set uploaded (by Danielyepezgarces; author: Danielyepezgarces):

[mediawiki/extensions/Wikibase@REL1_43] Use explicit nullable type on parameter arguments (for PHP 8.4)

https://gerrit.wikimedia.org/r/1091588

El T379777#10317934, @Prototyperspective escribió:

Been too slow to re-test it: it's still happening so it's repeatable. I don't understand what you mean with "that error doesn't exist". I went from the English article directly to the search which is still set to Spanish and entered some part of the article title.

El T379777#10317872, @Prototyperspective escribió:

@Danielyepezgarces Did you first open the English Wikipedia article and while having that tab open search in the other language? The above are screenshot of the bug as it happened so clearly there is an issue and I did not upgrade the Wikipedia app in the meantime. I will try with another article but even if it does not reoccur there is a bug somewhere (maybe really low importance if it occurs just very rarely but I'll test).

Work fine in app install clean

In T379509#10307988, @Reedy wrote:

What version of the Wikibase extensions are you using? If it's REL1_43, CI probably hasn't gotten to it yet...

CC: T379481: [GENERAL] PHP 8.4 issues in WMDE/Wikidata libraries

List for Wikibase Client

Deprecated: Wikibase\Client\WikibaseClient::getDefaultValueFormatterBuilders(): Implicitly marking parameter $services as nullable is deprecated, the explicit nullable type must be used instead in mediawiki\w\extensions\Wikibase\client\includes\WikibaseClient.php on line 97

rGOJU011d1ad6d3c6: Use explicit nullable type on parameter arguments but unreleased.

ok

Deprecated: Wikimedia\ScopedCallback::consume(): Implicitly marking parameter $sc as nullable is deprecated, the explicit nullable type must be used instead in /var/www/wiki/mediawiki/core/vendor/wikimedia/scoped-callback/src/ScopedCallback.php on line 57 and 66

In T379125#10302020, @Reedy wrote:

Well, PHP 8.4 isn't released yet, and as such, we haven't declared it as supported (because of various known outstanding issues on PHP 8.4 support)

The installer doesn't work either

$ mw-config/index.php

This means that a clean installation with PHP 8.4 is not possible

Has anyone thought about removing E_STRICT or using E_ALL

In T379125#10294646, @Reedy wrote:

Which extension?

Does it work without?

See also T375707: Avoid E_STRICT in MediaWiki and WMF-deployed extension (Deprecated in PHP 8.4)

I understand, well I replaced the blue color with the wiki theme, many table notices are used and the links were not distinguished from the text.
Example: https://es.wikipedia.org/wiki/Wikipedia:Tabl%C3%B3n_de_anuncios_de_los_bibliotecarios

When will eswiki be ready to be included in the next deployment?

es.wikipedia.org (baseline) 848 errors, last updated 77 hrs ago
es.wikipedia.org (night mode) 541 errors, last updated 77 hrs ago

And ask when the statistics are updated to see what things remain to be corrected. @Jdlrobson

In eswiki it happened on July 19 at 00:30 UTC around that time and from then on the error began to appear.

Dark mode can be disabled in source mode for eswiki beta testers?

As an experienced eswiki user, I think it was very hasty to activate the theme preference when there were so many errors. I think I can contribute something, but I don't know what tasks are essential to reduce that number of errors.

Spanish Wikipedia does not appear in the check report

In T367150#9928974, @KSarabia-WMF wrote:

Dark Mode Accessibility Check Report

Wiki Prefix	Wiki Name	Errors in Light Mode	Errors in Dark Mode	Difference (%)	Tier
ami	Ami Wikipedia	267	294	9.63%	2
ar	Arabic Wikipedia	28342	35024	21.09%	3
arz	Egyptian Arabic Wikipedia	3413	10013	98.32%	3
azb	Azerbaijani Wikipedia	2879	4692	47.89%	3
ban	Balinese Wikipedia	6596	6404	-2.95%	1
be	Belarusian Wikipedia	998	8733	158.98%	3
bjn	Banjar Wikipedia	4293	2752	-43.75%	1
bs	Bosnian Wikipedia	13184	15171	14.02%	2
ca*	Catalan Wikipedia	6676	11118	49.93%	3
cv*	Chuvash Wikipedia	2289	9304	121.02%	3
en*	English Wikipedia	6445	3051	-71.48%	1
simple*	Simple English Wikipedia	5732	5756	0.42%	2
eu*	Basque Wikipedia	5121	11688	78.14%	3
fa	Persian Wikipedia	10509	11687	10.61%	2
fi*	Finnish Wikipedia	714	707	-0.98%	1
fiu-vro*	Võro Wikipedia	7994	9487	18.68%	2
fr*	French Wikipedia	7938	14130	59.07%	3
frp*	Franco-Provençal Wikipedia	3107	3988	24.06%	2
gan*	Gan Chinese Wikipedia	1477	2708	64.00%	3
gl*	Galician Wikipedia	1422	1792	22.61%	2
gu*	Gujarati Wikipedia	552	3551	543.66%	3
hif*	Fiji Hindi Wikipedia	1919	2156	12.35%	2
hr*	Croatian Wikipedia	2905	3724	28.19%	2
hu*	Hungarian Wikipedia	3293	5430	64.91%	3
is*	Icelandic Wikipedia	2616	5488	109.88%	3
it*	Italian Wikipedia	8951	12552	32.30%	3
ja*	Japanese Wikipedia	35408	31808	-10.17%	1
jv*	Javanese Wikipedia	2157	5618	160.45%	3
kab*	Kabyle Wikipedia	608	5112	740.79%	3
km*	Khmer Wikipedia	1589	3081	93.95%	3
ko*	Korean Wikipedia	20635	13143	-44.10%	1
ku*	Kurdish Wikipedia	1445	5352	270.46%	3
la*	Latin Wikipedia	4818	6392	32.67%	3
lt*	Lithuanian Wikipedia	1282	1813	41.38%	3
mhr*	Meadow Mari Wikipedia	1442	1425	-1.18%	1
mn*	Mongolian Wikipedia	725	4562	529.93%	3
ms*	Malay Wikipedia	4075	3384	-20.47%	1
nah*	Classical Nahuatl Wikipedia	645	2418	274.29%	3
oc*	Occitan Wikipedia	4398	8920	52.51%	3
szy*	Sakizaya Wikipedia	61	445	151.78%	3
te*	Telugu Wikipedia	647	1283	65.91%	3
tg*	Tajik Wikipedia	2439	6296	88.31%	3
tum*	Tumbuka Wikipedia	3471	3049	-12.94%	1
uk*	Ukrainian Wikipedia	7659	7810	1.95%	2
ug*	Uyghur Wikipedia	884	3744	123.60%	3
wuu*	Wu Chinese Wikipedia	1629	1834	11.84%	2
yo*	Yoruba Wikipedia	3189	7678	82.62%	3
zh-yue*	Cantonese Wikipedia	4889	4909	0.41%	2
za*	Zhuang Wikipedia	1516	2253	39.11%	3
zh*	Chinese Wikipedia	50305	16125	-102.91%	1

* Means we went down to 500 for expediency sake

Not work, only work disabling DNS Proxy in Cloudflare but this is bad for origin server