Posted by Kripsy on May 15, 2008 at 8:32pm
Jump to:
| Project: | Save As Draft |
| Version: | 5.x-1.0-beta1 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
As it is right now, the draft block and list page link the draft that immediately precedes the published revision. This is how it works with Revision Moderation where that functionality might make sense, but with a draft system you will in all likelihood always want to have a quick link to the latest iteration to work on. I found a quick way to get this functionality: on line 302 of the save_as_draft.module remove DESC from the argument and you have it. I think this behavior is more in line with the "save as daft" mentality.
Comments
#1
I think I follow what you are saying, but let me clarify.
You want to link to the current published revision for editing, instead of the draft that is in waiting.
Example:
Node1 has two revisions, one is a draft, the other is published.
When I choose to edit this node you want to edit the published revision, not the draft revision
Is this what you are asking?
#2
No, obviously I would like the "Draft pending" block to link the draft :). The problem is if you have multiple drafts, it will link the oldest one by default. By removing DESC from the argument it links the latest. I can't really think of any reason you would always want to see the oldest draft. I believe this is left over from Revision Moderation which linked the "oldest" so that it would go through the moderation queue in chronological order.
#3
Thanks, I've committed this to CVS, it will be in the next release
#4
Automatically closed -- issue fixed for two weeks with no activity.
#5
Unfortunately the problem is a bit more complicated than this. If you have multiple drafts you do want to work on the most recent revision. However the SQL query does not work as expected. The query will return multiple revisions on a single node. This typically wouldn't be a problem as the code runs through it will update the last revision in the $revisions array. However, it is the limit imposed on the SQL query that is the problem. The limit gets imposed on vid, not nid so you don't always get all the revisions for a certain node in your result. It is possible to have a different revision linked in the block that is not the most current revision. This can also happen for the administration page depending on the numbers of revisions.
There are two ways to fix this. The first would be to impose the limit on the full returned result in the block() and pending_drafts_admin() routines. Memory usage could get large depending on how heavily the module is used. The second would be to re-write the SQL using groupings to pull out the revisions vid first, then another sql statement to pull out the information to display. I tried to do it in one SQL statement but found that the sub-query is extremely slow on MySQL 4 and ran at 19.85 seconds on my development box.
$sql = "select n.nid, r.vid, n.type, r.title, r.body, r.uid, r.timestamp FROM {node} n INNER JOIN {node_revisions} r ON n.nid = r.nid where r.vid in ( SELECT max(r.vid) as vid FROM node_revisions r INNER JOIN node n ON n.nid = r.nid WHERE r.vid > n.vid GROUP BY n.nid ) LIMIT %d";Warning: extremely slow, but it demonstrates the correct results
#6
Since I have only about 60 revisions on about 12 nodes I removed the limit from the sql statement that was causing problems. It's a temporary solution.
#7
Cleaning up issue queue, please re-open if still an issue