Manual talk:Recentchanges table

Removing selected changes from database

Will there be side effects if I remove select changes from the table in the database (using phpMyAdmin). I find myself removing garbage edits and subsequent blocks from the list, but worry about any possible issues this may bring. --Nathanael Bar-Aur L. 22:15, 16 November 2008 (UTC)

Yes, can cause problems. If it will, depends on what you do and how carefully you do it (what knowledge you have about the MediaWiki internals).

When you speak about removing stuff from the recentchanges table, this will only stop the removed rows from showing up in the recent changes pages, related changes pages, watchlists and so on. You can run the maintenance script rebuildrecentchanges.php to recreate the contents of this table; including(!) the stuff you deleted.

The table where you can remove log information without them coming back is the logging table: Remove rows from there and the messages will be gone. If you then rebuild the recentchanges table, the removed entries will really be gone.

However, if you really want to remove edits, then you will have to remove the according revisions (which can be done with the maintenance script deleteRevision.php like so: php deleteRevision.php <revision numbers>. Afterwards you can delete the according revisions from the archive table and then you can run php purgeOldText.php --purge to actually remove the associated texts. Note that after removing edits in that way you will have to manually fix the rev_parent_id field for the directly following revisions; otherwise some functions will work incorrectly, e.g. will the size differences, which are displayed in the page histories, no longer show the correct values. --88.130.83.1 02:10, 28 February 2014 (UTC)

Mediawiki 1.15.1

As I understand it, because $wgRCMaxAge defaults to 7 days in mediawiki 1.15.1, the links "14" and "30" days are useless in this special page. Might make sense to adjust the default back to what it was (13 weeks); remove these links; or find some midway solution (e.g. setting it to 30 days, not 13 weeks). -Pinkgothic 12:44, 30 November 2009 (UTC)

According to this edit, it never was 13 weeks, but is now. So you can disregard the comment above, since mediawiki 1.16.0 handles it correctly. -Pinkgothic 12:47, 30 November 2009 (UTC)

Suppress certain sections

By adding the following to Mediawiki:Common.css a person can suppress certain sections (fields) on a particular page which lists the recent changes by using {{special:recentchanges/5}}:

body.page-PAGE_NAME .mw-plusminus-pos  {display:none} /* removes plus minus of each edit */
body.page-PAGE_NAME  .mw-rollback-link  {display:none} /*removes rollback link */
body.page-PAGE_NAME .mw-plusminus-null  {display:none} /*removes null edit */
body.page-PAGE_NAME  .mw-usertoollinks {display:none} /* removes (Talk | contribs | block) */

Replace PAGE_NAME with the name of the page. Adamtheclown 19:29, 19 January 2011 (UTC)

Reason for the table

Why do we have a separate recentchanges table rather than having a boolean rev_recent field on the revision table? Leucosticte (talk) 22:01, 4 July 2014 (UTC)

It has to do with the size of the table: Revision holds a row for basically every single edit (excluded those ancient edits, where the table has not yet been in existence). This number of rows can become more or less indefinitely large. The recentchanges table however by default only holds around 1000 rows. The performance gain, which you get when querying this small over the giant table, also when you take into account the overhead, which adding a line here means, still makes it worth having this table around. --87.123.60.3 15:23, 18 February 2016 (UTC)

Revision Revision Entry

From the manual:

"as said, import of a page revision not only adds an entry to the revision table with the import date, but also one with the original date"

Is there any way to not have that additional entry? I'm trying to add a category to a large number of pages, and I'd prefer to have their histories stay closer to their last significant change date. I was doing that by adding a few msecs to the timestamp, and of course I ended up with the new date and the import date. --Salquint (talk) 15:02, 18 December 2014 (UTC)