Or not. I have the toolkit installed, but I feel like I must be missing some sort of documentation, because I cannot find anything that would help me figure this out. My main problem is where to specify the staging location? But in general, if there is some guidance someone could provide, I would be very appreciative.
Staging generally requires you to have a separate “site” and you publish the staged content (and the public content) onto that site. This means that you have a site root location (in the site definition) and perhaps a “delivery context” as well (although many customers who use staging use the same assembly and delivery contexts as the main site).
It seems I need more than just a separate site. At this point, I had to also create a separate edition and add values to the variables. I have the site publishing to the correct location when I run the edition, but it is using the public url for inline links, which is exactly what it should do, seeing as how when I created the inlines, I used the content from the public site.
This is also creating the unwanted behavior that when I run a search in Cx, I return two copies of the same thing - one for the public site, and one for the staging.
You should not need a separate folder tree (which is what causes the item to appear in 2 different folders), but you will need a separate site id and separate editions. You should be able to keep the same location schemes and context variables.
I’m not sure I understand your setup exactly, but perhaps if you just created the Staging site so that it used the same root folder path as the original site your problems would go away.
The goal I want is simple, I think. I want the authors the ability in the workflow to push the site to a staging server so that outside people can review the site without having to log in to Rx. This staging server sits at a different subdomain than the production server, but the content will sit in the same folder. So if production is www.myserver.com/myfolder, then staging is stage.myserver.com/myfolder.
Here is what I have done to achieve that goal.
Under Sites, I copied the site that publishes to the production server and made one for the staging server. In that, I changed the site address and the publishing root location. Everything else remained the same.
At this point, I realized I would need a separate edition. Under Editions, I copied the production server version, changing only the destination site.
When I ran the edition, it worked, but none of the variables in the templates resolved, which is when I decided that I needed to add entries for the site to the variables. Under Variables, I added one for $rxs_navbase and $rxs_urlroot, both times choosing the Staging version in the Site dropdown.
This solved the variable problem, but then I noticed a new problem - inline links were resolving to the production site. I went in to Cx to see what was going on, and that is when I noticed that every page was being listed twice - one for production and one for staging.
And that is where I am stuck at the moment. Again, I feel like I am missing something obvious, but I’ll be damned if I know what it is.
It sounds like you have cross-site links for your links. Generally, you don’t want this unless you really have a need. Cross site linking is implicitly controlled by the display format on the search; if you include a site column, then the link will be created as a cross-site link. If you also include a folder column, then the link points to the target in a specific folder (otherwise, it points to the first item after sorting them all in ascending alpha order by path.)
With cross-site links, you can’t accomplish what you want because cross-site links always point to the item on the original site, you need relative site links to accomplish your goal.