Is there any way to have a generic set of preview / active assembly menus that passes the $siteid as a variable (as opposed to declaring it specifically in WB)
The problem we’re having is that we have multiple communities and thus for each community we have to create a unique menu entry for Preview, AA (as the site id is hard coded on the menus). While this seems innocent enough with a few communities, we are going to have a couple hundred communities and if we can pass through a variable as opposed to creating a couple hundred action menus, this would greatly help in the overhead of managing all the communities and sites.
It isn’t a matter of wanting to have one site per community. There will be multiple site for certain communities, but in general there would be one site per community. The second question is one that I have, but things that I have thought of to figure out what site it is:
If you are previewing an item, that item will be in a folder (and the folder id is being passed to to menu item). Traversing up that folder (ie. the parent of the folder…) should lead to the site folder, at which point we should be able to get the site id.
Something that we noticed in the logs was that navigation elements was being used to get the site id (i’m not sure as exactly how we triggered that log entry, just that it was noticed in passing). I’m just throwing this out there as I need to look at this further to see what exactly we did.
In general, to me at least, it seems redundant to create a menu entry for each community and differing site if there was a way to get to the site id. The only thing differing between creating a couple hundred menu items and three is just that site id.
The fundamental issue here is that’s no universal way to uniquely determine the site id.
You can narrow it down based on the folders that an item is in, and if this is a small enough number (e.g. 1), you’re pretty sure of the right answer. However, when the answer is more than one, there’s nothing in the User Interface that allows a visitor to select a site.
The publishing system ALWAYS specifies as siteid (one way or another) This gets passed in various ways
Let me think about this… I know that we’ve started down this path before and if it was simple and generic we would have done it already.
I’m curious if we could use the already existing variable $sys_folderid along with the PSX_FOLDER and PSX_OBJECTRELATIONSHIP tables to trace the child/parent relationships until we reach a point where DEPENDENT_ID = OWNER_ID, yielding the Site Root Folder ID. The Site Root Folder ID would lead us to the Site Root Folder Name which is mapped to the Site Def in the table RXSITES, which would then yield the site id.
What I’d really like is a system variable $sys_siteid so I don’t have to create 170 Preview Action Menus, 170 Publish Now Action Menus, 170 Compare Action Menus, etc.
That works in your don’t have any sites that are “nested” (that is, where one site contains the root folder of another site). We generally discourage this, but there are some customers who do it anyway.
Note that the folder id isn’t universal. If you are previewing from within a “Search” or from the “Inbox”, there is no folder id.
I agree that having a single menu option that used the site associated with the logged in community and/or parent folder/site in the tree would satisfy most user requirements.
Where there is a one-to-one ration of community to site, you are covered for all scenarios.
Where there is more than one possibility, it would seem reasonable as a first pass to just present it with the first one in the list (arbitrary or some user defined order of precedence). This could also be mitigated by making the displayed site obvious in the global site templates site via a header bar or other visual cue if it was not already so.
PSO wrote this solution for 6.5.2, and it appears to be working properly after the upgrade to 6.6.1. I haven’t investigated as to whether or not it’s built-in to core 6.6.1 or if it’s indeed the PSO solution that’s working for us.