Slots become "unregistered"

Hi
I’m working on a 6.5.2 system with legacy 5.7 xsl templates.
What I what is is to conditionally apply different snippet templates to slot items depending on the page template from which they were called.
To do this have I created a duplicate XSL variant in the workbench for the page variant but appended an html parameter to each URL field in the variant (e.g.)
Page.html?snippet_variantID=1
Page.html?snippet_variantID=2
I then add an exit to the resource that generates the page using PSOMutateSlotVariant and replacing the default oldvariantID for the slot I want with a value captured from the html parameter snippet_variantID.
This works beautifully and I can preview the items.
Only problem is that if I try to edit the slots in the content explorer. I get a message “No slots registered for this content type”.
Not only is the slot for which the new snippet templates were defined missing, all the other slots for this content type are no longer picked up.

If I look at the content item in Impact Analysis the slots items are there and look fine.

Help!

Thanks

Ben

Interesting, I’ve never seen this one before.

We used this technique (we called it “shared variants”) in Rhythmyx 5 all the time (the 5.x Fast Forward makes extensive use of it), but it’s not necessary in 6.x implementations, and I don’t recall anybody having this problem on upgrade.

Does this content type have any other Variants (especially page variants) that use these slots?

David
Thanks and apologies
This problem is specific to our installation. There have been previous modifications to the sys_rcSupport application that break when new snippet variants are added. Argh!!
Can I/we close this thread?
Ben

Ben,

Good to hear that you know what the problem is.

This isn’t Tech Support, so we don’t “close Threads” like they would close a support call. These posts are here for everybody to learn from, and the more you post about the details of the problem resolution, the better the chance that you will save somebody else from falling into the same trap.

Hopefully, there aren’t too many customers who will see this problem, but it was common at one time to modify sys_rcSupport to add additional “authTypes”. These customers need to be aware that they need to examine this on upgrade, unless they plan to convert to Velocity Templates right away.

Dave

Hi

Same issue here; but this one was the outcome of an MSM Archive Deployment. (I did slots, templates then slots again following Rhythmyx_Multi_Server_Manager).
Is there a way to restore this other than restore the server from a backup?
Will overwriting sys_rcSupport from an older copy solve the issue?

Thanks.

YR