Last modified: 2010-05-15 15:37:41 UTC
We almost *finished* a reasonable framework and the necessary patches for two independent kind of e-mail notifications: for (1) general page changes (all namespace) (2) User_talk:page changes Assume you are User X and you have a watchlist and a user_talk:X page. You will receive a (one) short e-mail, when someone (else than you) changes pages you watch or changes your user_talk:X page. Further notifications regarding this page are suppressed until you revisit this page. An icon indicates your watch list items, which have new, not yet visited content, and for which you already got a notification. A new general reset button on your watch list page allows you to reset all notification flags at once. Further reading, implementation details and documentation is already available on http://meta.wikimedia.org/wiki/EmailNotification and secondary pages. The expected date of the patch publication is 19. September 2004 Thomas Gries and Markus Arndt free keywords: e-mail, email, notification, watchlist, user_talk, page changes
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 [details] 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
Created attachment 53 [details] 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
Created attachment 54 [details] 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)
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.
* 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.
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.
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 [details] 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
Created attachment 79 [details] 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.
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 [details] Enotif 1.21 diff against MediaWiki 1.3.6
Created attachment 103 [details] Enotif 1.21 diff against previous version MediaWiki 1.3.5 incl. Enotif v1.2
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.
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 [details] 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
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 [details] Enotif v1.22 against CVS 1.4 25.10.2003
(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 [details] Enotif patch 1.30 against CVS 1.4 (= 1st review of Enotif v1.22)
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"> updated (since my last visit) </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 [details] Enotif 1.33 for MediaWiki 1.3.7 (diff -r -u -b)
Created attachment 121 [details] Enotif 1.33 for MediaWiki 1.3.7 (diff -r -u -b) (same program; changed a few default options)
Created attachment 122 [details] Enotif 1.33 for MediaWiki 1.3.7 (diff -r -u -b) (same program; changed a few default options)
Comment on attachment 121 [details] 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 [details] 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
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 [details] 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
Created attachment 126 [details] Difference between Enotif 1.34 and Enotif 1.35
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 [details] 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).
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 [details] 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
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.
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 [details] 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
Created attachment 312 [details] 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
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 [details] 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)
Created attachment 422 [details] 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.
Created attachment 425 [details] 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.
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 [details] MediaWiki 1.4.1 plus Enotif v3.08. Added the new feature e-mail notification for _new_ pages (user and sysop option)
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 [details] 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.
download url adapted to new pre-version number http://www.wikinaut.de/mw/mw142+enea.tgz
Created attachment 466 [details] 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".
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 [details] ENotif/EConfirm v3.16 for REL1_5. some small problems fixed minor bug fixes.
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 [details] 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 :-)) ...
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.
