Be careful here - you are seriously changing the default behaviour of Tridion - the ability to republish all pages where a component is used by publishing the component is very useful for editors who may not know where a component is used, but want to make sure that it is up to date all over their website. Why is it that you do not want the pages to be ...
It sounds like your custom resolver is not working - you can check which items are going to be published by clicking the See Items to Publish button on the bottom left of the publish popup - if your resolver is working this will only show the one component. If you want to debug your resolver, then attach to the publisher process (TcmPublisher.exe - I think) ...
I wrote a blogpost about this exact issue: http://albertromkes.com/2014/01/20/custom-resolvers-and-configuration/
In short: you have to load the Tridion.ContentManager.config file yourself from the configuration of the calling application (TcmServiceHost, Publisher, etc).
Judging by the tags you used, it looks like you already thought about using a custom resolver for this. Have you actually tried using one?
I would normally handle this with a custom resolver, but the event system approach should have worked anyway, maybe there's something else going on there.
There's plenty of examples on custom resolvers out there.
manifest.json file allows multiple extensions, so you could add resolvers for both Component and Page as separate entries.
manifest.json file with multiple extentions:
If those two Publications are Published to the same Target, then you could use a Custom Resolver, if the Targets are different for those Publications, then I think you can only accomplish it through the Event System.
The benefits of using the Event System will be visibility, you add an additional Publish Transaction which shows up in the Publish Queue.
5.3 Event Systems are written in COM+/VB6 (or COM-visible .NET assemblies)
The COM+ Event System has been deprecated in Tridion 2011
You are likely to upgrade to 2011 or 2013 rather than 2009 on your next system upgrade
Custom resolvers haven't changed that much since 5.3 and are written with TOM.NET
My preferred option would be to use a Custom ...
This issue is addressed with hotfix CME_2013.1.0.87280 available here: https://www.sdltridionworld.com/downloads/hotfixes/SDL_Tridion_2013_SP1/index.aspx (login required, or contact Production Support).
A word of caution: we were about to build a Custom Resolver to address this having custom logic to pull the needed linked components in. However, this ...
If I understood your requirement correctly, while publishing the binaries dynamically, you want to avoid the dependent items to go to publishing.
So if you want to achieve it using custom resolver. One point to mention here is: In case you have multiple publishers, deploy the custom resolver to all your publishing servers as explained here.
I am sharing a ...
Yes. Here you go:
public void Resolve(IdentifiableObject item, ResolveInstruction instruction, PublishContext context, col.ISet<ResolvedItem> resolvedItems)
//... do your logic
Page p = item as Page;
bool isPublishedToCurrentTarget = PublishEngine.IsPublished(p, context.PublicationTarget);
//... do more of ...
Another, less technical, option is to publish from a Blueprint parent and then choose to publish all children. This assumes that:
1. You have a Blueprint parent that contains the Pages / Components to be published
2. Publishing to child Publications will not publish to other non-desired Publications
If you were using Tridion 2011 (I know you're not ...
On your first question I'm unsure, a resolver is called on publishing, but I'm unaware if a resolver is also called by the Session Preview/Fast Track Publishing indeed. That would be worth a test I'd say.
However your second question I can confirm, once you edit your DCP in XPM, its changes will already be published automatically once you check the ...
As a new answer to an old question, SDL Tridion Sites 9.1 added the ability to create and read custom configuration files as part of one or more extensions as part of the add-ons feature.
See how to create a custom Add-on configuration file.
Specifically for this question, the "Schema Titles" could be added to the specified JSON to be read and used with ...
Per my knowledge, this is the default behaviour that Tridion provides. You can write custom codes to achieve what you want. Below are few option in the order of their recommendations
Option 1: Write a Custom Resolver - You can get fair idea of custom resolver on the internet and one good link is here
Option 2: Tweaking through Event System on the Un-...
Using a custom resolver for this is quite likely to be the wrong approach. One very common reason for wanting not to resolve component links is that the resolving query is one of the heaviest database queries, so if there is no functional need for component link resolving, the system will run better without it. Unfortunately, the custom resolver technique ...
If your question is how to publish additional items together with your item, then, just like everything else in Tridion, you have multiple options, where choosing one depends on your implementation, preferences, maintenance capability etc.
So how you can achieve this:
As you and Bart stated, yes, you can use a Custom Resolver to add
items during publishing. ...
Those DLLs are indeed in the Content Manager Server GAC I doubt they are in your local computer GAC. Please note that since you are using a new version of Tridion you will need to use new DLLs versions. If you want to test it in your local machine you should copy the new dlls and reference them.
You should copy them from [TRIDION_HOME]\bin\client
You need to disable link propagation, so no components that are using this component will be republished.
You control that using the Event System before the publishing.
For 2011 you have to do call to a method that implements that
Example: When you initialize the Event
private void InitializeEvent()
Honestly, don't know, why do you need it (if you want save key/value pairs you can do it without Tridion configuration handlers).
But if you really want it, I've made fast example.
For next xml:
You need to have something next:
A simple solution, though not one which may satisfy all your requirements, is to copy PageA as PageB, change it's template to PageTemplateB and publish it. If you can determine some rules for when a PageA should have a matching PageB then you can automate the creation using an Event Handler and the publishing using either an Event Handler or a Custom ...
I would keep using your existing resolver and use ApplicationData (on the transaction) to store the options chosen in the UI. The resolver can then read the app data and decide whether or not to remove the child Structure Groups from the transaction.
A Custom Resolver is for customizing the resolving, this includes adding and removing items indeed.
Personally I think it is more clear when you are adding items in a custom resolver, than removing them. But I have built both types of resolvers and if you make sure the customer understands that there is a custom resolver in play and what it does, it should ...
You can implement a Event System to measure some of the parameters like RenderTime.
Second thing, the ScheduledForPublish, WaitingForPublish, ScheduledForDeployment, WaitingForDeployment, Resolving, Rendering are various states of a Publish Transaction.
So hook up into and handle the state change events ( Use the SaveEventArgs, SetPublishStateEventArgs ...
The easiest way to get a rough idea of these times is to double click on the publish transaction in the publishing queue. That will bring you to a view like this:
As you can see, there is a start and finish time listed for each stage of publishing, down to the second. Often times this is enough to find publishing bottlenecks if they're on the scale of ...
Your case is standard Tridion behavior with one exception: normally Tridion will publish the dynamic component presentation every time you publish the page. If I understand you correctly, your requirement is to ONLY publish the DCP if it is not published.
I would recommend to publish the page normally, and create a custom resolver which removes the DCP from ...
It's standard Tridion behaviour that a default publish action only re-publishes (i.e. doesn't publish items that aren't yet published) Well, obviously, the item itself will get published, but not the other items found during resolving.
I'm not sure what you mean by "dynamic components associated with a page". If they are in component presentations on the ...
On the subject of whether resolvers are triggered: the answer is No. From the online docs [login required]:
When Experience Manager users add or modify content, Experience
Manager uses a different mechanism than regular publishing to update
the content on the staging Web site.
This mechanism is called Session Preview. For performance optimization
You can handle disabling Linking Propagation when un-publish.
Check the following link to get an idea of the code you have to put in place in case you choose the Event System option (In your case you have to handle that in the un-publish events instead than in the publish events)
I don't want to publish any related components when publishing a component