Last modified: 2010-05-15 15:38:16 UTC
When you are watching a user page and the user archives his user talk page by moving it, the archive page is shown on the watchlist edit page. However, going to the page shows the page is watchlisted, but not its talk page. There were a number of these on my watchlist on en:, and I kept one of them so you can take a look at the database: [[User talk:SqueakBox/Archive 3]], which does not seem to be watchlisted (tab shows "watch"), however [[User:SqueakBox/Archive 3]], which never existed, seems to be watchlisted (tab shows "unwatch"). The page was created via a move from [[User talk:SqueakBox]].
Does this occur only on user talk pages, or also on other types of pages?
I tested it at [[User:CesarB/Sandbox]] (first creating both the page and its talk and watchlisting on the talk page, then moving the talk page to /Archive1, then moving the main page with talk to /Archive2, then moving the main page without talk to /Archive3). In the three cases, the talk page has the tab as "watch" and the main page has the tab as "unwatch", implying only the main page is being watched, but not its talk. I have not tested on other namespaces, since it involves moving and might be a bit disruptive.
You are right. With the introduction of Enotif, each page (article, talk) has its own entry. Therefore, move operations of the one or the other must duplicate the entries correctly. For the developers: Please check the code in lines 147-205 in my EnotifWiki version, which would solve the problem, if the patch would be applied to the regular MediaWiki branch. Check lines 147-205 http://cvs.sourceforge.net/viewcvs.py/enotifwiki/enotifwiki/includes/WatchedItem.php?annotate=1.1.1.1
(In reply to comment #3) > You are right. > > With the introduction of Enotif, each page (article, talk) has its own entry. > Therefore, move operations of the one or the other must duplicate the entries > correctly. > > For the developers: > Please check the code in lines 147-205 in my EnotifWiki version, which would > solve the problem, if the patch would be applied to the regular MediaWiki branch. > > Check lines 147-205 > http://cvs.sourceforge.net/viewcvs.py/enotifwiki/enotifwiki/includes/WatchedItem.php?annotate=1.1.1.1 It could be that some more small changes are also necessary, in Title.php and SpecialMovepage.php See lines 1596 ff. http://cvs.sourceforge.net/viewcvs.py/enotifwiki/enotifwiki/includes/Title.php?annotate=1.1.1.1 http://cvs.sourceforge.net/viewcvs.py/enotifwiki/enotifwiki/includes/SpecialMovepage.php?rev=1.1.1.1&view=log I need update and diff EnotifWiki with the beta4 -- please allow for one working day, then I will post a complete diff.
changed the title - it now better describes the problem
Created attachment 774 [details] patch for MediaWiki CVS tag REL1_5 of today - This patch solves the problem by copying both pages (when one or the both are moved). - Please can someone of the developers apply this to ***REL1_5*** (and later also to CVS HEAD) ? - The patch is copied from EnotifWiki, which uses this patch since a couple of months: if you want to compare with that version, please consider to visit the CVS repository http://cvs.sourceforge.net/viewcvs.py/enotifwiki/enotifwiki/includes/WatchedItem.php?rev=1.1.1.1&view=log
-- asking developers to fix this pls., a clean patch against REL1_5 is present in the bugzilla.
*** Bug 3465 has been marked as a duplicate of this bug. ***
when will the bug get fixed?
Hi BLueFiSH, this is fixed in EnotifWiki. It's up to MediaWiki developers to apply my patch http://bugzilla.wikimedia.org/attachment.cgi?id=774
(In reply to comment #9) > when will the bug get fixed? When someone writes a patch which is committed.
(In reply to comment #11) > (In reply to comment #9) > > when will the bug get fixed? > > When someone writes a patch which is committed. the patch is there since 2005-08-11
Applied a slightly less invasive patch; there's no need for an option around this behavior.
I think this bug should be reopened, because the patch hasn't been applied yet (the behavior described in the dupes still exists as of now). Close it when the patch is done.
Since the fix *was* applied months ago, I'll need an exact set of steps to reproduce the bug.
Found on Bug 4898, which was marked duplicate of a bug that was marked a duplicate of this.
Copied from that page: Steps to reproduce: 1. Make a new page (in your user namespace) and add to watchlist (as well as make a few edits) 2. View watchlist, and see how it shows up (near the top) 3. Move the page 4. View watchlist Expected results: We see the page move in our watchlist. Actual results: The page disappears from the watchlist! It might be a different bug, for all I know.
That would be a different bug, if any. 1. Created "3065_testX" 2. Watched the page. Watchlist table contained at this point: | wl_user | wl_namespace | wl_title | wl_notificationtimestamp | | 1 | 0 | 3065_testX | NULL | | 1 | 1 | 3065_testX | NULL | 3. Renamed to "3065_testX2" Watchlist table contained at this point: | wl_user | wl_namespace | wl_title | wl_notificationtimestamp | | 1 | 0 | 3065_testX | NULL | | 1 | 0 | 3065_testX2 | NULL | | 1 | 1 | 3065_testX | NULL | | 1 | 1 | 3065_testX2 | NULL | So, both article and talk entries are present and accounted for.
(In reply to comment #18) > That would be a different bug, if any. May my opinion count and help: Yes, Brion, you are right. I never discovered problems (in Enotif, which has back-ported _your_ patch [1] into WatchedItem.php a few months ago -but this is currently not in my EnotifWiki CVS- ) [1] r1=1.17.8.1&r2=1.17.8.2&only_with_tag=REL1_5">http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/WatchedItem.php?r1=1.17.8.1&r2=1.17.8.2&only_with_tag=REL1_5
Okay, I'm reopening the bug Tom Gries marked a duplicate.
