Paging for listed revisions that match criteria

I think we have 2 choices:

1) generate the result in several pages

2) show the user only a report of the quantity of revisions that are going to be deleted or already deleted.

let's see what Greg thinks about it, i personally don't see the point of listing all revisions affected... and think just telling the user that say "5200 revisions deleted." and logging it will be enough.

I too believe that since the listings that is shown, can't be edited or some revisions excluded from the list, it is better to just state how many will be deleted upon pressing the button (which is more information that when cron deletes them all).

Also, right now I have a watchdog listings for each revision that is deleted. Is that overkill since they can't be retrieved anyway. Maybe again just one entry stating how many revisions were deleted.

Thanks for starting this conversation.

Then let's do it! so we are going to:

1) show the end user how many revisions are going to be deleted before pressing the button.
2) show the end user how many revisions deleted after they press the button.
3) log how many revisions deleted automatically.
4) log how many revisions deleted by user x.

Greg! do you need my assistance or you will implement it yourself?

Yes, please do roll a patch for exactly what you have presented. All four would be excellent. Thank you. Might be the start of working together on this. -Greg

This sounds like some fine improvements to me! I was just about to write a patch myself that should be able to to just this (minus the logging).

One great improvement with this proposed solution is that the drupal_set_message() function will only write one message to the $_SESSION['message'] instead of writing "Revision Deletion: Aged Node nid=%node, %title, Revision vid=%rev deleted." for each deleted node. With the current solution we have a performance issue due to the possibility that huge amount of data could be stored in the $_SESSION.

If you need another co-maintainer for this module, just PM me.

O_o, please do roll the patch. I think that you could probably just count the number of results in the array of the this line (appears twice).

$results = revision_deletion_data();

-Greg

No patch yet. However, I have an objection to it, maybe. I also need a "pick and choose" form because there are additional choices I would like to see and I haven't gotten them implemented yet (if it is even possible). In some cases, I want to keep the last revision on a day; sometimes that last revision per day per user; etc. In almost all cases, I want the first version (for diffing) or the last revision on the first date. Right now, I think another "operation" (see #547650: Coding standards) that will produce a list of all revisions for a node that allows the user to check off the ones they want to delete (something like admin/content/node)

I have the "pick-and-choose" form (which is paged) and was thinking about porting much of the technique to the main list.

I understand the request because I got interested in this module because of a site for exactly the problem you mention. The issue I see here is where to break the pages. If one says "every 20 lines" then it could break in the middle of a node's revisions. If you say "every 10 nodes," you could still end up with an enormous list.

So I'm sort of leaning towards something that looks sort of like the node admin page, but with collapsed fieldsets for each node. Or a list that says "node 123 has 20 revisions that will be deleted" and a link to see the list.

Another question is: Do you include the "Run Revision Deletion" button on every page, or just the last?

Committed to both -dev versions.

I would still like to see answers to my questions. The way it is right now, you can get a node's revisions split and the button is on every page.

Included in the -rc1 versions.