Extension talk:SpecialDeleteOldRevisions2

Does not work with Postgres (Fixed)
If the extension is used with a Postgres database as backend, the following error occurs:

A database error has occurred Query: SELECT rev_id FROM revision,page WHERE (rev_id NOT IN ( 10918, 10950, 10977, 6545, 7219, 5893, 6399, 1655, 10411, 1931, 2704, 7876, 7882, 7878, 7880, 6702, 6909, 6910, 6950, 6705 ) AND rev_timestamp <= '20100311999999') AND (rev_page = page_id AND page_title LIKE 'Z%') Function: Database::select Error: 1 ERROR: invalid input syntax for type timestamp with time zone: "20100311999999"

Obviously, '20100311999999' isn't a valid date. I assume MySQL is doing some magick behind the scenes so that it works nevertheless. Why is the '999999' appended anyway? Because just removing them seems to work fine.
 * Fixed in 1.4.1 Jehy 01:40, 23 March 2010 (UTC)

I still get a similar error select rev_id FROM revision,page WHERE (rev_id NOT IN ( 2704, 1655, 10411, 1931, 7876, 7878, 7880, 7882, 6702, 5893, 6705, 6545, 10950, 6399, 6909, 6910, 7219, 10918, 10977, 6950 ) AND rev_timestamp <= '20100413235959') AND (rev_page = page_id AND page_title  LIKE 'Z%'); ERROR: invalid input syntax for type timestamp with time zone: "20100413235959" Assing a space between the day and the hour works fine: "20100413 235959"

20:36, 14 April 2010 (GMT+2)


 * Thank you for your reply. Could you tell me more - what type of field is used for storing this timestamp in postgres? In MySQL, it is binary field and obviously I can't add this space... Possibly, there is some workaround using mediawiki functions. Jehy 00:10, 16 April 2010 (UTC)

80.65.225.88 09:18, 24 July 2010 (UTC)

Putting a space doesn't work with me (I use mediawiki 1.15.4 with PostgreSQL 8.3.7, and version 1.4.1 of this extension). This is how rev_timestamp is defined:

Column          Type                         Not Null     Default rev_timestamp   timestamp with time zone     NOT NULL Sample value: 2010-07-23 19:27:15+00

hope this helps.

80.65.225.88 09:54, 24 July 2010 (UTC)

Well. As a quick workarround, I replaced line 486: $maxDate = str_replace('-','',$this->mRequest->getText( 'wpMaxDate' )). ' 235959'; with: $maxDate = $this->mRequest->getText( 'wpMaxDate' )) . ' 23:59:59+00';

Next error is:

Query: SELECT DISTINCTROW rev_text_id FROM revision Function: Error: 1 ERROR: syntax error at or near "rev_text_id" LINE 1: SELECT /* WikiSysop */ DISTINCTROW rev_text_id FROM revisio... ^ Backtrace: ('ERROR: syntax ...', 1, 'SELECT DISTINCT...', '', false) Database->query('SELECT DISTINCT...') PurgeRedundantText(true) DeleteOldRevisionsForm->execute Object(OutputPage), Object(WebRequest)) Object(OutputPage), Object(User), Object(WebRequest))
 * 1) 0 /filer/s/k/undisclosed/w/includes/db/Database.php(616): DatabasePostgres->reportQueryError
 * 1) 1 /filer/s/k/undisclosed/w/extensions/SpecialDeleteOldRevisions2/SpecialDeleteOldRevisions2.php(103):
 * 1) 2 /filer/s/k/undisclosed/w/extensions/SpecialDeleteOldRevisions2/SpecialDeleteOldRevisions2.php(502):
 * 1) 3 /filer/s/k/undisclosed/w/extensions/SpecialDeleteOldRevisions2/SpecialDeleteOldRevisions2.php(530):
 * 1) 4 /filer/s/k/undisclosed/w/includes/SpecialPage.php(559): DeleteOldRevisionsPage->execute(NULL)
 * 2) 5 /filer/s/k/undisclosed/w/includes/Wiki.php(229): SpecialPage::executePath(Object(Title))
 * 3) 6 /filer/s/k/undisclosed/w/includes/Wiki.php(59): MediaWiki->initializeSpecialCases(Object(Title),
 * 1) 7 /filer/s/k/undisclosed/w/index.php(116): MediaWiki->initialize(Object(Title), NULL,
 * 1) 8 {main}

I guess this extension was written with MySQL in mind. Postgres doesn't support DISTINCTROW. By the way, I may be wrong, but it seems that DISTINCT is more appropriate in your script (I'm not MySQL nor PHP fluent, but it looks like you want to build a set as a filter, and DISTINCTROW may return useless duplicates).

The extension seems to work with Postgres when you change (line 103): $res = $dbw->query( "SELECT DISTINCTROW rev_text_id FROM $tbl_rev" ); with: $res = $dbw->query( "SELECT DISTINCT rev_text_id FROM $tbl_rev" ); and (line 111): $res = $dbw->query( "SELECT DISTINCTROW ar_text_id FROM $tbl_arc" ); with $res = $dbw->query( "SELECT DISTINCT ar_text_id FROM $tbl_arc" );

Table Optimization in 1.4.3 Breaks it Further (Fixed)
The added "Optimize Table" loop breaks it for any database other than MySQL, since MySQL specific commands are used. Other databased either have other methods to "optimize" tables or don't need that step at all.

Query failed: ERROR: unrecognized configuration parameter "tables" in /var/www/wiki/htdocs/mediawiki/includes/db/DatabasePostgres.php on line 580

I have commented out the optimization loop around line 369 to get it working.
 * Thanks, fixed this in 1.4.4 - now extension detects database type. Also, replaced "distinctrow" with "distinct" - it's really better, and it bugged you ealier :)Jehy 23:47, 20 September 2010 (UTC)

Keep at least five or ten revisions, regardless of date
I would like to keep at least five or ten revisions per article. Regardless of how old the next-to-lat revision was. If Mr. Schmidt would add that function I would be grateful. Otherwise, I might take a look at how 'maxdate' is handled and add a 'maxcount' for this purpose. Thanks for making this extension. --John S. Peterson 16:25, 7 February 2010 (UTC)

Thanks
Great job. Thanks! It works fine on Mediawiki 1.14.0 with MySql 5.0.67-0ubuntu6 Enzo

Deleting only archived revisions
Is there any possibility of modifying this to allow deleting only deleted revisions, that is, the "archived" revisions that can be selected in the current version of the extension?

There are some times when it is helpful to keep a history, but when one would like to delete garbage revisions (e.g., revisions made during testing) and keep the size of the database down. Currently, first, I delete the page, then restore the revisions I want to keep, then I run the following MySQL queries, but they don't seem to get everything:

To list the deleted revisions:

SELECT `tblprefix_archive`.`ar_text_id`, `tblprefix_archive`.`ar_title`,`tblprefix_text`.`old_id`,`tblprefix_text`.`old_text`, `tblprefix_revision`.`rev_id` FROM tblprefix_archive, tblprefix_text, tblprefix_revision WHERE ((`tblprefix_text`.`old_id`=`tblprefix_archive`.`ar_text_id`) AND (`tblprefix_text`.`old_id`=`tblprefix_revision`.`rev_id`)) ORDER BY `tblprefix_text`.`old_id` DESC

To delete them:

DELETE FROM tblprefix_archive, tblprefix_revision, tblprefix_text USING tblprefix_archive, tblprefix_revision, tblprefix_text WHERE WHERE ((`tblprefix_archive`.`ar_text_id` >0) AND (`tblprefix_text`.`old_id`=`tblprefix_archive`.`ar_text_id`) AND (`tblprefix_text`.`old_id`=`tblprefix_revision`.`rev_id`))

Is this a reasonable approach that gets all the old text (and all references to it) out of the database?

If you don't have time to change the extension, I'd appreciate any tips about how I could modify the extension myself (or at least fix my SQL queries), but I'm more of a "front-end" user - I don't know much about PHP or MySQL.

Thanks! --Fungiblename 19:51, 2 February 2009 (UTC)
 * There is a maintenance script available for this, see MediaWiki maintenance - removing deleted revisions. Patheticcockroach 15:05, 28 July 2009 (UTC)


 * If you still need this, I can add an option. Jehy 03:02, 1 December 2009 (UTC)

Strange error message
Hello, I get an error message, when trying to use this tool. the error message is partially in german language:

Es ist ein Datenbankfehler aufgetreten. Der Grund kann ein Timeout sein, der Ausfall eines Servers oder auch ein Programmierfehler. Die letzte Datenbankabfrage lautete:

(SQL-Abfrage versteckt)

aus der Funktion „“. MySQL meldete den Fehler „1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ', , , , , , , , , , , , , , , , , , , , , , , , , , , 139, 140, 143, 144, 145, ' at line 1 (localhost)“.

Is it possible that this extension does not work for MySQL 5 and above? Or what is wrong?

Thanks for help! -- Roy, 12:05, 22 March 2009 (GMT)
 * Extension works fine for MySQL 5, we need to take a closer look at your problem. Jehy 03:02, 1 December 2009 (UTC)

have the same problem. help? --Seb edit: it works when you UNCHECK "db integrity check" --seb edit 2: nope, doesn't, only works when you click "test" --seb

Problems downloading extension (Fixed)
It appears as though Jehy's site is gone. Is there a backup site with the code?


 * Maybe its a temp downtime. --Choshi 15:52, 13 September 2009 (UTC)


 * Yeah, sorry for this, all ok now. Thanks for providing backup link. Jehy 03:02, 1 December 2009 (UTC)

pruning revisions using a "pruning date"
Hello,

I am very interested in a single parameter for your extension, a single date to prune (delete) the revision table before that date. I will pay a bounty (give you a donation) for such a modification (stable program version needed). --Wikinaut 22:47, 22 December 2009 (UTC)
 * No problem, just contact me (see in my profile, how) Jehy 13:10, 27 December 2009 (UTC)

Compatibility issue with SemanticForms 1.8.8 (Fixed)
See: this page for details. "HTMLForm.php" is deprecated and should be removed from the bundle. Alvinos 13:26, 8 March 2010 (UTC)
 * Thank you, I changed class name so there should not be problems any more. Please update to 1.4.1 version. Jehy 01:25, 23 March 2010 (UTC)

broken in latest svn of wiki (Fixed)
Fatal error: Call to undefined function wfElement in /web/htdocs/www.www0.org/home/wiki/extensions/SpecialDeleteOldRevisions2/SpecialDeleteOldRevisions2.php on line 396 --212.54.219.23 11:17, 14 March 2010 (UTC)
 * I went ahead and fixed it: version 1.4 fixed for SVN 63760). It was only an "xml::" format needed to be added on 2 functions. --Athinker 23:37, 14 March 2010 (UTC)
 * Thank you, I just don't update my wiki :) I updated my archive, removed warning message and changed version to 1.4.1. Also I made several little bugfixes so you should update to 1.4.1 too :) Jehy 01:15, 23 March 2010 (UTC)

Cannot redeclare deleteoldrevisions (Fixed)
C:\php5>php deleteOldRevisions.php

Fatal error: Cannot redeclare deleteoldrevisions (previously declared in ...\extensions\SpecialDeleteOldRevisions2\SpecialDeleteOldRevisions2.php:147) in ...\maintenance\deleteOldRevisions.inc on line 68 --91.78.126.159 00:54, 5 April 2010 (UTC)

don't work all Namespace in MW 1.15.1
Article name: % Namespace: -100 Modus: Test only Old revisions of 1086 pages need to be checked. 0 old revisions found.

but if choose specific, than it work

Article name: % Namespace: 0 Modus: Test only Old revisions of 275 pages need to be checked. 1 old revisions found.

--91.78.126.159 01:13, 5 April 2010 (UTC)

[FIX] The latest change conflicts with HTMLForm at least here
Hi, I'm the guy that had made the change for SVN above recently.

In 1.4.1, at least in a local windows installation, HTMLForm.php isn't properly read so the wiki fails to load [with PHP Fatal error: Class 'DeleteOldRevisions_HTMLForm' not found].

However, it is fixed if also HTMLForm.php is renamed to DeleteOldRevisions_HTMLForm.php and that is also reflected in the appropriate 'require_once'. --Athinker 21:50, 6 April 2010 (UTC)

PS. What is also peculiar is that it worked if there was no rename and Class was returned to previous; Apparently there was already an HTMLForm on the system used correctly.


 * That's because you didn't overwrite HTMLForm.php with newer version at first time. In 1.4.1, file name for inclusion is "HTMLForm.php" and the class name is "DeleteOldRevisions_HTMLForm" - everything is fine with it. Jehy 16:20, 7 April 2010 (UTC)
 * That can clearly not be the case since I renamed it and included it and it worked. If I renamed it and included the same old file it wouldn't work since it would call a wrong function.

Strict Standards error (Fixed)
in

 MediaWiki 	1.15.2 PHP 	5.3.2 (apache2handler) MySQL 	5.1.45

running on

 XAMPP for Linux 1.7.4-beta2

i kept getting

 Strict Standards: Declaration of DeleteOldRevisionsPage::execute should be compatible with that of SpecialPage::executein /opt/lampp/htdocs/mediawiki/unix/extensions/SpecialDeleteOldRevisions2/SpecialDeleteOldRevisions2.php on line 512

errors, until Bryan from #mediawiki@freenode.net suggested i change line 512 in DeleteOldRevisions2.php

from

 function execute {

to

 function execute( $par = null ) {
 * Thank you, added your fix in version 1.4.3 Jehy 09:49, 14 September 2010 (UTC)

Broken in 1.16 (?) (Fixed)
Loading this in 1.16 results in a crashed wiki.

"Fatal error: Class 'DeleteOldRevisions_HTMLForm' not found in ........\extensions\SpecialDeleteOldRevisions2\SpecialDeleteOldRevisions2.php on line 371"

Have not modified the code or the LocalSettings line in any way. Bizarre, because my eyes can find the class definition just fine...

Please advise!

-- 19:58, 14 June 2010 (UTC) DoubleSuitedChris

Getting the same problem


 * Solved in version 1.4.2, by User:Ff9will

Not deleting old versions of in the File namespace
I installed this extension with a view to deleting old versions of files (Images). I ran the extension which worked perfectly in removing the revision history from pages, but looking at File pages, the old versions are still there. This means when I clean out the images/archive directory I will have pages linking to non-existant files.

Has anyone else had this issue? --67.247.57.151 14:35, 25 July 2010 (UTC)

Extension name in Special Pages List
In 1.16 the name of the extension is listed as "&lt;deleteoldrevisions&gt;" and on the special page of the extension the heading is "&lt;deleteoldrevisions&gt;" as well! Page title is the same thing. Any suggestions? 2nd August 2010

[Fix 1 of 3] $wgOut->setPageTitle( 'Special Page:DeleteOldRevisions' );
 * This extension uses $wgMessageCache->addMessage. That method is deprecated in MediaWiki 1.16. It should still work though, as far as I can tell. Reach Out to the Truth 15:26, 2 August 2010 (UTC)
 * Fixed in version 1.4.3 Jehy 09:45, 14 September 2010 (UTC)

not working
results in a blank page with mediawiki 1.15.x, any ideas?
 * Hello. Fixed in 1.4.3? Jehy 09:45, 14 September 2010 (UTC)

Doesn't work with high number of artices
Article name: % Namespace: -100 Modus: Test only

Old revisions of 1216 pages need to be checked. 0 old revisions found.

No changes have been made.

Article name: % Namespace: 0 Modus: Test only

Old revisions of 402 pages need to be checked. '''7 old revisions found.

No changes have been made.

Probably, the problem with the query, which has 1216 values in IN, but in MySQL docs: The number of values in the IN list is only limited by the max_allowed_packet value. http://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html#function_in

I've changed max_allowed_packet from 1MB to 50MB and to 512MB, but it didn't solve the problem.

Any ideas how to solve this? Thanks in advance. --217.12.216.18 07:54, 13 August 2010 (UTC)


 * Hello. Please, locate the SQL query which is too long, I'll try to do smth with it.Jehy 09:42, 14 September 2010 (UTC)

[FIX] Encoding and Inheritance problem (2010/08/21) - 1.4.2

 * That bug: "Fatal error: Class 'DeleteOldRevisions_HTMLForm' not found in ROOT/extensions/SpecialDeleteOldRevisions2/SpecialDeleteOldRevisions2.php on line 371" was a encoding problem. Other minimal bugs are fixed, and now are working with 1.6+ The fix is packed as 1.4.2.

Preserving page history but not revisions?
How about only deleting the data in the field 'old_text' (table `mw_text`) for old revisions, instead of deleting that whole row? This will preserve the page history and still reduce the DB size. The links wont work any more or perhaps will only show changes from 0 Bytes to the next but thats ok. I really dont like loosing the page histories. --Choshi 02:15, 12 September 2010 (UTC)
 * Hi. I don't see any meaning to this:) Why do you want to preserve editing metadata but not revicions itself? What use has metadata without the article text? Jehy 09:41, 14 September 2010 (UTC)
 * With what it is right now, everything is deleted. We dont know when the page was created and who edited and when. The only thing we have left is the last editor. All other information is lost. Often we want to see who has edited the page and when, when it was created. If the diff link doesnt work, thats still ok because we would have at least some information in the history. So if the field 'old_text' (table `mw_text`) was set to null or zero, that would do the job. I believe in that way, you would also not have to change/delete any other tables since the main data that takes up space has been deleted and we keep everything else.
 * What do you think? I understand this means changing a code a lot and maybe you dont agree this is a good way. I'll try to play with your code and see if I can come up with something. The way I would do it is: 1) set old text = '0/null' 2) add "diff not available (article size in KB)" in the end or start of the edit summary of that certain revision to let people know they cant see the changes, but everything else is still there. --Choshi 15:20, 15 September 2010 (UTC)