A bit about Security

This is probably not so simple. Doing that change causes this problem:

I really like the idea here. Nice research :)

The sysop sees the email addresses of recipients already anyway by running an SQL query in the database if they operate the system anyway.
Running SQL queries is what I've been doing so far and it's cumbersome. Thus my request to allow this on an API level.
(I don't mind how MediaWiki behaves as that software covers different use cases.)

Unsure how to help here :) If this happens again, please reopen. Thanks!

At the moment I'm manually tracking things in this page:

I double-checked and I'm quite sure that this fixes the issue reported by the kind @speck

Added unit test

Can I ask how to reproduce this problem?

In D25267#8682, @valerio.bozzolan wrote:

__________________________________ < Overlap detected! Already fixed! > ---------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

Mistery resolved! Git was right. The patch was not successfully land-able since the kind user @aklapper already landed a fix for this 3 days ago

rP1c098c273d06: Fix PHP 8.1 "strlen(null)" exception calling Conduit's user.whoami

Ouch :D

Thank you very much anyway @mturdus - For consolation, you unlocked this command:

arc anoid

Indeed the maintenance message should always be null or a string. Soft +1 for a week. Then hard +1.

Another possible idea: we can approve this change (again, premising that isset($message) and $message !== null are equivalent - but I don't have an opinion - so OK to keep isset($message))

Premising that - to me - there was a bug in the already-existing code.

What do you think about this? In this way there are no exceptions in the error log

propose the soft error

I think this problem is infrastructure-related and not software-related. But feel free to reopen attaching more details

Another compromise could be, on small screens, hiding the time details and enlarge a bit the title. Example:

Somehow "Normal" in 2023 I think - at least in Maniphest. But probably not so important.

On this I think it does more or less the same as MediaWiki: the sysop does not see the emails of participants, not even via API.

Are you ready to laaand @20after4 ✨

(Premising that I liked to write a wall of text against Microsoft, randomly)

cover all the cases

I didn't read the whole novel in the description, but keep in mind that remarkup is very performance sensitive, so make sure not to add any complex algorithms.

Tested locally, both the feed and the history log, with without serious business mode

I uncommented a line in the editor executed by arc diff and it seemed to work

Updating D25267: Fix PHP 8.2 "trim(null)" exception which causes Conduit's user.whoami to fail

In T15480#10429, @valerio.bozzolan wrote:

Just for my curiosity, is serious business mode enabled in Wikimedia?

Yes, because I'd like to allow people to understand what is going on. Not everybody speaks perfectly "omg that's so phunny" English. "Set Sail for Adventure", really?

OK don't worry, you are almost there!

Thank you very much for this change. Hoping to be useful I tried to follow the indications from speck here:

Just for my curiosity, is serious business mode enabled in Wikimedia? I think nope

I'm sorry I didn't know I had to more.

Would you love an amend also here, to try the setError approach?

Thanks again for this patch

Tested, works, thanks :)