RootItem will be null when you do Publish Site

Challenge:

We’ve built one application which shows us the status of our publishing process. But sometime it was throwing “Object reference not set to an instance of an object” error. We checked the code. But in code there were so many lines which can cause this error. We decided to put individual exception blocks. But while doing this process we found the steps to reproduce it and it helped us to find what was NULL

Solution:

Basically we were using RootItem

//Gets Root Item Name
string rootItemName = ((Sitecore.Publishing.PublishOptions[])(job.Options.Parameters[0]))[0].RootItem.Paths.Path;

And when we do “Publish Site” [Shortcut is F9] at that time RootItem was null.

So, to fix it we checked whether RootItem is null or not and it fixed our problem!

So, In short When you do “Publish Item” you will get RootItem object else in “Publish Site” case you won’t.

Happy Publishing! 🙂

 

Render file in browser rather than showing OpenSaveDialog

Challenge:

One of my friend asked me that he is requesting XML file which has been uploaded in Sitecore using javascript for fetching XML content. But it fails as when he hits that XML URL directly in browser it shows OpenSave Dialog box of browser. Which he wanted to disable.

Solution:

Basically, This is being manged using Web.Config’s MediaType configuration here  <forceDownload>true tag plays a vital role in deciding whether to render or show open save dialog for request media item.If forceDownload is true then it will show OpenSave dialog else it won’t! — Easy right?

Sitecore says :

A true value for the forceDownload element causes Sitecore to apply an HTTP “Content-
Disposition = attachment; filename=” header when linking to the .ashx URL of the media item,
causing the browser to prompt the user to open/save as rather than opening the resource in the
browser.

So, Open you web.config file and find mediaType for your desired extension on which you would like to disable ForceDownload [In this case it’s XML] and set forceDownload to false.

<mediaType name="XML document" extensions="xml">
<mimeType>text/xml</mimeType>
<forceDownload>false</forceDownload>
system/media/unversioned/xml
system/media/versioned/xml
<thumbnails>
<generator type="Sitecore.Resources.Media.MediaThumbnailGenerator, Sitecore.Kernel">
<extension>png</extension>
</generator>
/sitecore/shell/Themes/standard/images/xml.png
</thumbnails>
</mediaType>

Just a note : Browser should also have proper plugin to render the requested media file. E.g. If you set forceDownload false for PDF files than PDF plugin should be there in your browser.

Worth to read : http://sdn.sitecore.net/upload/sdn/articles/media/sitecore-media-facilities.pdf#search=%22Forcedownload%22

Happy Media serving! 🙂

All About the Sitecore ASP.NET CMS Series by John West

While reading on web, I cam across with nice blog series by John West. It’s available here: http://www.sitecore.net/en/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/05/All-About-the-Sitecore-ASPNET-CMS.aspx

Happy Sitecoring!

Is your Sitecore publishing stucks?

Challenge:

On web and in person I’ve read and faced so many issues on publishing stuck scenario with Sitecore and most of them got resolved by doing Application Pool Recycling Or restarting IIS. But I’ve never read/found its root cause.

We were also facing lots of publishing stuck issues and we were also following the same approach what others were following [IISRestart] which was causing us a lot of man hours lost, clients unhappiness, Content Authors unhappiness etc. So, we decided to find the root cause of this issue and fix it permanently! [My learning — The best method to fix any issue/bug permanently is to first find the root cause [I know it’s not easy] and then find the fix for it, else you will be doing same thing for days and years :)]

So, if you are also facing Publishing Stuck issue this article is for you!

Solution:

Is your sitecore publishing stucks? Before I explain our problem. It would be great to check basic things first which are as below:

1. Check network speed\firewall\antivirus is everything looks fine?

2. If your Sitecore items are huge and If your CAs are using Publish Site [Shortcut F9]. This may also cause an issue for slow publishing.

3. Check Stager/Staging Module files [If your Sitecore version < 6.3].

Basically Stager or Staging module creates files on your CM environment which tells your CD environment to clear cache. Sometimes your Stager/Staging module does not clear this files and due to lots of Files the I/O operation takes time and your publishing stucks.

Below all steps applies to Sitecore Version >= 6.3

4 . Check EventQueue configuration.

5. Disable your WebDeploy, and check does your publishing works fine? If yes then you need to check your WebDeploy.

6. If you are using Sitecore CMS 6.3.0 rev.101029 (Update-3)  with publishing Instance and if your publishing is showing “Initializing” then you need to upgrade to Sitecore CMS 6.3.1 rev.110112 (Initial Release).

Publishing

• [Backported from 6.4.1] Publishing jobs would not be executed if the publish operation was initiated after a restart of the Sitecore Publishing instance or while it was down. The publish dialog would display “Initializing…” and never show any progress. (336232, 336668)

7. have you added any hook on publish:begin, publish:end, publish:end:remote? If yes check its code or to quickly verify that they are creating an  issue or not try disabling  them one by one. And if they seems to be creating an issue then check its code.

Okay, you’ve checked all above basic things, and still publishing stucks? [Which happened with us :)]. Then check things as mentioned below:

Do you have two publishing targets? if yes then Publishing stucks on second target? Does your Sitecore log file shows following pattern in log file? [We just selected Job Started entries for each item in following log snippet]

    Line 22533: ManagedPoolThread #10 13:27:46 INFO  Job started: Publish to ‘web1’
    Line 22721: ManagedPoolThread #16 13:32:34 INFO  Job started: Publish to ‘web2’
    Line 22725: ManagedPoolThread #16 13:32:35 INFO  Job started: Publish to ‘web1’
    Line 22729: ManagedPoolThread #16 13:32:35 INFO  Job started: Publish to ‘web2’
    Line 22734: ManagedPoolThread #16 13:32:36 INFO  Job started: Publish to ‘web1’
    Line 22992: ManagedPoolThread #16 13:38:12 INFO  Job started: Publish to ‘web2’
    Line 23002: ManagedPoolThread #16 13:38:13 INFO  Job started: Publish to ‘web1’
    Line 23447: ManagedPoolThread #16 13:48:32 INFO  Job started: Publish to ‘web2’
    Line 23705: ManagedPoolThread #16 13:56:38 INFO  Job started: Publish to ‘web1’

Here there is no entry for Job started: Publish to web2′ It means that system has completed “ Job started: Publish to ‘web1′” and after that before startingPublish to ‘web2’ it got stuck somewhere.

If answer is yes then below steps contains its solution, steps to reproduce it, and reason why it occurs! Wow! Sounds interesting! then let’s go..

We raised Sitecore Support ticket for the same and I should say big thanks to geniuses at Sitecore Support for providing us a hint on its problem and solution — Especially Sergey Kuts

Reason:

Our Sitecore instance was running out of thread, so it doesn’t have thread to run another publishing operation.
By default Sitecore has 20 threads in thread pool. According to our log file we have

ManagedPoolThread #XX where XX is from 0 to 19, so it is quite possible that all threads are in use. [Open your log file and check this out!]

Reproduce:

Above reason sounded logical to us. But it was theoretical and we wanted to check our theory, before we fix the issue. [Basically, we are engineers for whom E=MC² also need to be proved :)].

To reproduce the scenario we created one ASPX page in our Sitecore Instance which takes Number of Jobs to run as an input in text box and based on that input. It will Start that number of Jobs.

If you are new to Sitecore Jobs, then no worries check my earlier article here.

So, in our Job’s method we written some code which will run for long period of time [Technically iterating through /sitecore/ item recursively]. So, it will occupy the thread for long period of time.

Then we kept big items for publish with two publishing targets [Web1 and Web2]. And as it is a huge publishing  it takes sometime to publish in the mean time we used our ASPX page to create 19 Jobs. So, Now our threadpool is full.  [Currently 20 jobs are running – One Publish Job and  19 custom created jobs.]

Our publishing process completes publishing on first publish target [Web1], and the moment it starts publishing on another publishing target [web2] it get stucks [So, we conclude from this is that One Publish target creates one thread to execute itself].

And yes, we successfully reproduced the issue. [Have you!]

Okay, I am sure you are eager to see its solution. Let’s move on to it.

Solution:

Sitecore guys suggested us to try  to increase available threads to at least 100 and see if it helps.  It can be done by adding the following setting to the <settings> section in the web.config

<setting name="MaxWorkerThreads" value="100"/>

Just a note : as it is config change it will restart IIS

And after this change we tried to reproduce it again. And we can’t — That’s what we wanted to do! 🙂

Finally, sorry for such a long post. But I hope you found it useful!

UPDATE : 02/June/2014:

We were facing an error — Where publishing dialog will say — Initializing forever — And to resolve it we have to recycle app pool. After spending lot of hours we found that our SQL Server and Web Server’s timings were not in sync. Syncing them fixed our issue. Give it a try, it might work for you as well!

Good read:

http://sdn.sitecore.net/SDN5/Forum/ShowPost.aspx?PostID=59795

Happy Smooth Publishing! 🙂

Basics of Sitecore publishing modes

Challenge:

So less guys knows the real purpose of incremental/smart/full publish mode which Sitecore provides. People just keep using whatever they feel to. But Sitecore guys has designed the modes logically and each has its different purpose. Which we will discuss in this blog post.

Solution:

Before we move on to publish mode basics, let’s clear publishing basics first:

By default, when content is modified, it must be published before it will appear on the Live Web site. Content is edited in the Master database (which contains ―work in progress) while Sitecore generates requested Web pages using content in the Web data (which contains ―live content). Publishing copies the latest ―publishable version of ―publishable items from the Master database to one or more publishing target databases, by default the Web database.

Incremental	Smart	Full
You may publish individual items, a list items which are known to have changed.	cycle through the entire database to publish items that Sitecore can detect have changed	cycle through the entire database and publish all publishable content regardless of whether it has changed or not
Incremental publishing publishes all the items in the publishing queue, which is the list of items known to have been modified.	Smart publishing starts at the root item and iterates through the content tree comparing the item revision fields stored in the Master database and the selected publishing targets. Publishable items that have revision fields which do not match are copied from the Master database to the publishing targets. Smart publishing automatically removes items in the Web database which are no longer publishable.	Republishing overwrites the entire contents of the target database with the publishable items in the master database. Republishing is the most expensive type of publishing, because it must perform a write operation for all items, and write operations are more expensive than read operations.
Incremental publishing is the quickest publishing option and requires the fewest resources of the three options which publish the entire site.	Smart publishing takes longer and requires more resources than incremental publishing.	Because of the expense, you should only use republish when the databases appear to be in an inconsistent state, for example, after a publishing operation has failed due to a network outage.
Dbo.PublishQueue Table is used.	Revisions from dbo.VersionedFields will be compared (revisions are determined by FieldID).	NA