eZ Community » Blogs » Peter Keung » Using a preview siteaccess as an eZ...


Using a preview siteaccess as an eZ Publish content staging solution

Wednesday 17 April 2013 4:30:23 pm

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Using eZ Publish's siteaccess system combined with hidden nodes, you can quickly create a flexible content staging solution.

Much is written about the power of the separation of content and design, but an important element of this is that siteaccesses, in a most technical sense, are just a collection of settings. These settings control many, many features, such as which designs to use and which templates to load, as well as how to filter what content to show.

One such setting controls whether or not to show hidden nodes. This is enabled for the Administration Interface (otherwise you wouldn't be able to manage and unhide hidden nodes!) and disabled for public-facing siteaccesses:


If you make a copy of your front-end siteaccess settings folder, change that one ShowHiddenNodes setting to "true", and add this newly created siteaccess to a few "setup" settings, you'll have separate site on which editors can preview new content that they've hidden. (Of course, by default you can already preview any individual piece of content, but you cannot preview entire sections of a site or an entire site as a whole.) Here are the general steps:

1. Create a new siteaccess folder as a copy of your public siteaccess (in settings/siteaccess). Note that if you have siteaccess-specific folders in extensions, you'll have to copy those too. For the purpose of these instructions, we'll call the preview siteaccess "internal_preview".

2. Edit settings/siteaccess/internal_preview/site.ini.append.php and set[SiteAccessSettings]ShowHiddenNodes to "true".

3. Edit settings/override/site.ini.append.php to add "internal_preview" to the list of available siteaccesses:


4. If you are using host-based siteaccess mapping, edit settings/override/site.ini.append.php to add the new siteaccess:


You'll also have to configure the necessary domain / sub-domain DNS and virtual host rules.

5. In site.ini.append.php for other siteaccesses that share the same content tree, add an entry to[SiteAccessSettings]RelatedSiteAccessList. If all of your siteaccesses share the same content tree, you can simply add this once to settings/override/site.ini.append.php.


6. Clear the cache, at a minimum the INI cache.

You then have flexibility on how to control access permissions to this new preview site. If your entire staff is behind a virtual private network, then you can simply restrict access to the domain or subdomain within the network. Within eZ Publish you would then grant "content/read" access to the Anonymous user. If you need to open the domain or subdomain up to the public, you can protect it globally using HTTP authentication. Or, if you do not grant "content/read" access to the Anonymous user, you can manage access completely within eZ Publish by granting the necessary "read" permissions to different user roles and user groups, and apply those permissions differently to different areas of the site. You could even create two preview sites: one that is internal to a network and one that is password-protected but accessible to anybody on the Internet. One extra note: be sure to block search engines from visiting the preview site(s)!

Other content staging solutions

The biggest limitation to the approach above is that it doesn't work for edits to existing content, since hiding a node hides all versions of the node. Also, the biggest concern is usually that you're forced to stage content on your production site, which runs the risk of affecting other live content or the site's stability in general.

An alternative, more involved approach is to make content changes on a separate, staging install and synchronize the content manually, or programatically using either the eZ Content Staging extension or thepackage and ezpm.php command line tool features.

If your production site does not need to support user-generated content or any type of content updates in general, you could also consider making all edits on a staging install and then completely transferring the eZ Publish var folder and database to the production install when needed.

Proudly Developed with from