We are trying to use the PSOReverseSlotContentFinder and have come across the following problem. Does anyone else have a similar problem or is this a configuration problem unique to us?
Structure of site:
Root
ContentItem1
ContentItem2
-+ Folder1
– ContentItem3
Content set up:
ContentItem2 and 3 are in a slot in content item 1
contentItem2 and 3 use the reverse slot content finder
Problem
On publish (and also on preview as published by changing the sys_context), the slot renders the link on ContentItem3 to ContentItem1 as within the current folder (/Folder1/ContentItem1). It appears that the reverse slot content finder is making links to other items relative to the current item, and not where the item actually resides…
Other notes
[ul]
[li]Navigation elements are set up appropriately.[/li][li]Preview within RX works, it is only when it publishes that the location is wrong. [/li][li]The link to ContentItem1 works from ContentItem2 as they are in the same folder location…[/li][/ul]
I suspect what is happening is that the sys_folderid parameter, which is passed in the assembly URL of the parent item is being passed along to the slot item as well.
Looking at the source, I can see where this could happen. However, the place where this occurs is in the “Base Class” used for ALL slot content finders, so changing it might well have some other consequences.
Can you perform an experiment for me? Can you simulate this a normal (non-auto) slot where you link ContentItem 1 to a slot on ContentItem 3?
When you do this, does the link come out correctly or incorrectly?
If the normal slot didn’t work, the problem would be a lot worse (essentially all our sites would be broken).
As it is, I tested using a normal slot and the links do render properly (on publish context). So it appears to be specific to the reverse content finder…
Properties of slot
Type: Regular
Allowed Relationship types: Active Assembly
Content finder: PSOReverseSlotContentFinder (with template and slot set)
I’ll dig into this. Might take me a day or two, as I’ve got some other projects going on right now. I suspect that we should be suppressing the folder id, and that we are not somehow.
This appears to be a function in the base class, which is common to all content finders, but that cannot be true if it’s working in the standard relationship content finder.
Thanks Dave,
We are using this quite heavily in a “resource / publications” content type (which is in development) and without this working, we can’t proceed with deployment.
And that worked as well . So it appears that this bug manifest itself in the reverse content finder only if it is referencing items in the root of the site. Hope this helps in finding a fix.
By any chance does your location scheme use $sys.pub_path ?
If so, there’s a known bug (RX-14393) where the content item in a snippet gets the wrong value of $sys.pub_path ONLY when the content item is in the site root.
For example:
Content item 123 is in folder //Sites/MySite/FolderA. Content item 987 is in folder //Sites/MySite. In content item 123 I add a snippet (s-title link) of content item 987 into a slot.
When assembling content item 123 $sys.pub_path returns “/FolderA/” rather than “/” which is what I’d expect to see.
If this is the problem you are running into, it should be re-producible with any content finder. If so, let me us know, and we’ll add you to the bug report as an interested customer. It’s not fixed yet.
Yes,
we are using the $sys.pub_path in the location scheme (how can you not use it?).
I checked to make sure that what i had reported earlier (where I use a “normal” slot that references a content item in the root of the site) was publishing the link correctly…and it is. So for us, only the reverse content finder is causing issues with items at the root of the site.
I’ve been through the code with a fine-tooth comb. The only difference I can see between the PSOReverseSlotContentFinder and the PSRelationshipSlotFinder is that the PSRelationshipSlotFinder explicitly sets the folder ID when the AA relationship contains the “sys_folderid” property.
As you probably know, the sys_folderid relationship property is added when the content item was added to the slot, but ONLY in the case where the Display Format used for the related content search contained the sys_folderid column.
I’d like you to verify that this is what is happening in your case. Look at the relationships that work correctly (in the database) and tell me if there is an entry in the PSX_OBJECTRELATIONSHIPPROP table for that RID with PROPERTYNAME of “sys_folderid”. If there is, then this is almost certainly working because of the Folderid being passed from the relationship property.
The PSOReverseSlotContentFinder cannot use this property (as it points to the folder of the dependent item of the relationship, and what we need is the folder id of the OWNER item). In my view the best fix is to patch the underlying bug, but I’ll have to discuss that Tech Support and the Development team.
First let me know if my assumptions are correct, and if so, open a TAR with Tech Support so we can track the request. Make sure that you reference this thread and tell them to talk to me (which I’m sure that they will anyway).
Dave,
While the PSX_OBJECTRELATIONSHIPPROP table exists, there is nothing in that table…
We have modified the search so that we are passing the sys_folderid (modified Related_content_by_template). (this was done a while back to resolve another issue related to cross site linking)
Given the above, do you still want us to file a ticket with techsupport or does this bring into question more issues?
Has this issue been fixed? I have used the PSOReverseSlotContentFinder to find the parent item for a slot but how would I create a link using the GUID that is returned?
Bug RX-14393 is scheduled to be resolved in a future release of the product. At this time, the workaround is to avoid placing any content in the root folder of a site if you’re expecting to use $sys.pub_path.
Once you’ve got the ID of the parent item, you could feed it into a JSR-170 query passed to an autoslot, specifying a snippet template that would then have access to the $sys.assemblyItem for that parent item, and so could generate a URL for it.
Just out of curiosity, but is there a reason you aren’t using a standard slot macro? I mean I assume you have set the slot to use the PSOReverseSlotLookup content finder, so you should be able to use a normal slot macro to display the “contents” of this slot (along with whatever template you wanted as well) …
(essentially all our sites would be broken).