up

When hovering over the last item, it made the containers feel too close together, so I increased the value to 3.2rem

Before	After

El T419333#11685717, @Aklapper escribió:

Hi, as Wikimedia Phabricator is for bug reports, enhancement requests, and planning work, please check https://www.mediawiki.org/wiki/Communication for venues for configuration questions - Thanks for your understanding!

That old task speaks particularly of using the action=block in the filters
in general, this one that was done was to argue its need or use, and the
other task I did is because I tried to put a notice with the strings but it
is not rendering well so they are very different things

But there is no solution to be able to handle that type of situation
because there are no conditions for block in abuse filter nor is it working
in the interface put better warnings in Special:Block as in this failure
(T419333)

This task was asked to me by a local check user because in eswiki they are
doing bad practices of blocking temp accounts, the new Wikimedia policies
say that the one who has the
Temporary account IP viewers right should be cautious and many are putting
those blocking summaries and there is no possible filter to avoid that, for
now more than putting a warning in the Special:Block interface

You need to install the missing dependency (Smarty) for the Widgets extension.

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