Revisioning for content types set as profiles?

Thanks for your interest waterssaz,

I feel you gave an important clue:

"However when I view the 'content profile version' of this node when accessing under the 'my account' menu item, ie stored under user/ and not node/ then the profile listing can be edited without ever creating a new revision and without the revisioning module seeminlg taking any control over it."

Revisioning currently only handles URLs of the form ..../node/%.
I'll look into allowing .../user as well -- just hope that I'm not opening up a can of worms, in that it turns out to have side-effects via modules I didn't even know existed!

Rik

A rough cut of this feature was checked in today and will be available in the development snapshot of 5-Jun-09 or later.

Note that because content profiles don't have distinct create (initial) and edit (subsequent) phases (there both "edits"), the "auto-publish" feature (see Content management>>Content types>>edit, section "New revision in draft"), if switched on, won't work when creating the first version of the profile.

I haven't tested this in the context of CCK (only tested with Content Profile by itself), so have a look and see if it works for you.
Rik

Great! Will consider it fixed until someone reports a problem - Rik

Hi, I have the same issue as comment #2
"However when I view the 'content profile version' of this node when accessing under the 'my account' menu item, ie stored under user/ and not node/ then the profile listing can be edited without ever creating a new revision and without the revisioning module seeminlg taking any control over it."

I made a cck content profile and when I want to make changes when accessing it under 'my account' I can only view and edit the current version. When I access the same node via /node//edit I get the latest version.

I compared the module code of versions 2.x and 3.x and it seems that the code which fixed this issue in 2.x (in revisioning_nodeapi() ) is not available in 3.x.

Is it possible to fix this? Was there a reason to exclude it from the 3.x version?
thx in advance!

Content profiles appear to ignore the "Links to edit content default to" setting from the revisioning module when you are using a path like user/[uid]/profile/[content type]. This is happening because the content profile module uses a different page callback for that path (content_profile_page_edit) which looks up the node by type and uid rather than by nid. The revisioning module has no replacement for this callback.
Could this be added to the next version?

I am still searching for a solution. I looked deeper into the code, but couldn't find an easy fix...:-(, but almost half way :)

I don't think you need a replacement callback for content_profile_page_edit. This function uses content_profile_node, which uses node_load.

The node passes hook_nodeapi, where you could trigger a load of of the latest node if the arguments of the url are like the ones from content profile:
$edit_user_profile = ($args[0] == 'user') && ($args[2] == 'edit') && !empty($args[3]);

case 'load':
  if($edit_user_profile) {
     $vid_to_load = revisioning_get_latest_revision_id($node->nid);
      if ($node->vid < $vid_to_load) {
        $node = node_load($node->nid, $vid_to_load);
      }
  }
..

Has anybody come up with a solution for this issue as we've hit the same problem too.

Basically when the node is viewed directly then the revisioning tabs are available and revisions other than the current one can be selected and published or edited.

However when viewing via a user node the revisioning tabs are not visible and it's only possible to edit the current version and not the latest revision.

@Isostar #13, 15:
What is the code you're referring to?

@Ollie222, #16:
What are the versions of the modules involved, so that I can reliably reproduce your issue?