Idea Delivered

Republish in the Publishing Queue is available as of SDL Tridion Sites 9.1. Thank you for the idea and feedback!

Republish option in Publish Queue

How about a "Republish" or "Redo" option on the publish queue items? Sometimes a transaction fails (and get fixed in the background) which require republish. Currently you have to locate the page or sg again in the tree, and then click on the publish dialog. Then reselect all the publish properties, and hit publish. It will save a lot of click if you can simply right click on the item in the publish queue and select republish.

Note: this was the most voted for idea on the former SDL Tridion Ideas site (submitted by Hendrik Tredoux); it got 32 votes there.

This functionality has been made available as an extension already:

If you think that providing this functionality Out Of The Box adds a lot of value: vote for this idea (and let us know why).

Parents
  • So the current thinking is this enhancement request is specifically about a republish or redo option in the publishing queue with no user interaction.

    I see the other two use cases as useful, though separate ideas:

    1. Publish from the publishing queue would be for the ability to change options before submitting a new publish (or perhaps unpublish) action.
    2. Re-try publish would be a new kind of scheduling option to keep trying a give request.

    Ideally we'd tackle both this request and #1 in a single change, though it might be impossible to "reconstruct" and pre-populate the original request without a bit of changes. For example, changing resolving options such as including children Publications in a publishing request will create separate transactions.

Comment
  • So the current thinking is this enhancement request is specifically about a republish or redo option in the publishing queue with no user interaction.

    I see the other two use cases as useful, though separate ideas:

    1. Publish from the publishing queue would be for the ability to change options before submitting a new publish (or perhaps unpublish) action.
    2. Re-try publish would be a new kind of scheduling option to keep trying a give request.

    Ideally we'd tackle both this request and #1 in a single change, though it might be impossible to "reconstruct" and pre-populate the original request without a bit of changes. For example, changing resolving options such as including children Publications in a publishing request will create separate transactions.

Children
  • What's the main reason for deviating from the functionality that is already implemented in the 'Republish from Publish Queue' GUI Extension (linked to from the Idea description above)? Surely this is the functionality that is known and loved by the community, so why change it? Is it the level of effort required or the complications described below (figuring out permissions, etc.) or some other reason(s)?