bsitu: Could you take a look at this, as this might be a regression from the fix in bug 14901?

bsitu wrote:

I will take a look at this

bsitu wrote:

I tried it on enwiki, zhwiki, frwiki and my local dev with french language, this works on all of them except frwiki. frwiki is running the same mediawiki version(1.21wmf5) as enwiki and zhwiki. I am not quite sure what's causing the problem at this moment. The following is an email copy from my local dev:

Cher Bsitu,

La page Discussion utilisateur:Bsitu sur git-core-wiki a été modifiée
le 2012-12-07 par Test, voir
http://git-core/index.php?title=Discussion_utilisateur:Bsitu pour la
révision actuelle.

Voyez
http://git-core/index.php?title=Discussion_utilisateur:Bsitu&diff=next&oldid=4150
pour visualiser ces changements.

Voyez
http://git-core/index.php?title=Discussion_utilisateur:Bsitu&diff=0&oldid=4150
pour tous les changements depuis votre dernière visite.

Résumé du contributeur : -

Contactez ce contributeur :
courriel :
http://git-core/index.php?title=Sp%C3%A9cial:Envoyer_un_courriel/Test
wiki : http://git-core/index.php?title=Utilisateur:Test

Il n'y aura pas d'autres notifications en cas de changements
ultérieurs, à moins que vous ne visitiez cette page. Vous pouvez aussi
réinitialiser les drapeaux de notification pour toutes les pages de
votre liste de suivi.

Votre système de notification de git-core-wiki

Pour modifier les paramètres de notification par courriel, visitez
http://git-core/index.php?title=Sp%C3%A9cial:Pr%C3%A9f%C3%A9rences

Pour modifier les paramètres de votre liste de suivi, visitez
http://git-core/index.php?title=Sp%C3%A9cial:EditWatchlist

Pour supprimer la page de votre liste de suivi, visitez
http://git-core/index.php?title=Discussion_utilisateur:Bsitu&action=unwatch

Retour et assistance :
http://git-core/index.php?title=Aide:Accueil

dewiki as well, some email server out of sync? Dewiki is running 1.21wmf5 (0d30be3)

It's the same for me on it.wiki:

Gentile Nemo bis,

$PAGEINTRO Vedere
http://it.wikipedia.org/w/index.php?title=Discussioni_utente:Nemo_bis&diff=next&oldid=54456945

per visualizzare la modifica.

etc.

See [[translatewiki:MediaWiki:Enotif_body/qqq]] for the meanings of all parameters; [[it:MediaWiki:Enotif_body_intro_changed]] is correct.

By the way the wrong newlines above are fixed by gerrit change 37299.

bsitu wrote:

(In reply to comment #5)

It's the same for me on it.wiki:

Gentile Nemo bis,

$PAGEINTRO Vedere
http://it.wikipedia.org/w/index.php?title=Discussioni_utente:
Nemo_bis&diff=next&oldid=54456945

per visualizzare la modifica.

etc.

See [[translatewiki:MediaWiki:Enotif_body/qqq]] for the meanings of all
parameters; [[it:MediaWiki:Enotif_body_intro_changed]] is correct.

By the way the wrong newlines above are fixed by Gerrit change #37299.

Thanks for fixing that

bsitu wrote:

Hi Sam,

Could you help take a look at this?

Thanks,

(In reply to comment #5)

By the way the wrong newlines above are fixed by Gerrit change #37299.

I abandoned that change because the newlines are supposed to be added by the code, even though they fail in this case.

While debugging this bug on it.wikinews, I verified it for user talk and normal page edit and also for page creation; in the latter case I received:

Gentile Nemo bis,

$PAGEINTRO Questa è una nuova pagina.

So for some reason $NEWPAGE is being substituted with 'enotif_newpagetext', but this message has been removed in https://gerrit.wikimedia.org/r/#/c/7986/14/includes/UserMailer.php and is no longer in MessagesIt.php.

On mediawiki.org, I've created [[mw:Fréttinga]] with another account and I didn't receive any enotif; but when I deleted it, the other account received this:

Dear AnankeBot,

the MediaWiki page Fréttinga has been created on 9 December 2012 by Nemo
bis, see http://www.mediawiki.org/wiki/Fr%C3%A9ttinga for the current
version.

This is a new page.

Which has $PAGEINFO substituted, but again 'enotif_newpagetext' which is not supposed to be there.

So looks like the whole logic has some problem.

bsitu wrote:

(In reply to comment #8)

(In reply to comment #5)

By the way the wrong newlines above are fixed by Gerrit change #37299.

I abandoned that change because the newlines are supposed to be added by the
code, even though they fail in this case.

While debugging this bug on it.wikinews, I verified it for user talk and
normal

page edit and also for page creation; in the latter case I received:

Gentile Nemo bis,

$PAGEINTRO Questa è una nuova pagina.

So for some reason $NEWPAGE is being substituted with 'enotif_newpagetext',
but
this message has been removed in
https://gerrit.wikimedia.org/r/#/c/7986/14/includes/UserMailer.php and is no
longer in MessagesIt.php.

On mediawiki.org, I've created [[mw:Fréttinga]] with another account and I
didn't receive any enotif; but when I deleted it, the other account received

this:

Dear AnankeBot,

the MediaWiki page Fréttinga has been created on 9 December 2012 by Nemo
bis, see http://www.mediawiki.org/wiki/Fr%C3%A9ttinga for the current
version.

This is a new page.

Which has $PAGEINFO substituted, but again 'enotif_newpagetext' which is not
supposed to be there.

So looks like the whole logic has some problem.

enotif_newpagetext ( This is a new page. ) has been removed from the code base, it looks like the email server mediawiki runs against is still having the old code

richardg_uk wrote:

I am now receiving emails with the literal text "$CHANGEDORCREATED" instead of the relevant type of change.

For example:

On 10 Dec 2012, at 21:57, MediaWiki Mail <wiki@wikimedia.org> wrote:

Dear Richardguk,

the MediaWiki page MediaWiki 1.21/wmf6 has been $CHANGEDORCREATED on
2012-12-10 by Sharihareswara (WMF), see
http://www.mediawiki.org/wiki/MediaWiki_1.21/wmf6 for the current
version.

...

(In reply to comment #10)

I am now receiving emails with the literal text "$CHANGEDORCREATED" instead
of
the relevant type of change.

For example:

On 10 Dec 2012, at 21:57, MediaWiki Mail <wiki@wikimedia.org> wrote:

Dear Richardguk,

the MediaWiki page MediaWiki 1.21/wmf6 has been $CHANGEDORCREATED on
2012-12-10 by Sharihareswara (WMF), see
http://www.mediawiki.org/wiki/MediaWiki_1.21/wmf6 for the current
version.

...

On which wiki?

I'd expect these problems briefly given the asynchronous nature of the job queue and that runJobs can still be running the old code until it finishes and restarted by the jobs-loop.sh script. But that should last more than several hours or day (unless the maxJobs parameter to runJobs is too high or they take too long).

richardg_uk wrote:

(In reply to comment #11)

On which wiki?

MediaWiki, as in the example email extract. Emails sent 21:30 and 21:57.

I have not received any other notifications from MW or any other wikis in the past few hours, so do not know whether this is widespread.

(In reply to comment #12)

I'd expect these problems briefly given the asynchronous nature of the job
queue and that runJobs can still be running the old code until it finishes
and
restarted by the jobs-loop.sh script. But that should last more than several
hours or day (unless the maxJobs parameter to runJobs is too high or they
take
too long).

Actually comment 0 was probably more to the point: according to [[mw:MediaWiki_1.21/wmf6#Most_important_changes]] the new enotif system is in wmf6, but the new enotif_body and related messages were deployed together with wmf5 (?!).

Could the old key replacements be added back for backwards compatibility? There was another bug report (42941) with problems when wikis had customized MediaWiki: pages for messages.

(In reply to comment #15)

Could the old key replacements be added back for backwards compatibility?
There
was another bug report (42941) with problems when wikis had customized
MediaWiki: pages for messages.

You mean keep replacing the old named parameters, unused in the new messages, also in the new code? That wouldn't be a bad idea IMHO, but it belongs to bug 42941 (or a new bug): $PAGEINTRO is in the new messages but not in the old code, the opposite.

bsitu wrote:

(In reply to comment #16)

(In reply to comment #15)

Could the old key replacements be added back for backwards compatibility?
There
was another bug report (42941) with problems when wikis had customized
MediaWiki: pages for messages.

You mean keep replacing the old named parameters, unused in the new messages,
also in the new code? That wouldn't be a bad idea IMHO, but it belongs to bug
42941 (or a new bug): $PAGEINTRO is in the new messages but not in the old
code, the opposite.

Yeah, we can keep replacing the old parameters so customized template will not break. In the future, I guess we should add more information to the release note on what has been added/removed.

I just tried frwiki, it's still showing $PAGEINTRO. Aaron, do you expect this problem to be cleared when jobs-loop.sh gets restarted?

I just noticed the "$CHANGEDORCREATED" text in an e-mail from ptwikibooks.

Lots of languages still have this:

alex@alex:/var/www/MediaWiki/Git/core$ grep "CHANGEDORCREATED" languages/messages/*.php | wc -l
120

mr.heat wrote:

Not sure if this should be fixed and when. Currently I always get this email when somebody edits my discussion page in the German Wikipedia:

Hallo TMg,

$PAGEINTRO Siehe
http://de.wikipedia.org/w/[...]

I cut the URL here. The email is fine except for the single $ placeholder in the third line.

Aaron, do you expect
this
problem to be cleared when jobs-loop.sh gets restarted?

Ditto. Can someone please look into this or try and restart those scripts?

All of the runJob.php scripts I saw running on the job runners when I just checked them were from within the last 5 minutes; restarting the jobs-loop.sh won't fix that sort of issue.

enotif_body in /usr/local/apache/common/php-1.21wmf5/cache/l10n/l10n_cache-de.cdb, and I assume in the other wmf5 cdb files, has $PAGEINTRO in it.
/usr/local/apache/common/php-1.21wmf5/includes/UserMailer.php does not have $PAGEINTRO in it, and thus it is not ever expanded. This is the case on all jobrunners, ad I assume on all mw instal hosts.

I don't know which of the above files is wrong and should be changed.

bsitu wrote:

Hi Ariel,

$PAGEINTRO is a newly introduced variable since 1.21wmf5. It should be in UserMailer.php. In this case, this file is not up to date and should be changed.

There have been two recent reports of "$CHANGEDORCREATED" showing up in notification e-mails from the English Wikipedia.

Sending e-mails like this isn't acceptable. The relevant code needs to be promptly fixed or reverted to a working state. Setting this bug to "immediate" priority, but "minor" importance: this bug doesn't seem to be damaging anything, but it does need to be fixed as soon as possible.

bsitu wrote:

(In reply to comment #25)

There have been two recent reports of "$CHANGEDORCREATED" showing up in
notification e-mails from the English Wikipedia.

Sending e-mails like this isn't acceptable. The relevant code needs to be
promptly fixed or reverted to a working state. Setting this bug to
"immediate"
priority, but "minor" importance: this bug doesn't seem to be damaging
anything, but it does need to be fixed as soon as possible.

My schedule is pretty tight in the coming few days. I will try to add "$CHANGEDORCREATED" back for custom enotif_body backwards compatibility support. It's my carelessness that I did not realize wikis would customize enotif_body. :(, This is related to another bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=42941

(In reply to comment #26)

My schedule is pretty tight in the coming few days. I will try to add
"$CHANGEDORCREATED" back for custom enotif_body backwards compatibility
support. It's my carelessness that I did not realize wikis would customize
enotif_body. :(, This is related to another bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=42941

In the meantime, Ironholds has changed the message to just read 'changed'.

http://en.wikipedia.org/w/index.php?title=MediaWiki%3AEnotif_body&diff=528569865&oldid=489716103

In the short-term, someone needs to go through the Wikimedia wikis and fix the messages. Sending out broken e-mails makes us all look like idiots. This is bad. I've made a request at the English Wikipedia talk page (now fulfilled, thank you Ori and Ironholds).

Thank you Nemo for posting on the various MediaWiki talk pages, though I'm afraid nobody watches that page on any wiki, so only really small (inactive) wikis will see the change at Special:RecentChanges. We'll need to work on a better notification system for changes like this.

In the long-term, this needs backward-compatibility code so that other wikis (non-Wikimedia wikis) don't have to deal with this.

bsitu wrote:

I applied a fix in here: https://gerrit.wikimedia.org/r/#/c/39179/, which would fix $CHANGEDORCREATED in custom template

(In reply to comment #12)

I'd expect these problems briefly given the asynchronous nature of the job
queue and that runJobs can still be running the old code until it finishes
and
restarted by the jobs-loop.sh script. But that should last more than several
hours or day (unless the maxJobs parameter to runJobs is too high or they
take
too long).

*should not last more*

(In reply to comment #28)

Thank you Nemo for posting on the various MediaWiki talk pages, though I'm
afraid nobody watches that page on any wiki, so only really small (inactive)
wikis will see the change at Special:RecentChanges. We'll need to work on a
better notification system for changes like this.

All this is bug 42941, you're cluttering this report of a (true) bug with unrelated stuff. And the MediaWiki_talk notification worked on other top ten wikis, why en.wiki failed at this is left as an exercise for the reader.

(In reply to comment #25)

Setting this bug to "immediate" priority

No, this is not the most urgent thing to fix. Resetting.

Also restoring "critical" which MZ changed by mistake: unlike bug 42941, this makes the enotif almost completely useless (and very annoying) because it doesn't even mention the page it is about, except in the summary.

mr.heat wrote:

I'm sure you will not like the idea but why not add a simple preg_replace('/\$[A-Z]\b/g', '') as a cleanup rule to the code? This does not really fix the problems but at least will make the emails not look so strange. I must agree with some of the comments here. Currently the emails look like they are coming from one of these bad configured spam bots.

• Bug 43259 has been marked as a duplicate of this bug. ***

This bug is now obsoleted by the deployment of 1.21wmf6.
Closing WONTFIX to reflect that it hasn't been fixed in the two weeks when it was a bug and it could be fixed.