» #csuc09 - Cascade Conference, “Best Practices with Sites”
Penny Harding, Services Developer, Hannon Hill. “Best Practices with Sites.”
Best Practices with Sites
Goal is to give general guidance on how to use Site features
Try to centralize everything you can—data definitions, blocks used on multiple sites, script formats that can be re-used—put this in one main site, then you can assign permissions so other users can’t change these assets.
Not global, but set up a site for centralizing assets
If you want a basic site to reuse your original page type, set up a new site and set up new content type. Select the Page Type from the Main site you set up (select from Sites dropdown menu)
- The new site/page will have the same look/feel as the main site
- Note: every page now requires a Content Type
You can override the configuration set at the page level, but that’s not recommended—it’s not recommended to override at the page level if you plan to reuse that setup. Set up a new configuration set. You can set up another Page Type, re-using the template, but using an edited copy of the configuration site.
Items that can be shared across Sites:
- Content Types
- Configuration Sets and Metadata Sets can be shared through Content Types
- Templates can be shared on Configuration Set creation
- Blocks and Formats
- Files (CSS, images, javascript files, etc.)
Items that cannot be shared across Sites:
- Asset Factories
More information available at: http://hannonhill.com/kb/Linking/
New Syntax to note:
- site://SiteName/path/to/asset Link to assets on a different Site. This works for images, pages, files.
- [system-asset:local]/path/to/asset[/system-asset:local] This tag can be used so that you can have a standard template used by multiple sites but have the link to the image/CSS/javascript file be on each individual site. Works within Templates and blicks assigned at the Template level.
- link Within the XML rendered by index blocks, there is now a link item from each asset. Link is the same as path but includes the site id as well.
// Use [system-asset:local] tags for use in blocks that are shared across sites, to pull in an asset that is specific to that site. Let’s say there’s a CSS file in each site stored in the same place (let’s say a local CSS that just changes the header for that site.) You can share the template and use the [system-asset:local] tag in a block (residing in the main site) to link to that asset locally. The asset will have to reside on every site that shares the configuration set calling the asset.
Additional items/tips to consider when sharing across sites
- When sharing a block and format across sites, use link instead of path within your XSLT. This is especially important if the block being used is indexing a specific folder from a specific site.
- Keep all of your generic blocks in one admin Site (Current Folder, Current Page, etc.)
- If using [system-asset:local] tag, make sure that item exists in the same place on all sites.
- Within a page if you are linking to any item across another site (CSS, image, javascript files, etc.), make sure those items have been published live before publishing your page. When publishing a page, the page with not automatically publish items linked within another Site.
// In order to link between sites users will need read access to those sites so they can browse to the page they want to link to (or they might be able to guess at the path.)
Note on Sites and Permissions—you can’t take away permissions, so set up each user with the least amount of permissions they’ll need, then step up their permissions on the specific sites they need more access to.