2014-03-11 Update: The just released Sitecore 7.2 has implemented all these features into the product, so this blog post is only valid for 7.1 and below. Thank you Sitecore!

The Sitecore publishing dialog has some flaws that I finally got the chance to fix.

Here is a screenshot of the original publishing dialog from one of our Sitecore setups. The most obvious error you’ll find in the standard dialog is that the list of languages is unsorted. Another strange thing is that the list of languages is filtered on read access for each language. So, if I have read access on the language item (not even LanguageRead), I may publish any items on that language. Eh? When will I ever need to publish items that I can’t edit in the first place? I think LanguageWrite is a more suitable permission.

Another thing that can become an issue, is that anyone can do a complete Re-publish of everything. This shouldn’t ever be done really, unless you have a corrupt database. With a growing database, a Re-publish can have great performance impact. I guess Republish access is only needed for Administrators in most setups.

Publishing targets is also an issue. More of that below.

Solution
Note: This solution is only tested for Sitecore 6.6 rev 130214. Other versions of Sitecore may have different code in the publishing dialog, so this solution may need some adaptions.

In order to correct the publishing dialog, we’ll have to alter the Sitecore shell dialog xml and let it utilize a custom class. Edit the dialog xml file located in /sitecore/shell/Applications/Dialogs/Publish/Publish.xml. The only thing we need to change in this file is the CodeBeside attribute in the WizardForm tag, like this:

<?xml version="1.0" encoding="utf-8" ?>
<control xmlns:def="Definition" xmlns="http://schemas.sitecore.net/Visual-Studio-Intellisense">
  <Publish>
    <WizardForm CodeBeside="SitecorePatch.PublishDialog.PublishForm, SitecorePatch.PublishDialog">
...

Then we need a modified PublishForm implementation. Unfortunately the Sitecore PublishForm class is almost sealed and cannot be overridden to solve this. So we’ll have to implement our own. This is a rather big and complex class, so I’ve started with a copy of the disassembled source code of the original class. I used Jetbrains dotPeek. It’s a great and free tool. Try it if you haven’t!

The changes I’ve done to this class are mainly the following:

• CanPublishLanguage property added
• HasRepublishAccess property added
• BuildLanguages method checks the CanPublishLanguage property and sorts the resulting list
• OnLoad method checks the Republish Access

The RePublish access is implemented as an optional Sitecore role. If there is a role named “RePublish” present in the system, the user must be a member that role to do a Re-publish. If the RePublish role is missing, the behaviour is unchanged from Sitecore default (i.e everyone have access).

You can download the complete source code here: SitecorePublishingDialog

Multiple Content Delivery servers
The last thing worth doing if you have more than one CD server, and leverage from multiple publishing targets, is to configure those targets as well. This can be done out of the box in Sitecore. Using the DefaultPublishingTargets setting, you can enter a list of pipe separated targets (type the Key value of each target item – not the “Target database” value). Those will then be pre-selected in the publishing dialog.

If you have more than one Publishing Target, Sitecore will require write access to the targets. So if you have two CD’s, CD01 and CD02, it’s important that those databases don’t go out of sync. This means you can set DefaultPublishingTargets to cd01|cd02 (or your equivalent) and remove write access to the targets. This will make the targets selected in the publishing dialog and the checkboxes will be greyed out, so the users cannot deselect them.

Tip: Since the DefaultPublishingTargets setting is a bit ambiguous, rename the Publishing Target items to your target database names, so it corresponds to its Target database field value. Then set Display Name to a user friendly name. This will make your config files a bit more uniformed.

Here is an example of the expected result:

As you can see, the “Republish Everything” radio button is grayed out, the Language list is sorted and limited to the ones that the user has write access to, and the Publishing Targets checkboxes are both checked and greyed out.

@Sitecore: Please bundle this, or equivalent, in future releases of Sitecore. Thanks!