So, I have 5 different publishing targets (or, website-environments):
[ol]
[li]DEV[/li][li]QA[/li][li]PREPROD[/li][li]PROD1[/li][li]PROD2[/li][/ol]
all of these are located on the filesystem in NFS mounts at:
/data/<target name>/
Is there a way to publish to all 5 locations using a single Site definition and Context in 6.5.2 or later? If not, what is the best-practice method for accomplishing this goal?
Sam,
See “Extending Publishable States”, p. 108 in the Technical Reference (Version 6.5.2 link).
You should only need one Site definition. The Contexts you need depend on the directory structure in the target Web server.
RLJII
There’s a bit more to this issue than just extending the states: you have to define which revisions get published on the various targets.
This will require, at a minimum, new Item Filters. There is an Item filter in the PSOToolkit that will deal with 2 different targets (Production and Staging) but having more targets than this will require additional customization.
The server currently records only the “current” revision and the “last public” revision. Depending on the rules for your publishing targets, you may need to track additional revisions. Again, this is custom functionality.
What I have now is 5 Site definitions, each pointing to different root locations for the different web environments. I have 5 editions that all have very similar content lists (where the only differences are the item filters used). I have 3 custom publishable flags: ‘d’ for dev, ‘s’ for QA, and ‘p’ for preprod.
Each of these, I link to custom item filters using the sys_filterByPublishableFlag and PSOStagingItemFilter rules such that the dev item filter will publish for d,s,p,y flags and any workflow state named ‘dev’ and the qa filter will publish for s,p,y flags and any state named ‘qa’ or ‘qa test’, and so forth.
All of this works fairly well, but it’s time consuming to build and a nightmare to maintain. There’s got to be a better way.
That’s why I was saying, if I could use 1 site, 1 edition, and somehow build out the deployment location in a context’s location scheme similar to $sys.site.getRootLocation() + $envpath + [normal location scheme stuff], then I’d be golden.
[QUOTE=rljohnson;13485]Sam,
See “Extending Publishable States”, p. 108 in the Technical Reference (Version 6.5.2 link).
You should only need one Site definition. The Contexts you need depend on the directory structure in the target Web server.
RLJII[/QUOTE]
So, you’re saying that I’d need to define different contexts for all these targets? that’s even more work than setting up multiple sites and editions, with over 150 different locations schemes in each context…
Is there any other way?
FYI, my directory structure is <code>/data/targetName/</code>… after that, everything is identical for all 5 targets for this site.