Assigning back to wikibugs-l (needed to get notification e-mails out.)

Thomas, please make sure you make your patches against 1.4 CVS if you want them to be included.

reason for introducing dependencies to 581 and 580: Given, that user_talk pages
are treated as every other page (or talk_pages), this also would make enotif
easier.

Created attachment 52
E-mail notification v1.0 complete (tar.gz diff -u against CVS 1.4 phase3 incl. a new file)

This is the first release of the announced enhancement called "E-Mail
Notification on page and user_talk page changes". The comprehensive
documentation can be consulted on http://meta.wikipedia.org/Enotif.

Inside the tar.gz:

1. diff -u (against CVS 1.4)
2. new file /maintenance/archives/patch-email-notification.sql

Please report all your findings to the bugzilla bug tracker.

Tom Gries

attachment diff_1.4_enotif.tar.gz ignored as obsolete

Created attachment 53
E-mail notification v1.0 part 1 of 2 (plain diff file against CVS 1.4)

Same patch, but plain diff file against CVS 1.4

attachment diff_1.4_enotif ignored as obsolete

Created attachment 54
E-Mail notification v1.0 part 2 of 2 (one new file for /maintenance/archives)

E-Mail notification v1.0 (one new file for /maintenance/archives)

attachment patch-email-notification.sql ignored as obsolete

If you remove wikibugs-l from the assignment, you MUST add it to the CC list so
that bugmail reports continue to go through the notification channels.

jeluf wrote:

• Your patch changes the way talk pages are handled, in a not downward compatible way, for no obvious reason.
• We normally try to have the globals a function uses in one place, at the beginning of the function.
• $wgEmailNotificationSystembeepForWatchlistPages etc look like debugging options. MediaWiki already has wfDebug for debugging.
• The UserMailer.php is included in Setup.php. Is this module needed for all pages? My impression was that it is only needed on page change, but not for viewing pages etc? The number of included modules should be kept as small as possible, to reduce memory footprint and PHP compile times.
• For user_newtalk, you always query the database, ignoring that the flag is also available in memcached, which is faster.
• Specifying additional_paramaters for PHP's mail() function generates warnings in safe mode. Do they work under Windows?
• NotifyOnChange doesn't use the MagicWord class, but hardcoded strings. Bad for i18n.
• Please use ' instead of " for string messages that don't require string

interpolation

(e.g., no {$variable} and no \n)

• The date and time functions don't use the Language-objects, but reimplements them in a broken way. For example, German date format is $day. $month $year
• in UserTalkUpdate.php, the code from NotifyOnChange is duplicated. This is a

potential

source for future errors.

• Use CSS for changing the layout of the minor-"m". What does "corr." stand for?
• same for updateletter etc. How would this look like on a green background?
• The updaters.inc update looks strange, user_rights_update etc are handled

using $wgNewTables,

changes were probably not merged correctly.

wmahan_04 wrote:

Thank you for your work. In addition to JeLuF's excellent comments, I wanted
to add:

• It might make your patch easier to read if you didn't include whitespace

changes.

• You add your names to the source 42 times. Documenting changes and taking

credit for your work are good, but at some point it begins to clutter the
code, IMHO.

• Documenting your functions with phpdoc comments would make them more

consistent with the rest of the MediaWiki code (although the existing
code could be improved in that regard)

• What's the point of emitting a beep when an email is sent?

I'm a new developer, and these are only suggestions for you to consider.
Thanks again for taking the time to work on this.

jeluf wrote:

The lines

Patch for email notification on page changes T.Gries/M.Arndt 11.09.2004

are so-called change marks. I know them from other big software projects, where
they are widely used. In my opinion, cvs annotate provides the needed functionality,
too, but I know that others consider it more easy to have these notes inside the
source code.

When using them, I personally would add BUG#454, for easier reference.

Thank you all for your valuable feedback w.r.t. my enotif patch. Don' t panic, I
will not use bugzilla for broadcasting plenty of mails to you ... however, I am
keen to get to know whether anyone of you has really installed it, i.e. to learn
your experiences of installing and using it.

I will duly consider all your suggestions and comment the items in the next
couple of days.
Tom

Created attachment 73
enotif v1.1 diff patch -u -b against phase3 -- please tell me your observations

This new version enotif 1.1 has a text problem fixed when mailing to several
watching users in module UserMailer.php .

I did not yet fixed the several others issues mentioned by Brion, JeLuf and Wil

• Please apologise and be patient with me, I'll do my very best, started with

using diff -u -b - many thanks to all of you helping me as a newbie.

I am still keen to learn from any developer trying my patch (in order to
improve it based on your findings). [ Until now, I did not get a feedback from
someone actually using enotif. ]

Tom Gries
Berlin/Germany

attachment phase3-diff-enotif-1.1 ignored as obsolete

Created attachment 79
enotif V1.2 for MediaWiki REL1_3_5 (diff against REL1_3_5)

I applied the enotif patch now against the 1.3.5 release version. Attached is
the diff file against 1.3.5 (you also need the new file
maintenance/archives/patch-email-notification.sql when you make a fresh
installation). The current version enotif v1.2 complies with many of your
comments/instructions for patches. A major improvement allows now for non-ASCII
usernames and page titles in the mail headers eg. Subject: and To: .

See the other attachment for a COMPLETE tar.gz archive of REL1_3_5 INCLUDING
enotif v1.2 and all others needed files. This complete tar.gz also comprises
the diff file against REL1_3_5.

The tar.gz can be used as a complete substitute for either a complete fresh
installation or an upgrade of an existing database, as it automatically changes
the database structure (if needed). Please make a database backup or nysqldump
before upgrading for safety/fall-back reasons.

attachment enotif_v1.2_against_REL1_3_5.diff ignored as obsolete

The COMPLETE MediaWiki 1.3.5 including Enotif 1.2 can be downloaded from

http://www.tgries.de/mw/enotif/mw1.3.5_incl_enotif1.2.tgz ,

for your fresh or upgrade installations.
This tgz also comprises the enotif V1.2 diff against MediaWiki REL1_3_5 .

Tom

I changed the version info to 1.3.5, because the enotif patch and complete installation tgz are now available for MediaWiki 1.3.5.

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

Created attachment 102
Enotif 1.21 diff against MediaWiki 1.3.6

attachment mw136-mw136enotif121.diff ignored as obsolete

Created attachment 103
Enotif 1.21 diff against previous version MediaWiki 1.3.5 incl. Enotif v1.2

attachment mw135enotif12-mw136enotif121.diff ignored as obsolete

leercontainer-bugzilla wrote:

So why hasn't this been included in CVS and the default package?

(In reply to comment #18)

So why hasn't this been included in CVS and the default package

because I have no developer status yet. Just talked with Emmanuel and he
explained what I have to do. Commit to CVS will follow after I got the rights
and after technical checks- perhaps in the next few hours or tomorrow. Tom

(In reply to comment #18)

So why hasn't this been included in CVS and the default package?

It hasn't been reviewed yet, there's still no e-mail address verification which is highly recommended before adding more e-mail features, and
there's not a current patch against 1.4.

bugzilla_wikipedia_org.to.jamesd wrote:

WikiAdmin may have to be used for urgent or system notices, so it shouldn't be
used for routine notifications caused by random page editors. Better to have the
default from user be {{MediaWiki:Sitetitle}} Page Edit or similar. There is the
X-Mailer field but Subject and From are the two fields on which filters can most
universally be used, so it's better to have such clear tags in those fields.

Limited clients also may limit the From match to only people in the address
book, so some easy string match in the Subject is good. Changing the default
subject from:

{{MediaWiki:Sitetitle}} page $PAGETITLE_QP has been changed by $PAGEEDITOR_QP

to:

{{MediaWiki:Sitetitle}} page changed: $PAGEEDITOR_QP changed $PAGETITLE_QP

would allow a subject match on "{{MediaWiki:Sitetitle}} page changed:". That
should be fairly reliable in filtering rules.

I suggested moving $PAGEEDITOR_QP earlier so that it's easier to filter out page
change notices from those you trust or those you don't want to know about - you
can match on {{MediaWiki:Sitetitle}} page changed: $PAGEEDITOR_QP changed" and
get good filter results.

(In reply to comment #21)

WikiAdmin may have to be used for urgent or system notices, so it shouldn't be
used for routine notifications caused by random page editors. Better to have the
default from user be {{MediaWiki:Sitetitle}} Page Edit or similar.

Agreed. I need to pass this Sitetitle - which can have non-ASCII character to
QuotedPrintable, but will do so.

to:

> {{MediaWiki:Sitetitle}} page changed: $PAGEEDITOR_QP changed $PAGETITLE_QP

would allow a subject match on "{{MediaWiki:Sitetitle}} page changed:". That
should be fairly reliable in filtering rules.

Agreed. This is an easy (cosmetic) change, and if you are happy with it: I am.

My "Agreed" means, that I will change the defaults in Language.php accordingly
to your two proposals. Everyone WikiAdmin who whishes so, can further modify
his/her MediaWiki:Email_notification_messagetext "live" on the program, as you
certainly know.

Tom Gries

Reasons why I declared dependency from bug 603 (delete + undelete cycle doesn't preserve old_id):

Enotif versions > 1.21 will use "old_id" in emails to give a watching user a direct link to the *difference view* between current
and last visited version of a watch-listed page, this was recently requested by some users.

{{SERVER}}{{localurl:namespace:pagettitle|diff=0&oldid=$OLDID}}
($OLDID = oldid of the last visited version, delivered by Enotif)

Once a mail is sent out, there is no chance to signal further changes between "old_id" and corresponding page eg. due to a delete/
undelete cycle. Therefore, Enotif depends at least a little bit on a permanent and fixed meaning of "old_id" with respect to a page.

Created attachment 111
Enotif 1.22 Patch for today's CVS 1.4 version (25.10.2004)

The new Enotif patch pays attention to a lot of your comments.

I also reestablished the "old" user interface, i.e. when user adds a page to
the watchlist, the corresponding talk page is also watched.

Many further improvements such as

• "update (since my last visit)" marker shown on recent changes, page history

and watchlist (also for users without email address in preferences)

• number of watching users shown in recent changes, page article footers
• link to diff-to-last-visited-version sent in notification mails

attachment enotif1.22_against_CVS1.4.diff ignored as obsolete

jeluf wrote:

You can also compare oldid=1234&direction=next, e.g.
http://schema.mormo.org/index.php?title=Somewhere&direction=next&oldid=914

This will compare rev 914 with the next revision.

Created attachment 112
Enotif v1.22 against CVS 1.4 25.10.2003

attachment enotif1.22_against_CVS1.4.diff ignored as obsolete

(In reply to comment #25)

You can also compare oldid=1234&direction=next, e.g.
http://schema.mormo.org/index.php?title=Somewhere&direction=next&oldid=914

This will compare rev 914 with the next revision.

Thanks, but users who read their mail, let's say one week after the notification was sent, want to compare the current (today's)
version with the one they last visited (i.e. one week ago or later).

Perhaps I can add your link too, but then the mails will become to long.

Best will be: I can convince Brion to check my code now. It's working fine and took the new database calls into account.
The avoid confusion, many of my new features can be switched off (by variables in Default/LocalSettings.php).

I am interested in your feedback.

I've e-mailed Tom a list of things that should be addressed.

Created attachment 115
Enotif patch 1.30 against CVS 1.4 (= 1st review of Enotif v1.22)

attachment enotif1.30_against_CVS1.4.diff ignored as obsolete

Some more comments:

Please take out $wgRCUseModStyle; it's an unnecessary complication and
doesn't actually provide UseMod's basic features.

Avoid loading UserMailer.php in Setup.php. Every inclusion requires
processing time and memory, which slows down the operation of the wiki. If
you're not going to send mail on every hit, don't include it every time.

There's a weird comment:
+# while code from www/home/www/phase3/
enotif1.22_against_CVS1.4.diff.php.net

wfMsg( 'updatedletter' ) is dumped as raw HTML several times; change this to
plaintext via htmlspecialchars(). Any formatting should be done through the
stylesheet; wrap it in a <span> or something. The other messages added
should also be either plaintext or wikitext as appropriate.

This is really wrong:
+ global $wgUser, $notificationtimestamp, $numberofWatchingusers;
+ # set the global variable here. We could pass it as a parameter, but
it would be need to many code changes
+ $notificationtimestamp = $xnotificationtimestamp;
+ $numberofWatchingusers = $xnumberofWatchingusers;

Why would these be set as globals? If they must be preserved between calls,
use member variables, not globals.

+ mail( $to, $subject, $body, $headers, "-
f{$wgEmergencyContact}\n");
How does this behave if special shell characters or spaces appear in the
contact address?

+ if (($wgUser->getEmail() != '') && (1 != $wgUser-

getOption('disablemail'))) {

In general boolean checks should be done as booleans rather than looking
specifically for == or != 1.

More generally this bit totally changes the privacy rules:
+ # the user who edited is $wgUser->getName():
+ # reveal the page editor's address as REPLY-TO address only if the
user has not opted-out
+ if (($wgUser->getEmail() != '') && (1 != $wgUser-

getOption('disablemail'))) {

+ $headers =
str_replace('$PAGEEDITORNAMEANDEMAILADDR_QP', $pageeditor_qp . ' <' .
$wgUser->getEmail() . '>', $headers);
+ $body = str_replace('$PAGEEDITORNAMEANDEMAILADDR',
$wgUser->getName() . ' <' . $wgUser->getEmail() . '>', $body);
+ } else {

Currently we do not reveal anyone's e-mail address unless they explicitly
send a mail to another user through Special:Useremail; if I'm reading this
correctly this would reveal the listed e-mail address of the editor to everyone
watching the page, unless they chose to opt out of *receiving* e-mail through
Special:Useremail. That's a big privacy leak.

I'd recommend changing the functions to accept Title objects rather than title:
namespace pairs for consistency and cleanliness. Also, method names should
begin with a lowercase letter (traditional camelCase naming style) and the
contents of a class definition should be indented.

There's still a huge amount of duplicated code in UserTalkUpdate; please
merge this with Notification.

WatchedItem in a couple places runs the same query twice with a tiny
difference. Refactor this to another method so that the two queries don't have
to be updated identically every time something changes.

+'updatedletter' => '<font size=-2 style="background:
#00FF00">&nbsp;updated (since my last visit)&nbsp;</font>',
This is still not valid XHTML. Make it plaintext (use htmlspecialchars on the
output) and surround it with a <span class="update"> or something, so the
CSS stylesheet can specify formatting.

+'email_notification_infotext' => '
This one contains a huge amount of HTML mixed in, which is not valid XHTML
either. Please try to extract the _text_ from the HTML form; maintaining form
changes across copies in dozens of localizations is a huge maintenance
burden.

+'email_notification_headers' => 'MIME-Version: 1.0
Again this should not be in the localization system, as it's special text. The
line ending format of the person downloading the files may also affect how
and whether the headers work. Headers broken accidentally or maliciously
through the wiki could cause failure to deliver, or incorrect delivery.

In general you might also want to look over some of the options which
require an additional query eg on every line of RC output to see if they can be
consolidated, if that might help performance.

RELEASE NOTES FOR THE NEW ENOTIF PATCH 1.33 FOR MEDIAWIKI 1.3.7 (URL for complete tgz follows)

ATTENTION:

the DIFF file and the TGZ file will be published/uploaded later, because I first serve some test users, who already uses my older
version.

DISCLAIMER:

I tried to address as MANY of Brion's and JeLuf's ultra-valuable comments as possible, especially the security related and
"hard"cosmetic ones. The rest of their comments will be addressed in further releases - as soon as possible. Overall it was a VERY
hard work for me, but the released patch - coming with my PERSONALLY SUGGESTED DEFAULT OPTIONS - is worth to have look into it.

If you decompress the tgz file - its URL will follow soon - it will decompress the whole MediaWiki 1.3.7 code INCLUDING the Enotif
1.33 patch and my PERSONALLY SUGGESTED DEFAULTS to a subdirectory /testwiki . Then you can perform either a fresh installation with
a fresh database or a fresh installation with an existing database. If you prefer to copy the files manually, you need to issue a
PHP /maintenance/update.php command to adapt the database structure (for watchlist table only).

Users of my older Enotif patches can use their databases without any changes (there is NO further database layout change necessary).

For feedback: I prefer to communicate via mail, mailto:mail@tgries.de .

I hope, that my contribution is seen friendly and that it is kindly appreciated by you. However, there might be cases that you do
not like my patch. Please be then courageous and tell me why, because I will definitely try to improve it for a manifold of
applications. especially for medium-sized companies and family wikis. On the other hand, I already know of several users and
companies which finds the pre-released versions an epoch-making improvement.

Hope, you like it, too.

Tom Gries
Berlin

THESE IS THE RELEASE NOTE AS INCLUDED IN FILE mw137+en133.tgz (URL follows separately)

Version 1.3.7+enotif v1.33, 2004-10-29

• Enotif v1.33 written by Tom Gries, Berlin and Markus Arndt, Munich

• Executive summary for the impatient reader: Enotif adds e-mail notification to MediaWiki version stable release 1.3.7 It sends e-mails when a watch-listed page or user_talk page is changed to the watching users. Listed as "enhancement" http://bugzilla.wikipedia.org/show_bug.cgi?id=454 Visit the complete documentation on http://meta.wikipedia.org/Enotif

• Details: Implements almost all enotif options as user preferences. These are only shown on the user preference page, if they are globally enabled by the corresponding admin option in DefaultSettings.php. Added admin feature to let enotifs appear to come from the page editor. This facilitates automatic mail sorting and anti-spam filtering; feature was originally proposed by Nick Triantos, thank you ! Page editor's email address is however only shown, if this user enabled the option "reveal my email address" in user preferences. Otherwise, the enotifs appear to come from WikiAdmin as usual (tricky to program, but simply trust the algorithm. or look into UserMailer.php and UserTalkPage.php).

• Changes from previous enotif versions

• v1.31 is an improved version with many security and also cosmetic changes applied after two first reviews by Brion Vibber. v1.31 is basically the same as the older Enotif v1.30 and v1.22 versions. Added UseMod style for recent changes view so that only the most recent change of any page is listed. The (diff) and (hist) still allow to retrieve the older versions at users' discretion, but the RC view is much cleaner for trusted environments such as medium-size companies or family wikis.

• v1.22 "updated (since my last visit)" also shown for users without stored email address in preferences, so that they can see, what watched pages have changed.
• show "updated (since my last visit)" markers in RC, history and watchlist
• Systemvariables to suppress updated marker in all views
• show number of watching users in RC and on bottom of articles in classic skin and in monobook skin
• Systemvariables in DefaultSettings.php to enable or disable features
• v1.21 now suppresses displaying the marker "updated (since my last visit)" in recent changes view for the older (already visited) versions of watched pages - i.e. page versions before the enotif was sent do not bear that marker any longer.
• enotif mails come with a link to the diff view between current and last visited version of the watching user; feature was proposed by Chris Phoenix, thank you !

*database structure is changed automatically when installing via the
recommended way (starting index.php and re-using the old database name).
run php /maintenance/update.php
OR see /maintenance/archives/patch-email-notification.sql and apply the
command
ALTER TABLE watchlist
ADD (wl_notificationtimestamp varchar(14) binary NOT NULL default '0');
manually to your database, which does not harm the non notification versions

*adding a page x to the watchlist does automatically add a watch

for the accompanying talk_page talk:x and vice versa;

Because the patch performed well the last days (no glitches or whatsoever), I
hereby publish the download URL for

***MediaWiki 1.3.7 (FULL VERSION) including my patch Enotif 1.33***
http://www.tgries.de/mw/enotif/mw137+en133.tgz
This will decompress to a subdirectory testwiki/ unless you use the tar - C

option

PLEASE READ CAREFULLY the documentation. There are two possibilities: one to
study the text of the files RELEASE-NOTES, second to read the verbose
http://meta.wikipedia.org/Email_notification_installation page. Both versions
explain how to install "from scratch" or how to "upgrade with using an existing
database" (which is then automatically adjusted to work with Enotif by adding
the field wl_notificationtimestamp to the table watchlist. For users who already
have used one of the older Enotif versions: there are no further database layout
changes.

PLEASE BE ALSO REMINDED, that the above *.tgz comes with some slightly different
MediaWiki default settings, inter alia is "remember password across session" now
checked by default. The enotif email options (see DefaultSettings.php and user
preferences) are generously enabled; the debug options for beeps on the server
beeper when enotif mails are actually sent are *disabled*.

The patch comes with (in my view) useful extras, which are also generously
enabled to give an impression, what powerful extensions it brings to this
project. For example, there is this long-awaited "updated" marker, which
indicates these revisions of your watched pages which you haven't seen since
your last visit.

Anyone, who do not like one or more of my defaults can easily set up other
default options, as they are verbosely commented anywhere and on the users'
preference pages. My intention was to show the powerful possibilities.

AGAIN:
This mw137+en133 is my personal view of the story. Some readers will certainly
have objections against this-and-that, which I fully respect. Some cosmetic
problems (only inside the code) are outstanding matter and will be solved as
soon as possible. All your valuable other advices regarding potential security
problems have been picked up and appear to be solved. In case you have comments,
please let me known them as soon as possible.

Many thanks to
Chris Phoenix in Florida for the (diff-to-last-visited-revision) link idea in
enotif mails,
Nick Triantos in California,
David in Germany for pointing to a php-mail() inconsistency,
Hans-Jürgen for "CVS briefing",
Emmanuel from Alsace/France,
Ashar in Nantes/France
and of course Brion Vibber in ?
and JeLuf in Germany for chatting, suggestions and comments.
and last, but not least, my friend-colleague and co-author Markus Arndt for the
first implementations.

Tom

Created attachment 120
Enotif 1.33 for MediaWiki 1.3.7 (diff -r -u -b)

attachment mw137_against_mw137+en133.diff ignored as obsolete

Created attachment 121
Enotif 1.33 for MediaWiki 1.3.7 (diff -r -u -b) (same program; changed a few default options)

attachment mw137_against_mw137+en133.diff ignored as obsolete

Created attachment 122
Enotif 1.33 for MediaWiki 1.3.7 (diff -r -u -b) (same program; changed a few default options)

attachment mw137_against_mw137+en133.diff ignored as obsolete

Comment on attachment 121
Enotif 1.33 for MediaWiki 1.3.7 (diff -r -u -b) (same program; changed a few default options)

(obsolete due to user upload abort)

Created attachment 123
Enotif 1.34 for MediaWiki 1.3.7 (diff -r -u -b) (diff file only)

A problem with $oldid is solved in this bug-fix, which prohibited the
generation of (diff-to-last-visited-version) link in enotif mails.

Download of the whole package MediaWiki 1.3.7 incl. Enotif 1.34 and diff files
http://www.tgries.de/mw/enotif/mw137+en134.tgz

attachment mw137_against_mw137+en134.diff ignored as obsolete

Reopened; this feature is not (yet) in MediaWiki, but in an in-development third-party patch which has not
(yet) been included.

Created attachment 125
Maintenance relase of Enotif 1.35 for MediaWiki 1.3.7 (diff file only)

The complete download Enotif 1.35 including the full MediaWiki 1.3.7 code can
be downloaded from http://www.tgries.de/mw/mw137+en135.tgz .

This decompresses to a subdirectory testwiki/ .

More info see documentation on http://meta.wikipedia.org/Enotif

attachment mw137_against_mw137+en135.diff ignored as obsolete

Created attachment 126
Difference between Enotif 1.34 and Enotif 1.35

attachment mw137+en134_against_mw137+en135.diff ignored as obsolete

leercontainer-bugzilla wrote:

Brion has kindly clarified why enotif is not included in the current MediWiki
release in the following e-mail to the mediawiki mailinglist:

http://mail.wikipedia.org/pipermail/mediawiki-l/2004-November/002082.html

I hope for everybodies (and espescially, tom and brions) patience in getting the
necessary work done.

I am sending this only as a "staying-alive" message and also to pre-announce a
new version Enotif v2.00 for CVS HEAD, overcoming all objections. Those of you,
who are interested in a preview of the code, can contact me personally.

Scheduled date of the patch: 30.11.2004

Created attachment 168
Maintenance release of enotif 1.351 (patch for enotif 1.35 for mediawiki 1.3.7)

The updated full tgz file can be downloaded from
http://www.tgries.de/mw/mw137+en135.tgz (I did not change the filename).

attachment enotif135_against_enotif1351.diff ignored as obsolete

EN = Email Notification (Enotif)
EA = Email Authentication
ENEA = EN+EA

The first alpha release of Enotif AND Eauthent 2.00/CVS for CVS HEAD (1.5) is ready and can be obtained from my server on request.
Code review, diff files and complete URL will be published soon after I have received some feedback from my testusers.

If you want to test it too, now, please let me now by mailto:mail@tgries.de , then I'll pass you the URL.

Tom aka Wikinaut

Created attachment 171
EN+EA 2.00/CVS against CVS 1.5 as of today (manually applied patch)

Here it comes -- please be polite with me -- the long promised (first) release
of email authentication and notification for page changes in the version for
CVS HEAD i.e. 1.5 of today.

The full program can be downloaded from
http://www.tgries.de/mw/cvs15+enea200-minus-cvs.tgz for a fresh installation or
update installation. Everything shall work as you expect.

If not, please let me know as soon as possible.

Use at your own risk; however, it is very very nice, you will see.
Try it, before telling me, that you don't like it from the beginning.

Every single feature can be fully disabled; many switches have corresponding
option on the user preference page, so that each user can determine if he wants
to have this and that.

Tom

attachment phase3-phase3enea.diff ignored as obsolete

I uploaded a freshly updated (from CVS HEAD 16.12.2004 1900 UTC) version to my
server

EN+EA 2.00/CVS against CVS 1.5

The full program can be downloaded from
http://www.tgries.de/mw/cvs15+enea200-minus-cvs.tgz (2,9 MB) for a fresh
installation or update installation. Everything shall work as you expect.

Use at your own risk.

Every single feature can be fully disabled; many switches have corresponding
option on the user preference page, so that each user can determine if he wants
to have this and that.

Tom

Brion: I hope, that I can upload it soon (tonight?) into the CVS HEAD; how do
you think about this step now ?

(I forgot:) There ware no code changes in ENotif or EAuthent.

Merged in CVS HEAD.

dieter.menne wrote:

E-mail notification failed for me with
$wgEmergencyContact = 'dieter.menne@menne-biomed.de';
No error, but mail never arrived.

Works ok without the wgEmergencyContact. I thought it had to do with safe mode
and tried

if( ini_get('safe_mode') )

mail( wfQuotedPrintable_name_and_emailaddr($to), $subject, $body, $headers);

else

mail( wfQuotedPrintable_name_and_emailaddr($to), $subject, $body, $headers,

"-f{$wgEmergencyContact}\n");

but this does not work too. phpVersion is 4.10

Pre-Announcement (to avoid double efforts, if you are interested):

An intermediate release of ENotif for MediaWiki version 1.3.10 is scheduled for
publication on 09. Feb. 2005. It can be installed with a new or using an
existing wiki database, as it comes with a database upgrader module as usual.

Tom

(In reply to comment #51)

Pre-Announcement (to avoid double efforts, if you are interested):

An intermediate release of ENotif for MediaWiki version 1.3.10 is scheduled for
publication on 09. Feb. 2005.

I forget to say w.r.t. to MediaWiki 1.5:

A different version of ENotif is available for mediawiki testers and developers
in CVS HEAD since 18.12.2004 for version 1.5, this version not intended for
production environments.

Created attachment 281
ENotif 2.01alpha including and for MediaWiki 1.3.10

Downloadsite http://www.wikinaut.de/mw/mw1310+en201alpha.tgz
Please take note that the tgz decompresses to a subdirectory testwiki/ .

Some further necessary remarks.

First at all: use at your own risk. I did my very best to make it robust and
safe, it is a fresh port onto the mediawiki 1.3.10 stable release code and
almost every contribution and remark by Tim, JeLuF, Brion, Hashar has been duly
considered. It looks fine, but one can never know.

Next advice: make a database backup (you always should do this), however, I
never encountered a single problem.

You can safely make new installations (with a "fresh" database) or use an
existing database, because a database updating step for table watchlist is
performed if you never used ENotif before.

My version comes with a few personal settings (default user preferences for
newly created accounts) which differ slighty from standard mediawiki 1.3.10
release versions. Try them please, you can later disable everything.

The version has also again support for a third option for what Recent Changes
view, I call it "RecentChanges in UseModStyle" see
http://bugzilla.wikipedia.org/show_bug.cgi?id=782 , which can be disabled by
Sysop and in user preferences. It also shows the number of watching users in
the RC view.

The latter features can be easily disabled in both
DefaultSettings/LocalSettings.php and in every user's preferences page.

Accompanying documentation as usual on http://meta.wikimedia.org/Enotif .

Tom

attachment mw1310_to_mw1310+en201alpha.diff ignored as obsolete

Created attachment 312
ENotif 2.02 for Mediawiki 1.3.11

Release of ENotif 2.02 for Mediawiki 1.3.11 . Full code mediawiki 1.3.11 incl.
ENotif 2.02 can be downloaded from my server as
http://www.tgries.de/mw/mw1311+en202.tgz .

It installs into a subdirectory /testwiki .

Pls. read previous comment for details of installation. Accompanying
documentation on http://meta.wikimedia.org/wiki/Enotif - as usual.

Hotline: mailto:mail@wikinaut.de (mention your phone number, if you wish. I'll
call you back.)

Tom

attachment mw1311_mw1311en202.diff ignored as obsolete

Dear all:

ENotif and EAuthent for REL1_4 will be published tomorrow; it's ready and stable.
Allow one more day for testing.

Tom

Created attachment 417
Patch against Mediawiki REL1_4 of 13.04.2005

FULL ALPHA RELEASE 13.04.2005
Download http://www.tgries.de/mw/mw141+en305alpha.tgz

• Make backups. Always.

• Attention: tar -xzf mw141+en305aplha.tgz installs into /testwiki
• comes with my preferred settings
• You will like it. Direct links to the last seen version (of watched pages

only). User-Talk AND User-Pages are notified by the "You have new messages"
marker. Many dozens of other features. See RELEASE-NOTES inside the patch; see
Metawiki page http://meta.wikipedia.org/wiki/Enotif (not updated at the moment)

Tom (Wikinaut)

attachment mw141_against_mw141enea.diff ignored as obsolete

Created attachment 422
ENotif and EAuthent MediaWiki 1.4.1 a small bugfix (for lvrd -- diff-view of last-seen revision -- if there is only the initial version, no difference is shown, but the initial version itself)

To say it again: I invite all of you to install my patch. I invested roughly
300 hours into ENotif and EAuthent, and integrated many other feature requests,
such as "show a link (or better, a link to the difference view) to the last
version I saw".

Every database /where applicable/ is wrapped; ENotif and EAuthent already uses
the NEW DATABASE type for timestamps which is DATETIME (for MySQL).

So say what ?
Try it, taste it, and let me know, whether/that you like it.

Pushy as always --
Wikinaut Tom

Attention Magnus, JeLuf, Ashar, Brion, Tim:
I kindly but pushy ask Magnus or JeLuf or Ashar or Brion or Tim to install it
on http://test.wikipedia.org.

The current patch is a diff against the CVS REL1_4 (=1.4.1) from Sourceforge as
of 14-APR-2005, 20:40 UTC; the whole code is available on my site
http://www.wikinaut.de/mw/mw141+en305alpha.tgz ( and installs into /testwiki if
you do not change this).

Everything is like in the original release, so you have to "chmod a+w config"
and to move /config/LocalSettings.php one level up.

attachment mw141_against_mw141enea.diff ignored as obsolete

Created attachment 425
diff between current REL1_4 and current ENotif (version number 3.07)

Full download of MediaWiki-Plus: http://www.wikinaut.de/mw/mw141+enea.tgz (~
3MByte)

Sent feedback, please mailto:mail@wikinaut.de

Small bugfix compared to previous version: when a page is moved, the correct
watchlist settings are now taken into consideration, i.e. when a user is
watching the subject and the talk page X and that page X is moved to page Y,
all four pages are watched correctly.

MediaWiki-Plus = MediaWiki REL1_4 incl. E-mail notification incl. E-mail
address authentication, fully customizable according to your needs.

Under GNU/GPL license.

attachment mw141_against_mw141enea.diff ignored as obsolete

In reply to comment #58)
Created an attachment (id=425) [edit]
diff between current REL1_4 and current ENotif (version number 3.07)

The full version of MediaWiki-Plus is here:
http://www.wikinaut.de/mw/mw141+enea.tgz (~ 3MByte)
This is NOT a spawn of MediaWiki; it's an enhanced version and open for peer
code review.

Sent feedback, please mailto:mail@wikinaut.de or post in this bugzilla, please.

Small bugfix compared to previous version: when a page is moved, the correct
watchlist settings are now taken into consideration, i.e. when a user is
watching the subject and the talk page X and that page X is moved to page Y,
all four pages are watched correctly.

MediaWiki-Plus = MediaWiki REL1_4 incl. E-mail notification incl. E-mail
address authentication, fully customizable according to your needs.

Under GNU/GPL license.

I can only add this:

• recommended to try this version and
• to set it up as http://test.wikipedia.org

Created attachment 429
MediaWiki 1.4.1 plus Enotif v3.08. Added the new feature e-mail notification for _new_ pages (user and sysop option)

attachment mw141_against_mw141enea.diff ignored as obsolete

MediaWiki 1.4.1 plus Enotif v3.08.

I added a long-felt want:

new feature: e-mail notification for _new_ pages

The "patch" includes user and sysop options and update.php; it is based on
today's update from REL1_4 = 1.4.1

a) sysops can disable or enable the new option "Send me an e-mail when a new
page is created" to be shown for everyone or
b) only for developers, sysops, and bureaucrats

Donwload URL as usual
http://www.wikinaut.de/mw/mw141+enea.tgz (now at version 3.08)

it installs to /testwiki

Please report problems (or if you like that one) here or mail me, please.

Tom

Bugzilla title adapted to reflect the new feature.

Created attachment 430
MediaWiki-REL1_4 (pre-1.4.2) plus ENotif 3.09

Going 1.4.2. Small security fix to prevent non-authorized users to enable
newpage notification flag by form tampering in SpecialPreferences.php.

Attached:

download url adapted to new pre-version number
http://www.wikinaut.de/mw/mw142+enea.tgz

Created attachment 466
ENotif/EConfirm v3.15 for REL1_5 of today, 27.04.2005 20:25 UTC

adds optional notifcation on _new_ pages; "(last seen)" links for watched
pages; improved code went to RecentChange.php module; E-mail address
confirmation sends a link with a token to unconfirmed address; "you have new
messages on your user and/or user_talk page" (new) including "(last seen)"
links; new option for recent changes "show only current revision of pages in
Recent view".

attachment cvs.diff ignored as obsolete

Please consult documentation and screenshots on
http://meta.wikipedia.org/wiki/Enotif

Please contact me on http://test.leuksman.com/wiki/Enotif . I have "enotified"
this page, meaning: I watch it with e-mail notification switched on.

Euer/Your Wikinaut

Created attachment 468
ENotif/EConfirm v3.16 for REL1_5. some small problems fixed

minor bug fixes.

attachment cvs.diff ignored as obsolete

The full code of this patch (diff =
http://bugzilla.wikimedia.org/attachment.cgi?id=468&action=view ) is available
as http://www.wikinaut.de/mw/rel15+enec316_CVS.tgz (3,3 MB)

Attention:
(a) be aware, that it installs into the subdirectory /phase3 and save your
directory, if you need it.
(b) the tgz file comprises the CVS markers and tags, so that you easily can make
further updates from CVS upon my version

Hotpage and helpdesk for this version: http://test.leuksman.com/wiki/Enotif

(correction to comment #68, sorry)
The full code ... http://www.wikinaut.de/mw/rel15+enec316_CVS.tgz (3,3 MB)
... Hotpage and helpdesk: http://test.leuksman.com/index.php/Enotif << corrected

Created attachment 474
ENotif/EConfirm v3.17 for REL1_5. Fixed a) "address was confirmed w/o confirmation" and b) "superusers don't have to confirm their addresses: not working"

Everything including the CVS-tag files can be downloaded as
http://www.wikinaut.de/mw/rel15+enec317_CVS.tgz .

Attention again, it installs to a subdirectory /phase3

Msg for Brion only: will propose to you, that I proceed now breaking this down
into a reasonable set of (+/-4..6) smaller subject-oriented patches. Pls. let
me know, if you accept my offer.

What I have placed here, is working fine for me, and I really propose the whole
patch for REL1_5 - but nothing more :-)) ...

Attached:

Recent work is heading for REL1_5 .

Lovers of 1.3.x and 1.4.x versions can look here and or consult the
documentation pages http://meta.wikipedia.org/wiki/Enotif . [ but I stopped
describing the differences between my evolving versions, now 3.x -- I can't
afford the time for this any longer, pls. apologise. But I offer this "Helpdesk"
on http://test.leuksman.com/index.php/Enotif or wikitech-l mailinglist ]

I'm marking this bug CLOSED (it's been FIXED for ages).

If there are specific changes that should be made, please provide individual patches under the appropriate bugs. Do not post
anything additional under this bug, which is done since December.