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

ymmatt’s picture

ymmatt commented

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?

Kripsy’s picture

Kripsy commented

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.

ymmatt’s picture

ymmatt commented
Status: Active » Fixed

Thanks, I've committed this to CVS, it will be in the next release

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

JHeffner’s picture

JHeffner commented
Status: Closed (fixed) » Needs work

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

JHeffner’s picture

JHeffner commented

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.

realityloop’s picture

realityloop commented
Status: Needs work » Closed (fixed)

Cleaning up issue queue, please re-open if still an issue