Finding the folder path for a copy "as link" item

Hi

I use the getParentFolderPath function to generate the parent path for an item but if the item has been copied “as link” then the copied item has the same getParentFolderPath value as the original even though it’s in a different folder.

I guess this is because the function only accepts one parameter sys.item.guid so it will always base the folderpath on the original item.

How do I obtain the parent folder path of an item when it’s been copied “as link”?

Cheers
James

To get the path, deploy the latest PSO Toolkit and use alternative getFolder Path, one where you can pass assembly item as parameter.

Two more caveats to using paste-as-link:

  1. if you want to add those items to slots (like landing page for instance), you’ll need to be on version 6.5 and up. Then you need to modify search display options to include folder path. (Default option does not include folder path when creating relationship.)

  2. to build an automated index on “linked” items, you need to be on the latest pach. (Otherwise auto slot will return “original” items.)

I hope I didn’t forget something here…

Hi Sinisa

Thanks for the info and it’s all working although I did have to do some playing around.

If I used the assembly item in both instances it returned the same path for both items:

#set($link = $user.psoFolders.getParentFolderPath($relresult))
#set($pa_link = $user.psoFolders.getParentFolderPath($sys.assemblyItem))

I got around this by using the guid on one of them and the assembly item on the other

#set($link = $user.psoFolders.getParentFolderPath($relresult.node.guid))
#set($pa_link = $user.psoFolders.getParentFolderPath($sys.assemblyItem))

Cheers
James

It appears there is some confusion about how the Rx folder system works; let’s clear that up first. Users must realize that the Rx folder system is not quite like a filesystem; none of the items in folders are the actual instance of the item, they are ALL links. In other words, you could delete every occcurrence of an item in all folders in the system, but the item will still be in the system (it can be found via search.)
If you ‘paste as new copy,’ you are actually duplicating the original item and linking it to the target folder. If you ‘paste as link,’ you are not really copying anything, you are just creating a link to the source item in the target folder.

Now let’s look at how the 2 methods you are using behave.
getParentFolderPath(guid) finds all occurrences of an item in all folders. If the item is in more than 1 folder, the first folder is returned. The order of the returned folders is not guaranteed and thus should not be depended upon. It could be correct one time, and incorrect another (assuming the item is in more than 1 folder) (i.e. just because it happened to work this time, doesn’t mean it is going to work next time if there is more than 1 folder path. Generally, though, if the system hasn’t been modified, the order will remain consistent.)

getParentFolderPath(assemblyItem) returns the folder that was passed to the assembler. (If there wasn’t one passed in, it attempts to use the PSNavHelper in the assembly item to find a path.) Generally, this is going to be the correct path as the folder is passed in

James,
I hope the description above makes it clear why you got the behavior you did.
Looks like you got lucky this time, but your technique is not guaranteed to work. I’m unclear on what you are trying to accomplish. Why do you want to get the path of an item that isn’t currently being assembled? Are you trying to build some sort of nav to all instances?

Sinisa,
Why do you think you need v6.5+ in order to add ‘paste as link’ items to a slot and have a folder path attached to the relationship? This should work in older versions too.

James,

Did you fix your code based on Paul’s response? If so, could you please explain how you modified your code below? I am running into the same circumstance as your first mentioned.

I have an instance where “copy as link” is not functioning in the desired manner, a site where a piece of content needs to be copied “as link” within a new section of the same site, but should function as if I copied the item “as copy” without editing options… Basically, when a user clicks on the link to the copied item in the left nav, they should not be redirected to the original item, rather they should see the “copied” item within the current section. Clicking on the content item to edit within Rhythymx should open the original item, not in independent copy with a new content id.

This does not help to decided which linked copy to display in an autoslot. You only have access to the assemblyItem for the potentially multiply link copied items in the snippet template used to assemble them. To set up rules on which linked copy to use (e.g. always link to the linked copy higher up the folder structure, or according to an array of site sections in order of preference) the parent folder has to be examined in the page template. But the following…

#foreach($relresult in $sys.currentslot.relresults)
	$user.psoFolders.getParentFolderPath($relresult.Id)
#end

…just displays the same path for all linked copies.

Thanks Andrew,

One of my users posed the solution of reusing the full page content inline of a new generic page instead of trying to get this to work… I would think we would run into nested div and body tag issues if we were to do this. Does anyone else have a solution for this problem?

Do you mean each time a user wants to put something in two folders at once, they would create a brand new content item (presumably of a new content type set up specifically for this purpose) then add the “original” item in the new one via a slot? I guess it could work, with a lot of template finagling, but would be an enormous faff for the users compared to simply dragging and dropping. It would also mean you have these extra items floating around the place, whose content type isn’t representative of the actual content. Seems like a lot of compromises to workaround something that should have been thought through more thoroughly in the first place. We are basically wondering whether to disable the paste as link menu item completely, and giving up on content reuse (kind of a major reason for adopting a CMS in the first place, but hey ho…)

I agree, I think this is a huge issue with content reuse and should be addressed by Percussion. I really don’t like thinking about creating a placeholder content item to work around this issue, it seems like a new function should be created to extend the “paste” option dialog, possibly by creating a “duplicate as link” option?

[QUOTE=paulhoward;2665]
Sinisa,
Why do you think you need v6.5+ in order to add ‘paste as link’ items to a slot and have a folder path attached to the relationship?

This should work in older versions too.[/QUOTE]

We tried but it just didn’t work with 6.0. I think it was one of the patches…
!Correction: version 6.1 can be used with patch 13199. (plus some tweaking, if I remember correctly)

Andrew and Stephen,

I don’t understand why this doesn’t work for you. Got a feeling you both are really close…

“Copy-as-link” requirements in our implemetation are really outrageous. Users are working on hundreds of policies , all in one folder. When done, they “copy-as-link” to appropriate folders. So, published version shows policies in correct locations, however content providers maintain them in one place. Then I had to build an index of “linked” items located in “correct” folders.

One question: in your auto slot, is sys_folderid returned in the content finder query?

Thanks very much slolic. This does the trick. All my various autoslots go through a single macro for building JSR-170 queries, so just by adding rx:sys_folderid to the list of fields in the SELECT statement, I can now print the folder path either in a snippet template using…

$user.psoFolders.getParentFolderPath($sys.assemblyItem)

…or in a #for loop in a page template, using…

$user.psoFolders.getParentFolderPath($relresult)

Now I can get the folder path in the Rhythmyx repository for each linked copy of an item, I just need to write some code to decide which linked copy to use, based on some rules for which section of sites should take precedence.

I see the Rhythmyx Implementation Guide’s section on “Writing Automated Slot Queries” has been updated sometime over the course of 6.5.2 to go from this…

The select clause in the expression must include the fields rx:sys_contentid and rx:sys_revision

…to this…

The select clause in the expression must include the fields rx:sys_contentid and rx:sys_folderid

I hadn’t noticed this change at the time. In fact, searching the latest version of the 6.5.2 Implementation Guide, there are still examples using rx:sys_revision, and some using rx:sys_contentstartdate as the second field specified after rx:sys_contentid.

Could someone from Percussion just confirm that sys_revision isn’t needed in autoslot queries, or should all three be included (I vaguely recall someone on these forums complaining of multiple versions of the same item being returned?)

Andrew,

I knew you were close. :slight_smile:
Glad I was able to help…

Slolic and Andrew,

I must be missing something because I don’t see how getting the sitepath folder can be used to manipulate the link for a content item? Please let me know where my logic is not correct:

  1. A user wants to “copy > as link” a content item from another section, they perform a drag operation on the content item to the new folder.

  2. Previewing this new content item copy, the sys_folderid url parameter shows correctly since we previewed the item in the current folder. Linking to this item is where the problem occurs…

  3. On our test servers I cannot simply drag a folder from one section to another and choose “copy > as link” because I get an error stating

Error executing action <Drop-Drop-Drop-Drop-Drop-Drop-Drop-Drop-Drop-Paste_As_Link> : An unexpected error occurred while processing the CMS request. The error was: Failed to add child objects to folder “about”. These objects had non-unique names within the target folder: . These objects had non-unique names within supplied new children: colleges.

The folder name is unique within the folder so I am not sure why I cannot do this. So instead I created a new folder with a new navon, copied the generic page into the new folder and linked the navon to the content item (this id is the same as the copied item). Previewing the nav and clicking on the item causes the problem I am talking about, the link takes me to the original item.

The only place I can think to specify the folder id would be in the leftnav template, which currently looks like this:


#macro (getProps $node)##
	#set($title = $node.getProperty("rx:displaytitle").String)##
	#set($landing_page = $node.getProperty("nav:url").String)##
	##set($folder_id = $user.psoFolders.getParentFolderPath($relresult))##
	#set($submenu = $node.getNodes("nav:submenu"))##
	#set($axis = $node.getProperty("nav:axis").String)##
	#set($indentclass = $axis.toLowerCase())##
#end##
...
#macro(secondlevel $node)##
  #getProps($node)##
  ## this template processes the second level navons. Notice we are only processing two levels of navons.
  #if ($landing_page != '#')##
    li class="secondlevel">
      a class="$axis" href="${landing_page}">$title/a>
    /li>
	#if ($submenu && $axis == "SELF" || $submenu && $axis == "PARENT")##
    	#foreach ($navon in $submenu)##
			ul>#thirdlevel($navon)/ul>
		#end##
    #end##
  #end##
  #end##
#end##

You can see that I added Andrew’s example into the template code, which returns a path like ‘/sites/about/’. I really don’t see how that path would help when building the navigation link to the content item, I could see specifying the folder id somehow and manipulating the $node.getProperty(“nav:url”).String variable by specifying the folderid… is this what you are referring to? I don’t even know if you can replace the folderid property returned by the nav:url variable but I don’t see how the actual path would be useful…

I then thought maybe your example had something to do with the publishing content list generator variable, however all of my content lists have the rx:sys_folderid specified to be returned from their associated content types…

My problem was with autoslots (i.e. the results are searched for upon initialisation of the slot in the template during assembly.) You appear to be having problems with navigation slots, which are manual slots (in that they contain items that can be edited via the Active Assembly Table Editor - aka Related Content Control.)

I am not 100% sure of the nature of your problem but, AFAIK, if the Display Format that you have set up for displaying the results of the search for landing pages in the “Nav Landing Page” slot includes the folder path as one of the columns it displays, then as long as the user who selects the landing page choses the correct linked copy it will associate the navon to the correct one (presumably the one in the same folder.) Not exactly user friendly, which is why we only allow access to navons for a small community of users. If you can trust your users to be careful when selecting landing pages then you (the developer of templates) do not have to worry about it, nor use the getParentFolderPath() method at all.