Last modified: 2007-02-02 20:35:50 UTC
When a page is moved, the move does not register on the watchlist, and the entire page disappears until the next edit is made to the 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! From user reports, the bug appears to be a regression. There may be a related bug, but I wasn't able to find it.
duplicate to (closed) http://bugzilla.wikipedia.org/show_bug.cgi?id=3065 and http://bugzilla.wikipedia.org/show_bug.cgi?id=3465
*** This bug has been marked as a duplicate of 3465 ***
This bug was marked a duplicate a duplicate of Bug 3065, but it appears that this is a different bug, so reopening.
*** Bug 5912 has been marked as a duplicate of this bug. ***
The same problem occurs when a page's protection status is modified. As both are "null" revisions, with no change occuring on the current table, maybe the bug has something to do with that?
*** Bug 7181 has been marked as a duplicate of this bug. ***
The page disappears from the watchlist when it is moved because there is no longer a recentchanges entry where 'rc_this_oldid=page_latest' in the page table. So the where clause in the SQL statement issued by SpecialWatchlist fails. Note that if you set the 'extendwatchlist' preference, the page does appear, because this condition is not added to the where clause in that case. One possible fix (which I implemented to get around this problem) is to remove the join with the page table in the SQL statement. Keep a hash of seen page_namespace+page_title's as you're looping through the query results, and skip rows for pages you've already seen if 'extendwatchlist' is not checked. If you do this, you'll need to calculate $numRows inside the loop, so you need to move the loop up above the code that generates the bottom header. It was pretty easy change to implement, and it has a side-benefit of being more efficient in many cases because you omit a database join.
*** Bug 3067 has been marked as a duplicate of this bug. ***
*** Bug 8804 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 5546 ***
The moves not only dont show (bug 5546), but the page is actually not watched anymore. Either the watchlist table uses page ids or we add some renaming operation of watchlist columns to the move function.
(In reply to comment #11) > The moves not only dont show (bug 5546), but the page is actually not watched > anymore. > > Either the watchlist table uses page ids or we add some renaming operation of > watchlist columns to the move function. Nevermind, I was right before. This is already done. The new and old location our watched. Log items just do show.
Opps, I meant "Log items just do not show."
