Previously, a failure to open the debug log file for writing would end up getting reported as a failure of mail delivery, even though we were successful.
It'll now fail silently (as it should) and won't interfere with the actual mail() call's error reporting.
* Move up the UPDATE query on wl_notificationtimestamp up to before scheduling the EnotifyNotifyJob
* Move up the SELECT query fetching the users to be notified to before the UPDATE, and use its result for a more efficient UPDATE
* Pass actuallyNotifyOnPageChange() and the EnotifyNotifyJob an array of user IDs
* Add UserArray::newFromIDs()
As Tim notes, the weird callback setup in $wgHooks isn't really something we want to replicate or ever rely on ever again, as PHP's native callback syntax already handles things fine and is more consistent (and used extensively in the rest of MediaWiki).
May be other remaining issues with the refactor on top of bugs already discovered, but if it's going to be refactored to use callbacks it should be done using regular callbacks.
A database query syntax error has occurred.
The last attempted database query was:
"SELECT gu_id, lu_wiki, gu_salt, gu_password,gu_auth_token, gu_locked,gu_hidden,gu_registration,gu_email,gu_email_authenticated FROM `parsertest_globaluser` LEFT OUTER JOIN `parsertest_localuser` ON gu_name=lu_name AND lu_wiki='test2wiki-parsertest_' WHERE gu_name='127.0.0.1'"
from within function "Database::safeQuery".
MySQL returned error "1146: Table 'centralauth.parsertest_globaluser' doesn't exist (127.0.0.1)"
* Whitespaces fixes
* In UserMailer::send(), allow the caller to override the Content-type header so people can send multipart messages if they really want to. Using this in an extension I'm developing
address for page update notification mails.
Note that $wgEmergencyContact is now not currently in active use, but could
in theory be used for some kinds of failure notifications or to provide to
users to contact in case of failure, which I think was its original intention.
Certainly it's silly to throw an "emergency" contact on auto-sent mails!
There's also a $wgNoReplyAddress, which is currently used to add a Reply-To
header on notification mails. WTF? :)
We should probably refactor all this address crap...
The hook seems a bit odd; it triggers on some of the composes, but not all. There's another loop right after this one.
Also, there's no need to pass objects as references here.
* User->getID() already returns an integer
* Use != rather than <>, as it looks clearer
* Do not add "updated since" to users for their own edits
* Actually check $wgShowUpdatedMarker properly. It is it's own setting.
* Defer load of groups data
* Introduce newFromRow()/loadFromRow() to allow bulk loading of user objects from a result set
* Hook email and email authentication save/load to allow CentralAuth to provide a global email address
* Defer save of user data after confirmEmail() and invalidateEmail(). Caller must now also call saveSettings(). This reduces the master query count in some code paths.
Elsewhere:
* Introduce UserArray class, for bulk loading of user objects. Immediately useful in email notification, potentially useful for proposed user alias feature.
* In Special:Confirmemail, remove useless handling for impossible false return from confirmEmail()/invalidateEmail().
"Object of class MailAddress to string conversion in includes/UserMailer.php on line 112"
(It seems a bit silly of PHP to give this warning when the class has a __toString method,
but adding an explicit toString() call is easy enough)
* Bug 9213: Fixed the plainly broken user_newtalk updating and caching scheme. I tried to keep my changes roughly performance-neutral, but the update on Wikimedia should be watched carefully for performance problems.
* Made UserMailer a class, use the autoloader to load it
* General UserMailer refactoring
* If the user has email-on-newtalk enabled, send them an email for every change, not just the first one before they view the page again.
* Don't add a watchlist entry automatically on change of user talk page
