17

What are the best practices for publishing configuration on Sitecore these days, especially given the performance improvements on 8.2 when using the new publishing service?

  • Scheduled incremental publishes?
  • Workflow based publishes?
  • Allow manual user publishes?
  • Something else?

This is a multi-site scenario that will have ongoing site builds even after initial launch. So content will be updated frequently. I would like to minimize HTML cache clears and as much as possible make it easy for authors to ensure they publish all needed items.

Improve this question

2 Answers 2

Reset to default
11

  • If your content authors are strictly following WorkFlow, use scheduled Incremental publishes.

  • If workflow is not strictly used, use user manual publishes (Smart Publish), and try to cover related item publishes to reduce number of cache clears.

  • For multisite, if you publish item of site-A. It will clear html cache for all sites. It should clear cache for site-A only.

For this, you must customize the publish:end:remote event. For that, find the root item got published (on CD server), identify which site the item related is, and clear HTML cache for that site only. This case is nicely explained in "Sitecore Cookbook for Developers". Still, here is the code for that (Add this processor to the event and replace existing one):

protected void ClearCache(object Sender, EventArgs args) {
  PublishEndRemoteEventArgs pubArgs = (PublishEndRemoteEventArgs) args;
  string rootID = pubArgs.RootItemId.ToString();
  Database db = Database.GetDatabase(pubArgs.TargetDatabaseName);
  Item rootItem = db.GetItem(rootID);
  if (rootItem != null)
    ClearHtmlCache(rootItem);
 }

 private static void ClearHtmlCache(Item rootItem) {
  List<SiteInfo> sites = Factory.GetSiteInfoList();
  var selectedSites = sites
    .Where(s => rootItem.Paths.Path.ToLower().StartsWith(
     s.RootPath.ToLower()) && s.Database.ToLower() == "web");
  foreach(SiteInfo site in selectedSites) {
    ClearSiteHtmlCache(site);
  }
 }


 private static void ClearSiteHtmlCache(SiteInfo site) {
  string cacheName = site.Name + "[html]";
  Cache cache = CacheManager.FindCacheByName(cacheName);
  if (cache != null)
   cache.Clear();
 }
Improve this answer
2
  • Is there a reason for scheduled incremental vs attaching the publish to workflow, if I'm strict about using workflows?
    – nickwesselman
    Commented Sep 20, 2016 at 14:04
  • If workflow is strictly handled, both are same what I see. The only advantage scheduled incremental will have is less publishing and less html cache clear compared to auto publish with workflow - in the context of the original question. But again, choosing any of above practice should be driven by business requirements, than technology.
    – Yogesh Patel
    Commented Sep 20, 2016 at 14:15
6

I agree with comment from Yogesh about publishing following the business use case. I usually consider workflow based publishing(autopublish on approval)/manual publishing (assuming you meant adhoc publish and not person initiating publish daily at 9pm :p) to be both adhoc as there is less control on the time of publish. As we are all well aware of the consequences of sitecore publish (html cache clear), you would want to go with some scheduled approach which would work in most cases.

It is better to decouple the publishing operation from the workflow process to avoid the cache clearing scenario. You can always provide the ability to do adhoc publishes.

Latest Publishing Service: The latest publish service introduced, they do not hook into your normal Sitecore publish pipelines.

"The Publishing Service does not use any of the features, pipelines, and settings in the current publishing system"

It provides one bulk update to the "publishEndResultBatch" pipeline of the invoking process to be able to perform other tasks based on the result of the publish. So when thinking of using the new Publishing service, one has to revisit the pipeline processors added to original publishing system. There are limitations to the new publishing service currently, but sure they will be removed as it matures. Until then one has to choose one way or the other knowing the limitations.

Improve this answer
2
  • 2
    The new Publishing Service does in fact raise the same publish job events as the existing system. For example, the 'publish:end:remote' will still be raised as before, so any existing code shouldn't need to be changed - this was a very conscious design decision. It's the internal workings that have completely changed - i.e. the existing pipelines are used anymore.
    – Trevor Reeves
    Commented Oct 7, 2016 at 13:04
  • I was not referring to the begin and end events, was more referring to the other publish events that exist and the pipelines, when I said one has to revisit and make sure they consider when changing to the new publishing service.
    – Prasanth Nittala
    Commented Oct 7, 2016 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.