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).

Rick Pannekoek
  • in reply to Alvin Reyes

    Yes, we just use the normal 'Republish from Publish Queue' GUI Extension that has been knocking around the Community for a while now, so that opens the Publishing Dialogue window.

    Tbh, the client likes and uses this functionality, so if you only add a 'Redo publish' then I'm probably going to have to install this GUI Extension again. :(

  • Some additional questions where we're looking for some context from the community.

    1. Should the ability to “republish” via a context menu to resubmit a Publish transaction (with no dialogue), be restricted to the same user that submitted the original (i.e. previous) Publish transaction?
    2. Should this republish context menu option be available for both failed and successful transactions? In other words is this only for republishing failed items?
    3. Finally, what's the expectation for a transaction with scheduling options to:
      1. Publish at a later date
      2. Unpublish at a given time

    Would a "republish" even be avaialble on scheduled transactions, or might "redo" attempt to somehow replace scheduled transactions?

    I suspect limiting the option to failed requests simplifies exactly when the republish option should be available.

  • in reply to Jun Sasaki

    Thanks for the example. Would this kind of idea mean an item would keep retrying or just retry just once (assuming a failure)?

    I see this as a separate idea; could you or someone else submit a different "keep trying" idea if this is interesting to others?

  • in reply to Jonathan Williams

    If we only implement "redo" or "republish," would you still be interested in a separate "publish" option that opens the form dialogue? Does the/your GUI extension open a dialogue? Could you submit a separate idea for this editorial feature?

  • 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.