We have a Component - attached to a Dynamic Component and want to publish it for content changes.

We have this same Component in a container which we use to control the order of the Components in this particular view (it can't be meta on the Component as it's used in different containers / in different orders).

The Container is a Component Presentation on more than one page.

So, the intention is

  • publish page(2) = changed order
  • publish DCP = changed content

This model allows the editorial team to continue updating content when a page is locked (say because a disclosure is being check and the intro isn't signed off).

Now technically this is working correctly in that when we publish with the DCP all the pages are published alongside the DCP itself.

I figure

  • a custom resolver could catch the DCP and stop the page publish
  • or we could remove the Container CP from the pages and have the page grab and render the necessary (java tag with a 'order array') rather it than being manually linked

The custom resolver would require code releases (multiple) with changes as we add more items to this pattern (although we may be able to abstract out a generic solution)

The removal of a CP will upset editors as they, rightly, Where Used.

Am I making it up or did there used to be a setting that would allow the depth of a component publish to a page to be limited ... e.g. if you don't find me directly on a CP then don't look any further?

If I am making it up ... any thoughts on other strategies for this challenge?

3 Answers 3


We went with the custom resolver. The client requirements are such that they publish from a very controlled process and always at a Page level. The idea here is to have certain marketing material availble for update even when pages are 'locked' from publishing.

We've added the following - and caught the specific content type we're interested in:

        string[] lookupSchemas = { "SchemaNameHere" };

        if (item is Component)
            Component comp1 = (Component)item;
            if (lookupSchemas.Contains(comp1.Schema.Title))
                List<ResolvedItem> tempItems = new List<ResolvedItem>();
                foreach (var resolvedItem in resolvedItems)
                    if (resolvedItem.Item is Component)
                        Component compResolved = (Component)resolvedItem.Item;
                        if (compResolved.ComponentType == ComponentType.Multimedia || resolvedItem.Item.Id == item.Id)
                foreach (ResolvedItem tempResolvedItem in tempItems)


This said, the client does not want to publish from Components in general and does not envisage this changing in the foreseeable future. We could be safe to catch publishing from any component and take pages out of the instruction (but as you never know what the future holds I prefer to control it all the same).


If I understand it correctly, your Pages get resolved because of (default) Component Link resolving: normally if you publish a Component, it won't resolve Pages containing that Component as DCP (because the CP is stand-alone). However, in your case Component Link resolving kicks it: your Container Component links to the Component you're publishing and hence the Container Component gets resolved and the Container Component is on Pages as embedded CP so finally those Pages get resolved.

Component Link resolving can be switched off in the ResolveInstruction; something you could do in a Publish event handler.

  • The ResolveInstruction certainly sounds like something I'd not yet considered so I'll take a look into this shortly - I am wondering if this will still work in the context of the DCP existing with standard Components in a Folder / Bundle etc. ... more reading to be done - thanks Rick! Commented Oct 2, 2015 at 5:37
  • Modifying the publish/resolve instruction in a publish event will indeed only work if the Component is published directly. If it gets resolved (for example because a Bundle is published), you will only get a publish event for the Bundle. You could disable Component Link resolving in general, but may be too coarse-grained. Commented Oct 2, 2015 at 9:15

I don't recall such a setting. Are you thinking of the setting which limits circular references instead perhaps?

A custom resolver would be my recommendation here, as you have suggested. You could possibly make it quite generic and avoid multiple releases if you took an approach where resolved pages are removed if the published item was a component. Doing so would mean that your users would always have to publish pages for embedded content though - they couldn't publish the embedded component itself, as the publish job would resolve to nothing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.