Idea Delivered

The idea was delivered as part of Tridion Sites 9.6 release

Publish Folders

Publish all Components in a folder, by publishing "the folder". Also publishing the Components in subfolders.

The flow should be something like:

  1. User right clicks a folder and selects publish
  2. TCM gets all components that can be published dynamically and puts them in the publishing queue.
  3. Components are published.

Note: this is an idea from the former SDL Tridion Ideas site (submitted by Wouter van Vegchel); it got 16 votes there.

Rick Pannekoek
Parents

  • Publishing a folder does indeed make sense. I would generally suggest that creating one big publish transaction is not what's wanted. In most reasonably large sites, if you published the root structure group, you'd probably break something. Common approaches usually involve deliberately breaking publish actions down to a smaller granularity. This gives you firstly some resilience against failures: you can republish only the things that failed. Secondly, assuming a finite amount of render threads, by publishing a lot of large SGs, you can easily tie up all your available threads for several minutes at a time, which means you won't be able to get your small-but-important job to publish straight away, even with high prio. In general, I have my doubts about the usefulness of large transactions. There may once have been a theoretical possibility of transactional deployment of an entire site, but in practice this isn't a high priority for many people. My suggestion would be to make all publish actions on containers default to queuing the contents as individual items. Actually - I'm going to go and add an idea just for that.

Comment

  • Publishing a folder does indeed make sense. I would generally suggest that creating one big publish transaction is not what's wanted. In most reasonably large sites, if you published the root structure group, you'd probably break something. Common approaches usually involve deliberately breaking publish actions down to a smaller granularity. This gives you firstly some resilience against failures: you can republish only the things that failed. Secondly, assuming a finite amount of render threads, by publishing a lot of large SGs, you can easily tie up all your available threads for several minutes at a time, which means you won't be able to get your small-but-important job to publish straight away, even with high prio. In general, I have my doubts about the usefulness of large transactions. There may once have been a theoretical possibility of transactional deployment of an entire site, but in practice this isn't a high priority for many people. My suggestion would be to make all publish actions on containers default to queuing the contents as individual items. Actually - I'm going to go and add an idea just for that.

Children
No Data