Steps to reproduce

a] Publish a recursively huge subtree with just a few modified items
b] Publish recursively folder with too many children 
c] Publish a large amount of nodes that were preselected at the same level

Expected results (ideas)

let the user know that publishing too many nodes can cause freezing the screen and performance issues / slowing down of app and provide the possibility to avoid too big publishing load

Proposals

a] in case of publishing big amount of nodes in recursive mode (publishing including sub-nodes) -  User is offered a dialog where he sees the publication options like in the screen below ( "Modified items (number) vs "Bulk (utilizing itemsPerRequest)") so he can pick the most reasonable one. The recommended one might be preselected.

For operation: Publish Inc. subpages adapt the dialog so the user can access all necessary information while selecting one of the options. This problem occurs only with big-size projects so make sure to make this functionality available not by default but by enabling it via definition.

Help tips:

• Modified only - By selecting this option, you will publish only modified content

• Publish all: 31 items - By selecting this option, you will re-publish all content regardless of status. This can cause the service to slow down temporarily (not recommended).

• Publish all: in 3 larger batches - By selecting this option, you will re-publish all content regardless of status. All changes will be packed in batches to reduce the publishing load

Actual results

User is not warned in case of

• publishing huge amount of items
• publishing unmodified items

Workaround

• Configure itemsPerRequest
• Set orderSiblings to false

Development notes