This website uses cookies to ensure you get the best experience. Learn More.
Staging vs Publications
Recently my friend and coworker Andrew Jardine and I were together in Rome for a Liferay Partner event where we were part of a round table discussion about all things Liferay.
Even before the session, Andrew and I had already picked up our friendly argument about Staging (me) versus Publications (Andrew) and which one is better. For us it has always been more of a friendly jab at each other, but it is based upon our histories with each solution.
For me, I ran into trouble using Publications (issues that have long since been fixed but I think I'm still holding the issues against Publications), and most requirements that I've been dealing with have been easily satisfied by Staging.
Andrew, like many others, have been frustrated at times using Staging and found the new Publications model a breath of fresh air.
Is one better than the other? Let's explore them and find out together...
I know this will seem more like rambling for a while, but these background details that I'm sharing will help to explain my conclusions and why I might suggest one vs the other.
Staging has been a key part of Liferay since version 6.0, and was actually a client-sponsored enhancement.
The client in question wanted a way to preview how the site would appear before it went live. Workflow approval of assets was not enough, it was necessary for them to review how each page would work before it went live.
And staging was born. It was designed after a dead tree publication process, wherein there would be someone responsible for laying out the complete page, selecting the colors, fonts, content, ads, etc, and the publisher who would review this work and either send it back for rework or would publish it.
The implementation of Staging uses a duplicate of a live site. Changes are made on the staging site, they can be reviewed and (the way it used to work) marked as "ready for publication". When the site is published, approved pages are copied from the staging site to the live site. Now the "ready for publication" has been removed, the assumption being that any page (not in draft state) is actually ready for publication.
There are two forms of Staging, Local and Remote. In Local staging, the staging site copy is in the same Liferay cluster as the live site, and in Remote staging, the staging site copy is in a completely different Liferay cluster. Remote staging can isolate the cluster where changes can be made and offer heightened security and protection, but Local staging tends to be a bit faster and not subject to network issues during publication.
The internals of both forms of staging are effectively the same - a LAR export from the staging site is made, and the import of the LAR happens into the live site. The LAR export/import is automatic, whether local or remote.
And in every version of Liferay since it was introduced, there have been bugs in the process, and those bugs have been frustrating for users and implementors and folks often ask why, after all of this time, are there still bugs in staging? Shouldn't they have been fully addressed by now?
To answer this, I have to pull back the curtain and share what goes on behind the scenes...
The perception is that staging is pretty simple... I select one (or more) pages from staging, I select the Publish button, those pages are copied over to live, and now the changes are all on the live site for real users to see.
Internally, though, this is a really complex problem. If I select a widget page to publish, I'm not really selecting only a page. A Liferay page is a container of portlets, each portlet has configuration for the instance, so those things get selected. If one or more portlets are Web Content Displays, well they point at web contents and those may need to be published. The web content might be based on a structure and a template, so those would need to be published so the web content would work. The web content can have related assets, ratings, categories, and tags, and these items would also need to be published to live. The web content itself may have embedded links to images or documents, so those items would need to be published. Those files are in folders in D&M, so those may need to be published. Documents could be based on a custom document type, so that would need to be published...
What complicates things further, for all of those things that are possibly selected to publish to a page, we really only want to publish the things that have changed on the staging side. If the web contents haven't changed, there's no reason to republish those again.
But then there's also knowing what needs to be published because it hasn't before; the documents, for example, are in a folder hierarchy, does the hierarchy exist on the Live side, either full or in part? Which pieces have not been published because they need to exist for the document to be published...
So there's a lot going on here, and I only selected a single widget page... What happens if I select multiple pages? What happens when I select content pages which are composed of fragments with configuration, the fragments themselves, the related data the fragments reference, ...
This really does blossom into quite a complex problem and the implementation then tends to be on the fragile side.
And what makes it worse is if (when) Liferay is building a new feature (such as Objects), if supporting staging is not included as a non-functional requirement, there may be no staging support for the feature at all, or maybe it is added in as an afterthought...
There are a number of use cases that Staging solves:
That last one is important. If you are using remote staging, assets outside of the site, i.e. those from the Global site or from an Asset Library, will not be included in the remote staging publication. If those assets don't exist on the remote live site, the publication (import) will fail. This isn't an issue with local staging because the Global site assets and the Asset Libraries will of course be there.
So the Staging mess had been around for a while and it was quite obvious that the complexities involved in selecting and publishing all relevant assets was not going to go away, so Liferay started to rethink the whole Staging thing...
And, what started as a way to track row-level changes across all Liferay database tables grew into what is now called Publications.
With Publications enabled, when a new Publication is started, as existing records would otherwise be changed, instead they are added as a new unique row, but they include a foreign key reference to the current Publication.
This tends to be quite useful, yeah? When you want to publish a Publication, you're basically finding every record with the Publication reference and making that record "live".
This is a super-simple solution for the complexity involved in Staging trying to identify records that need to be published, since we're tracking individual changes, there is no discovery process necessary.
In fact, Publications ends up being very git-like in that you can have multiple Publications (branches) going at the same time, each one tracks its own changes and doesn't change "live" (main branch) directly, each can be published (merged) separately or even discarded...
But, of course, therein lies the rub - just like git, you have to worry about collisions and collision resolution. And not the simple case of "I'm publishing the only Publication I have to live" kind of thing, the more complicated "I have multiple publications and, in each publication, I have made different changes to the same content page, now I want to publish them all" sorts of things.
In the initial releases of Publications, this was one of the things that hit me almost every time... Try to publish a Publication, get the collision dialog, and wham, I couldn't go further because there was no real merge process.
Additionally, Publications is scoped at the instance (company) level. So if you start a publication and then start moving around to different sites and different asset libraries making changes, those changes would be tied to the current Publication, whether that's what you wanted or not.
This was another thing that tripped me up with Publications... I'd start a Publication for changes I was working on for a specific site. I get an IM asking me to make some change to instance settings or another site or an asset library... I'd drop what I was doing, go make the change, then return to what I was working on... However, since I was in a publication, those on the fly changes I made were also tied to the the publication, and I had no way of doing a "partial publish", so I basically had to exit my Publication, re-apply the changes that were asked for, then I could go back to my Publication to finish the work on the site, but now I have changes from two branches and, when I am finally ready to publish, I have the collision dialog to look forward to. And of course this is if I actually realized that I did the changes in the Publication, more often than not I would say "Hey what you asked for is done" only to hear back that the requestor couldn't find the changes, then I'd realize they were in the publication...
So yeah, I held those issues against Publications because I didn't face any of those issues with Staging...
But, I have to admit that Publications has been getting better, feedback like mine has been used by the team to make necessary changes, ... The merge process has gotten much better, fewer collisions as Publications is better able to automate the merges. Changes that are part of a Publication can now be moved to another Publication, so I can solve my last issue by creating a new Publication, moving the changes I didn't want part of my current Publication there, then I can publish that Publication on its own...
So yeah, things are getting better with Publications...
And the being instance scoped rather than site scoped? That's actually a good thing, especially if you are following my advice to stop using the Global site and even the regular sites for the content, instead putting the content into Asset Libraries... Since the Publication spans all of those, if I'm making changes across multiple Asset Libraries related to a Publication, when I publish it all of those changes will be published too.
Publications has the following set of use cases:
Publications also comes with a restriction - if you need the security and protection by using separate clusters for editing content, Publications is not for you. Only remote staging has this capability, Publications does not.
So maybe after reading this blog you're thinking, "I'm currently using Staging, but I want to give Publications a try" or vice-versa...
Well, here's how you're going to switch...
First thing you need to do is publish everything. When you disable Staging, you're throwing out the whole Staging site, so anything that is not published is going to be lost.
Next, you'll go to the Site menu, then Publishing -> Staging to get to the Staging Configuration settings. Change from Local or Remote (whichever you're on) to None and hit Save.
Once you do this, your Staging site is going to be deleted and, depending upon the size of your site, this could take a while...
Once it is done, go to the Waffle menu, to Applications, then to Publications. On this dialog you can choose to Enable Publications.
From here, just follow the instructions for Publications and you can learn how to handle them.
First thing you need to do is publish and/or revert (as necessary). When you disable Publications, expect that your publications (and publication history) will be discarded.
To disable Publications, go to the Waffle menu, to Applications, then to Publications and uncheck the Enable Publications option.
This should delete your publications and history, so this might take a while.
For each site or Asset Library to enable staging for, go to the Site menu, to Publishing -> Staging to get to the Staging Configuration settings. Change from None to Local for local staging, or None to Remote for remote staging. If you're just wanting to test out Staging, I'd recommend going with Local, save Remote Staging setup for the production environments because it has some specific configuration requirements.
When you enable staging, the site or Asset Library is the live version, so a copy must be made for the Staging version. This can take some time to complete, so be prepared.
From here, just follow the instructions for Staging and you can learn how to handle it.
So, which is better, Staging or Publications?
Well, it depends really upon your use case, yeah?
If you need remote editing, you only have one choice, Remote Staging.
Otherwise, and don't tell Andrew this, Publications would probably be my go-to solution, but only if I can be one one of the later releases where they've made lots of improvements to collision handling, moving changes out of publications, etc.
Staging is still going to work, it hasn't necessarily been deprecated or anything, but I'm not really sure that there will ever be a "bug free staging"... I mean, if you can set up staging in your environment and you're only using those features that support Staging and you can publish without problems, then you're probably going to be okay, and you'll enjoy seeing the staging site entirely and knowing what you'll have in Live when you publish...
But ultimately I have to admit that Publications is more in line with how we should be handling assets, namely by adopting and using Asset Libraries almost exclusively, and therefore Publications stands out as the best fit for adhering to these kinds of best practices.
Before choosing, I do suggest you do your own comparison research, especially paying attention to the feature comparison and the supported types matrix.
Finally, note that neither option directly supports Liferay Commerce or Liferay Objects. Your only option here is going to be workflows. This shouldn't be a problem though because neither of these are really presentation, they're just data. The presentation aspects (display page templates, things like that) are subject (per the matrix) to the publishing options.
