After showing you how you can navigate efficiently in Sitecore, let us now check out the publishing mechanism and its gotchas.
As usual, this blog post is available in German and English to help as many people as possible.
Enough talk, let’s jump in!
Publishing basics
Before we actually dive deeper into publishing, lets recover some of Sitecores basic concepts. Sitecore uses 2 datasources to store the content for your website, called databases. Master contains all of the content, while Web is a stripped subset of that data, namely the content that is currently live. Publishing in this sense is an update of the Web database with data from Master.
What’s going on, eh?
Considering the publishing concept, wouldn’t it be nice to be able to check what is actually in the Web database(=live)? You can actually do this by switching the content database to Web in the Desktop.
In the lower right corner, you see a database symbol, click on it to see the available databases. Click Web to change to the Web database (the currently published data).
You probably won’t see much of a difference, but this is due to the fact that these databases tend to be very similar in terms of structure. In my case, I can see from the Content Editor that the whole Habitat Site is not published.
Publishing in Sitecore
Let us look at the publishing dialog and publish the Habitat Site now. To do so, select the item and open the publishing dialog via Publish -> Publish -> Publish Item. Make sure to hit the text below the icon, otherwise you will see a simplified dialog.
You will see a dialog with quite some options, let’s see what they do.
- Smart publish
This is the one you want to use. Sitecore determines which items have changed by looking at their Revision. The revision changes every time an item is saved in the Content Editor. - Republish
Sitecore publishes all items independently of their revision. This should almost never be necessary, but is kind of a safe option in case something went wrong with the publishing. - Publish subitems
This is the single most important switch in this dialog. When checked, Sitecore does not only publish the current item, but all subitems recursively. - Publish related items
Now this is a tricky one. In Sitecore, you can publish items that have a dependency to other items, e.g. you can publish an item without publishing its template. When this Box is checked, Sitecore tries to resolve this by finding related items and publishing them as well. The downside is that you loose quite some control about what will actually be published. In a healthy environment, having this box checked should not pose a threat.
Publishing language
Select the Languages you want to publish. In most cases, all languages should be published.
Publishing Targets
In most Sitecore environments, there will be only one publishing target. In bigger organizations you might have Sitecore clusters or other environments you can choose from.
Let’s go!
Let’s publish the Habitat site smartly, including subitems & related items, and in all languages.
When the publishing has finished, you will see a summary of the process. Here is what these numbers mean.
- Items processed
Number of items that Sitecore considered during this publish - Items created
Number of items that did not exist in the Web database and were created - Items updated
Number of items that already existed in the Web database but had to be updated - Items skipped
Number of items that already existed in the Web database and did not change (=had the same revision)
If we publish the same items again, we can see the smart publish kicking in. In my case, no new items were created and almost 1200 were skipped. There were still almost 900 items updated. This is possibly due to some custom functionality in the Habitat solution which changes the revision at some point. If you see constantly more items being updated than expected, let your IT know. They might have added some customization that degrades publishing performance.
Change back to the Web database now, and you will see the new Items.
“With great power comes great responsibility”
Publishing is quite an expensive operation, so you should be aware of the implications.
- Only one publishing operation can run at a time. When another publish is running and you start yours, your job will be appended to the Publish Queue and you will see the status Queued. Your operation will start when all preceding publishes are finished.
- Publishing the whole site is probably the longest-running and most resource-intense operation that you can trigger. Your IT should remove this option from the Content Editor to avoid accidental site publish.
- In almost all cases, Sitecore will clear the cache of the website after a publishing operation. If your site relies heavily on caching, the performace will probably decrease significantly for a short timeframe.
Restricting publishing
In Sitecore, you can prevent publishing by changing Publishing Settings. Let us assume we want to remove the Habitat Site from the web, but keep it around for editing. We can achieve that by setting a publishing restriction on the habitat Site Root.
To do so, select the Habitat item and open the publishing settings dialog via Publish -> Change
The Publishing Settings Dialog has 3 tabs, where you can setup publishing restriction timeframes by version, by item and by target. For now, we want to make the Habitat item completely unpublishable, which we can set up in the Item Tab.
Do you see a warning label in your Quick Action Bar? If not, you might want to activate the Publishing Warnings ribbon in the quick action bar (Check out my first Content Editing Blog Post if you don’t know how).
If you now publish the Habitat Item, it is gone in the Web database again.
Preview
Sitecore provides a way to check what the website would look like if you would publish right now. You can start this mode via Publish -> Preview.
In this Preview mode, you you can not only see what the website would look now, but also what it would like at a any given point in future, as well as what it looked like in the past. Use the Date area in the Experience Ribbon to change the valid date.
Publishing Gotchas
I see a lot of content authors struggling with the Sitecore publishing, so I want to explain and demonstrate some of the publishing behaviours that are seemingly odd.
Gotcha 1: Unpublishable Items
You actually just saw one of the big gotchas. Making an Item unpublishable does not mean it will never be updated. It means it will be deleted during the next publish.
Gotcha 2: Item Names vs Item IDs
To demonstrate this gotcha, I created an item Test under the Habitat Home und published it. We can verify in the Web database that it exists.
In the Master database, we now delete this item and the recreate it via Insert, then publish. Any guesses how this will look in the Web database?
Why do we have the same item twice? Well… it turns out we don’t! We have two items that have the same name, which could be purely coincidental. Sitecore recognizes identical items by there Item ID, which means when two Item IDs are different, so are the items. Since Sitecore generates a new unique item ID upon creation of an item, we can now reconstruct what happened.
- We created an item Test with ID X
- We published the item with ID X
- We deleted the item with ID X
- We created an item Test with ID Y
- We published the item with ID Y
As you can see, we never let Item X know that it does not exist anymore in the Web Database. Items X and Y are totally unrelated. Follow these guidelines to prevent issues with names and IDs:
- If you accidentally delete an item, recover it from the Recycling bin instead of creating a new item.
- Before deleting an item, set its publishing settings to Unpublishable und publish. This deletes the item from the Web database.
- You can make a deleted item disappear by publishing the parent item with the Include subitems option.
Gotcha 3: Moving an Item
To demonstrate this gotcha, I uploaded a picture in the media library and published it. Needless to say it ended up in the Web database.
Next, I moved the picture to the subfolder Files and published it again.
When you check the Web database, you will see that the image only exists in the new location.
How is that possible when we never published the parent folder? It is pretty logical when you think about it, because the item cannot exist twice. So when you publish it somewhere it needs to diappear wherever it was before. The path of the item is actually an information within the item that changes upon publishing. Just keep that in Mind when moving around items.
Gotcha 4: Preview
The preview functionality seems super convenient, but it has its major gotcha: It only takes the Master database into account. To clarify the impact of this gotcha, consider the following scenario:
You want some content to disappear on January 1st 2019, so you change the publishing setting of the item to be publishable until 31st December 2018, 23:59. To make sure everything works, you confirm that the content disappears in the preview on this exact date. When you check the actual website on January 1st 2019 00:00, chances are high that the content is still there. The reason is that your Web database only gets updated during publishing; until then, the old content stays available.
So keep in mind that the preview is actually a snapshot of what the website would look like if it were just published on the given date. The same applies for previous dates: A certain state in the preview does not necessarily mean your live website looked exactly like that at the time.
That’s all folks
So much for Sitecore publishing and its gotchas, I hope you have a better understanding of the mechanisms now. Stay tuned for my next article about languages and versioning!
