Extension talk:CategoryWatch/Archive

That would be a very useful tool for those who work in Wikipedias along a field. It is not easy to keep in touch with new articles. So keep up the work, I hope to see that tool in action soon! Regards, Denis Barthel 19:43, 5 September 2008 (UTC)

Notification message in 1.15.1
Hey folks. I seem to have CategoryWatch working nicely in 1.15.1. However, the message sent to a user watching the category contains only the standard notification for article watching (ie. whatever is in 'MediaWiki:Enotif body'). Could someone drop a hint regarding what needs to change to get category move-in/out details sent? Is there something in Enotif_body that needs to be there to trigger it? - Lucas Billett 17:00, 9 December 2009 (UTC)
 * My bad. I had removed the $NEWPAGE element from enotif, which is what the extension strtr's on. - Lucas Billett 19:56, 9 December 2009 (UTC)

MW 1.14?
Doesn't seem to work in MW 1.14?

Also would it be possible to have a $wgCategoryWatchNotifyOnlyAdditions? So the user is only notified about new pages being added to the category not Page edits, moves or deletions etc.? Maybe a prefs setting is better: "[_] When I watch a category page only notify me about new additons." --Subfader 22:32, 15 March 2009 (UTC)
 * yeah good idea, we're using this extension a lot and I've been getting a bit annoyed with notifications of articles moving out of my watched categories since this never requires any action from me. It doesn't currently notify users when articles in the category are edited though. I'll check out the 1.14 problem asap as we've just upgraded our main wiki to 1.14. --Nad 10:07, 16 March 2009 (UTC)
 * It works. I got emails for 2 articles being added to the category. The mails were not very helpful (plain text, nothing linked). --Subfader 13:42, 16 March 2009 (UTC)

How to use extension
Just a question I am hoping you can answer (probably a stupid question)... but...

I know how to add a page to my watchlist. But with this extension properly installed, how does it know to email me if any page is created that has the same category name as the page that I put on my watch list. Is there somewhere that I specify that ALL pages which are labelled as CategoryX, for instance, and have been changed or added that I get an email.... or is just putting 1 page with that category on my watch list automatically put that category on my watch list. Thanks

Salutation Wrong
I noticed that the source code was modified on Apr 24 09:48:21 2009 [49810] to add $WATCHINGUSERNAME in the emailed message.

$WATCHINGUSERNAME was assigned $name. Should it be assigned $watchingUser->getName. $name is the person who edited the page not the person who is watching the page.

I also modified my version of the code so that an email is not sent if the editor and watcher are the same person. This mimics how the normal watch works.

Wolcott 16:26, 27 May 2009 (UTC)

Watching changes to all pages in a category
Does anybody know if it is possible to be notified of all changes to pages in a particular category.

Current implementation tells you when pages are added/moved, but I would be interested in an extension that lets you know when any page in a category is updated, to easily keep up with all pages in a category. Could this functionality be added? or are there other extensions covering this?

--Carter040 12:53, 14 September 2009 (UTC)


 * Update: Have looked at the code and made a modification so the above mentioned is realized. However I would like to know how to get permission or agreement on incorporating this here in the repository. The behaviour is currently implemented so it can be controlled by a global variable..

--Carter040 12:17, 15 September 2009 (UTC)

I have also made this modification (changed the rest of the behavior a bit for our purposes, so it's not just a clean update) but in addition, added notification for everything that happens in subcategories of the category. The code snippets below should be relatively easy to implement for users familiar with php. It has a deadswitch for infinite categories, not particularly elegant.

and in function onArticleSaveComplete

and of course you need $messages['en'] = array( 'categorywatch-catchange' => 'changed $1'

--Cm 11:55, 29 October 2009 (UTC)

Subject, No Subject..
This extension is fantastic and useful. I use the extension for our events mailing list, so that our mailing list has got an user (admin user) with watchlist the category:event. I used this extension since mediawiki 1.13; now I'm using mediawiki 1.15.1 release. It is writing very well so I'm added some custom msgs into CategoryWatch.i18n.php and I'm changed two lines with others into CategoryWatch.php:

$subject = wfMsg( 'categorywatch-emailsubject', $page ); $body   = wfMsgForContent( 'enotif_body' );

changed with:

0. $array  = array (""); 1. $event  = preg_split("/\|/",$summary); 2. $summary = str_replace("|others=", " and ", $summary); 3. $summary = str_replace("|", "", $summary); 4. $summary = str_replace($array, "", $summary); 5. $event_s = str_replace("title=", "", $event[1]); 6. $summary = str_replace($event_s, "", $summary); 7. if (!$event_s) $event_s = "New event"; 8. $subject = wfMsg( 'categorywatch-emailsubject', $event_s ); 9. $body   = wfMsg( 'categorywatch-enotif_body' );

Results are:
 * when we create new event (new page into category:event), we receive email with subject "New event" and string $event_s is removed from $summary
 * only one admin has got category:event into watchlist, and this admin receive email with subject $event_s and string $event_s is removed from $summary
 * if I modify line 8 with $subject = wfMsg( "categorywatch-emailsubject", $page );, we receive always email with subject $page and string $event_s is removed from $summary

Why is $event_s not empty until line 6 and after is it empty? Can you help me about it? -- Bilardi 08:55, 21 October 2009 (UTC)

Using CategoryWatch
Please explain this part. Thanks. Bennylin 10:42, 6 April 2010 (UTC)

Error with MediaWiki 1.15.3
Tried the current development trunk and got this error: Detected bug in an extension! Hook CategoryWatch::onArticleSaveComplete failed to return a value; should return true to continue hook processing or false to abort. --217.6.32.154 15:35, 25 May 2010 (UTC) Artur

I see the same error on a 1.5.1 wiki (and PHP 5.3.2). It occurs when saving a page that places it into a watched category. Alexkozak 03:54, 15 July 2010 (UTC)
 * Check in your Special:Version page that you have the most recent version of CategoryWatch, version 1.1.1, as the current code returns true in that hook function --118.90.5.202 04:43, 15 July 2010 (UTC)
 * I am at Version r48218 because I checked it out of subversion. Should I not do that? Alexkozak 04:38, 21 July 2010 (UTC)
 * Ok I can confirm this error is still present on 1.2.0 Alexkozak 00:48, 22 July 2010 (UTC)
 * I've done some digging through the code, and I can get some functionality if I change line 89 to:   However, the changes don't get added to the watchlist, and the only thing that appears to work is an email when something is added to the category. Alexkozak 01:16, 22 July 2010 (UTC)

Error in 1.15.1 as well
Software Configuration:

MediaWiki 	1.15.1 PHP 	       5.3.2-1ubuntu4.2 (apache2handler) MySQL 	       5.1.41-3ubuntu12.3

When saving a page I get the following errors :-(

Detected bug in an extension! Hook CategoryWatch::onArticleSaveComplete failed to return a value; should return true to continue hook processing or false to abort. Backtrace: -- MMX 10:57, 23 July 2010 (UTC)
 * 1) 0 /data/prod/webapps/mediawiki-1.15.1/includes/Article.php(1779): wfRunHooks('ArticleSaveComp...', Array)
 * 2) 1 /data/prod/webapps/mediawiki-1.15.1/includes/Article.php(1472): Article->doEdit('Artikel ist ALT...', '', 114)
 * 3) 2 /data/prod/webapps/mediawiki-1.15.1/includes/EditPage.php(1027): Article->updateArticle('Artikel ist ALT...', , false, true, true, )
 * 4) 3 /data/prod/webapps/mediawiki-1.15.1/includes/EditPage.php(2483): EditPage->internalAttemptSave(false, true)
 * 5) 4 /data/prod/webapps/mediawiki-1.15.1/includes/EditPage.php(449): EditPage->attemptSave
 * 6) 5 /data/prod/webapps/mediawiki-1.15.1/includes/EditPage.php(340): EditPage->edit
 * 7) 6 /data/prod/webapps/mediawiki-1.15.1/includes/Wiki.php(510): EditPage->submit
 * 8) 7 /data/prod/webapps/mediawiki-1.15.1/includes/Wiki.php(63): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
 * 9) 8 /data/prod/webapps/mediawiki-1.15.1/index.php(116): MediaWiki->initialize(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
 * 10) 9 {main}

Configuration example for $wgCategoryWatchUseAutoCat
Hi

Sorry, but I don't understand usage of $wgCategoryWatchUseAutoCat.

Is there a example somewhere which describes this more detailed?

If I'd like my users to automatically get notified about changes of pages in category:Projects and pages in category:Foundations, what do I have to configure for this?

Thanks for any advice

Daniel Steiner 18:15, 22 June 2010 (UTC)
 * If you set that global to true, then it means that all users are automatically watching the category named "Automatically watched by USERNAME", e.g. if you were logged in to the wiki as User:Foo, then you would automatically be notified of any changes to articles in Category:Automatically watched by Foo. The format of the category name is defined in the system message categorywatch-autocat. --118.90.5.202 04:53, 15 July 2010 (UTC)


 * I think that if you added all the pages you want to watch (all pages in Projects and Foundations categories) it would consider the named user as watching that page, and enable enotif and the like. So really, it's the same as watching a page, however now you can invoke it with a template! So instead of added each page to a category, add a template to those pages that adds it to the category you want AND the 'Automatically watched by user' category.


 * At least, thats how I interpret the instructions. I've tried my damnedest to get it to work in 1.16, but with little success. It would be an awesome feature - Lbillett 19:42, 6 April 2011 (UTC)

Latest version (for MW 1.15)?
When I download the latest version for MW 1.15, I get version 1.0.0, 2009-03-22. This is strange because the article page shows the latest version as 1.2.0 (2010-07-15). When I attempt to get the development version, I get an SVN error.

So I have two questions: --Robinson Weijman 08:43, 22 July 2010 (UTC)
 * 1) How can I get the latest version (1.2.0)?
 * 2) Does this version include all the fixes in, above? I've got Carter040's changes locally, but have they been included into the final version?

Hello,

I can confirm the download problem. When I download the extension through the ExtensionDistributor for MW 1.15.x, I get the following tar.gz file: CategoryWatch-MW1.15-r69579.tar.gz This file however includes old files: define( 'CATEGORYWATCH_VERSION', '1.0.0, 2009-03-22' );

Would be great if that dowload problem could be fixed! --80.123.158.221 09:09, 16 August 2010 (UTC)

Does not work in 1.16.0
Software: MediaWiki 	1.16.0 PHP 	       5.3.2-1ubuntu4.2 (apache2handler) MySQL 	       5.1.41-3ubuntu12.3 CategoryWatch (Version 1.1.0, 2009-04-21) User:Nad

While saving an articel, I get the following errors:

Detected bug in an extension! Hook CategoryWatch::onArticleSaveComplete failed to return a value; should return true to continue hook processing or false to abort. Backtrace:
 * 1) 0 /data/dev/webapps/mediawiki-1.16.0/includes/Article.php(2099): wfRunHooks('ArticleSaveComp...', Array)
 * 2) 1 /data/dev/webapps/mediawiki-1.16.0/includes/Article.php(1791): Article->doEdit('Ich h??tte da w...', '', 114)
 * 3) 2 /data/dev/webapps/mediawiki-1.16.0/includes/EditPage.php(1047): Article->updateArticle('Ich h??tte da w...', , false, true, true, )
 * 4) 3 /data/dev/webapps/mediawiki-1.16.0/includes/EditPage.php(2552): EditPage->internalAttemptSave(false, true)
 * 5) 4 /data/dev/webapps/mediawiki-1.16.0/includes/EditPage.php(389): EditPage->attemptSave
 * 6) 5 /data/dev/webapps/mediawiki-1.16.0/includes/EditPage.php(271): EditPage->edit
 * 7) 6 /data/dev/webapps/mediawiki-1.16.0/includes/Wiki.php(553): EditPage->submit
 * 8) 7 /data/dev/webapps/mediawiki-1.16.0/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
 * 9) 8 /data/dev/webapps/mediawiki-1.16.0/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
 * 10) 9 {main}

Now I updated the extension to version 1.2 vom 15. July, still the same :-(

Please help. thanks.

--MMX 14:29, 3 August 2010 (UTC)
 * Are you absolutely sure you've updated the extension? check the version in the Special:Version page, I can't see any way for the ArticleSaveComplete hook to not be returning a value in version 1.2. --Nad 23:28, 3 August 2010 (UTC)


 * I see the problem (I had this as well). It is due to PHP 5.3 (MediaWiki currently runs on 5.2). The solution is to change this:




 * into this:




 * HTH --Robinson Weijman 12:33, 4 August 2010 (UTC)
 * You mean not using the reference operator on some of those args? ok I've tried doing that, but I can't test the results since the problem doesn't occur for me, try the new version 1.2.1 and see if it fixes it... --Nad 08:26, 5 August 2010 (UTC)


 * Hi Nad - yes, correct about the reference operator. Did you include Carter040's changes (above) in the latest version? --Robinson Weijman 09:43, 5 August 2010 (UTC)

Hardcoded "WikiAdmin" mail sender
CategoryWatch sends out mails with the hardcoded sender name "WikiAdmin" and the mail address from $wgPasswordSender:

$adminAddress  = new MailAddress( $wgPasswordSender, 'WikiAdmin' );

Mediawiki has a new config variable $wgPasswordSenderName since today (SVN trunk r76234, see25728for details). Please use this variable instead of hardcoded "WikiAdmin" in future versions of CategoryWatch. --Cboltz 16:46, 7 November 2010 (UTC)
 * Done in 76253. Max Semenik 16:54, 7 November 2010 (UTC)

No more notification when page is removed
Hi,

I just noticed that the notification for the removal of a page from a category has been commented out/removed in recent CategoryWatch versions. http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/CategoryWatch/CategoryWatch.php?r1=49744&r2=48655 See Line 106 und 118.

Is there a special reason for that?

Thank you, Christoph


 * I noticed this too. Had to paste the 2nd loop code back in to get it to work again. Should this maybe be changed into an option of sorts? - Lucas Billett 19:15, 6 April 2011 (UTC)

Works MediaWiki 1.16.2 / CategoryWatch 1.2.1
CaliVW78 08:39, 22 March 2011 (UTC)

Link in the notification email?
Would it be possible for the notification email to contain a link to the newly added/removed page? That would come in very handy. Thank you! --Nadyro 11:52, 6 July 2011 (UTC)

Fatal Error when adding multiple categories to a page
When tagging a page with more than one category with this extension enabled, it results in the following error on MW 1.16.5:

Fatal error: Allowed memory size of [xxxxxx] bytes exhausted (tried to allocate 523800 bytes) in /htdocs/w/includes/db/LoadBalancer.php on line 443

I'm working on finding a solution, but has anyone else run across this and found a fix?

--Jlemley 17:13, 16 January 2012 (UTC)


 * Answer: The function findCategoryParents calls itself.  It looks like it attempts to prevent infinite loops with the below code, but the "return" is not ending the loop, it's just returning back to itself and moving on with the next loop:


 * I moved the latter part of this code into the while loop later in this function and changed "return" to "continue", as follows:


 * This seems to resolve the issue.
 * --Jlemley 19:29, 16 January 2012 (UTC)

message removed from I18n?!
Heiya, message "Categorywatch-emailbody" somehow vanished from the I18n file. However, a lot of other messages do not make any sense without it. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:05, 21 August 2012 (UTC)
 * I don't think that message ever existed, it's always used enotif_body which is the message used by the normal watchlist wmail notification --Nad (talk) 12:52, 12 September 2012 (UTC)

Watching Talk Pages
Have been using this extension for a while and noticed that editors are not being notified of creation, addition, or edits to talk pages for the categories they watch. Can this be added or do I perhaps have something configured incorrectly? We are using Liquid Threads, however, we tested in both LT and just editing the talk page itself. Both failed to send a notification.

--Thanks! Jaime Lemley

New User Attributed Next Edit Since 1.18.1
Some disturbing behavior in my mediawiki 1.18.1 (now 1.21.2) installation (PHP 5.2.9, Mysql 5.1.30). Closed company intranet (no link, sorry). When I disable this extension, the behavior stops. Only happens for the very next edit after user creation (thankfully). Any ideas? - Lbillett (talk) 23:44, 22 October 2013 (UTC)
 * 1) I create a new user and assign them some groups.
 * 2) Another user makes an edit on some article.
 * 3) The article edit is attributed to the new user!!!
 * Entered the observation into bugzilla here. - Lbillett (talk) 16:43, 7 November 2013 (UTC)
 * Confirmed this behavior in MW 1.23.3 today. The implications are still kind of scary. It's not a big problem in a community where new users are created rarely, but even then, edits attributed to the incorrect user can have some troublesome implications. Any ideas on how to tweak so this doesn't happen? - Lbillett (talk) 21:51, 17 November 2014 (UTC)

See below for a patch that seems to work for us (MW 1.21.1) --DavidBiesack (talk) 12:59, 16 March 2015 (UTC)

Watching user as page editor?
Why does this extension set the watching user's info into  and , instead of the editing user's info? This makes the notification email somewhat confusing because it tells the watching user that they made this edit themselves. It seems this was broken by version 1.2.2 (SVN revision 105067). &mdash;  lziobro   (talk)  19:30, 9 January 2014 (UTC)


 * I've noticed this too. Version 1.2.1 works fine in that regard. I mentioned it in some correspondence with Nad. Things all got weird for me when upgrading through MW 1.18. You could maybe stick with CW version 1.2.1. - Lbillett (talk) 20:19, 9 January 2014 (UTC)

How does the extension work
Hi,

I don't know if it's that it's not working for me but I don't see any change since I activated the extension. Can somebody tell me how to watch the categories? What difference should I see in the menus, etc?

Thanks --217.144.254.178 14:36, 26 March 2014 (UTC)


 * If you navigate to a category page (ie. Category:My Category), and add THAT page to your watch list, CategoryWatch will trigger an email notification any time a different article is ADDED to that category (have to hack it a little if you want another email on when articles are REMOVED from the category). The extension isn't really maintained. But it's one of the most important ones I use to help manage article workflow. That answer your question? - Lbillett (talk) 14:41, 26 March 2014 (UTC)


 * Oh ok, I has tried that but it's not sending the e-mails. Knowing this I'm going to check what can be wrong. You've been very helpful. Thanks! --217.144.254.178 08:44, 27 March 2014 (UTC)


 * No problem. Check and make sure your normal notification emails are sending. Also, if YOU're the person saving the article in a new category, $wgCategoryWatchNotifyEditor=true; needs to be in your localsettings.php or you won't get the email (others watching the category should). Cheers. - 12.227.189.130 12:04, 27 March 2014 (UTC)

onArticleSaveComplete hook not being called
Hi, I've been investigating why the extension is not working for me (WM 1.22) and it seems that onArticleSaveComplete is not called.

I've found that the hook is deprecated and I changed it for onPageContentSaveComplete, but no luck either.

What I did to determine that onArticleSave is working and onArticleSaveComplete is not, is to return false instead of true. When I return false in onArticleSave the saving is aborted, but when I do it in onArticleSaveComplete, the saving continues with normality. Any idea of what can be happening? --217.144.254.178 13:02, 27 March 2014 (UTC)

-- FWIW, I'm running MW 1.22.3 and the extension is functioning normally. --Gstratt (talk) 14:21, 23 June 2014 (UTC)

$PAGEINTRO not set
I have found that the email is arriving with a $PAGEINTRO text in the body, the variable is not replaced. The email body is taken from MediaWiki:Enotif_body page where it is defined. So I added an element in the $keys array definition, like this

This solved the issue-.

user conflict
We noticed on our WikiMedia installation that sometimes a change would be attributed to the wrong user. For example, I would update a page but the email sent to those watching that page, and the page history, would list another user as the user who made change.

Someone on our IT team tracked this down to CategoryWatch, which updates the $user that is passed in to

Below is the patch which we believe fixes this by using a different variable, $user_nm, so as to not affect the caller:

*** CategoryWatch.php-031215	Fri Mar 13 16:58:20 2015 --- CategoryWatch.php	Fri Mar 13 16:58:38 2015 # Insert an entry into watchlist for each while ( $row = $dbr->fetchRow( $res ) ) { ! 				$user = User::newFromId( $row[0] ); ! 				$name = $wgCategoryWatchUseAutoCatRealName ? $user->getRealName : $user->getName; $wl_title = str_replace( ' ', '_', wfMsg( 'categorywatch-autocat', $name ) ); $dbr->insert( $wtbl, array( 'wl_user' => $row[0], 'wl_namespace' => NS_CATEGORY, 'wl_title' => $wl_title ) ); } --- 72,79  			# Insert an entry into watchlist for each while ( $row = $dbr->fetchRow( $res ) ) { ! 				$user_nm = User::newFromId( $row[0] ); ! 				$name = $wgCategoryWatchUseAutoCatRealName ? $user_nm->getRealName : $user_nm->getName; $wl_title = str_replace( ' ', '_', wfMsg( 'categorywatch-autocat', $name ) ); $dbr->insert( $wtbl, array( 'wl_user' => $row[0], 'wl_namespace' => NS_CATEGORY, 'wl_title' => $wl_title ) ); }
 * 72,79 ****
 * 72,79 ****

This is based on

Perhaps this can be patched in the next release. Thanks - I find CategoryWatch to be very powerful!

--DavidBiesack (talk) 21:05, 13 March 2015 (UTC)


 * CategoryWatch functionality has become critical in my production environment for managing/notifying workflow elements. If this is the fix to the bug that popped up when MW went to 1.18 (up a few topics on this page), then YOU SIR, ARE THE BEST EVER! Always figured (hoped) it'd boil down to some small misuse of a variable or object (that eluded a php rookie like me). Can't wait to try it out. - Lbillett (talk) 00:33, 14 March 2015 (UTC)
 * I can't claim credit; my peer Craig Dawson here at SAS tracked this down and made the patch. I hope others can confirm this fix works. It happens infrequently enough that it will take time to be sure it is fixed. --DavidBiesack (talk) 12:56, 16 March 2015 (UTC)

MW 1.27
A lot of deprecated wfMsg functions have been removed from MW 1.27. In order to use this extension with MW 1.27, I have replaced the two exiting functions according to the Messages API manual. --Ralfk (talk) 12:44, 3 July 2016 (UTC)
 * Hi Ralfk can you provided some details for the technically unsophisticated? For instance a block of code showing exactly what you changed? I'm having difficulty with this extension on MW 1.28 and would appreciate the help. -- Dan.mulholland (talk) 22:22, 9 March 2017 (UTC)
 * Hi Dan.mulholland. Please find below the diff between the changed file and the original file. --Ralfk (talk) 16:30, 10 March 2017 (UTC)

Hooks in MW 1.26
Extension doesn't work in MW 1.26 as the arrays "before" and "after" are always identical. I've tried with 'PageContentSaveComplete' and 'ArticleSaveComplete'. Table 'categorylinks' seems to be updated later!? Is there any other hook to be used?

--Werthebachg (talk) 08:10, 13 July 2016 (UTC)

Namespace & Page Title not being processed
I'm running CategoryWatch 2.0 (2017-09-19 (13a2040) 16:18, 27 June 2018) on MediaWiki 1.30.0 (830bb58).

What works:
 * 1) emails and Echo Notifications are produced when a page is added to a watched category.

What is not working:
 * 1) the specifics of the page are lost in the production of the emails and notifications such that the pages are referred to as
 * 2) not quite sure what the purpose of the 127.0.0.1 IP address is - should that be the user?

CategoryWatch vs. $wgRCWatchCategoryMembership
During the time this extension was unmaintained, it was recommended to use $wgRCWatchCategoryMembership as a replacement. This is what I'm using now, together with two $wgDefaultUserOptions to enable the category change notifications by default (unless a user disables it).

I know the following question might sound like blasphemy, but I'll ask nevertheless ;-) - Is there a good reason to switch back to the CategoryWatch extension, or does $wgRCWatchCategoryMembership provide a similar feature set?

--Cboltz (talk) 19:38, 9 August 2018 (UTC)


 * There is if you're still running MW 1.23.2 like us! - Lbillett (talk) 19:41, 9 August 2018 (UTC)