9

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


8

Try to load page after instantiating it: page.Load(LoadFlags.None); Your page object has only TCM URI pre-loaded and TCM doesn't force its reload to get title.


7

You can copy all Tridion.* dlls, from <tridion>/bin/client on the server to your local machine


7

manifest.json file allows multiple extensions, so you could add resolvers for both Component and Page as separate entries. For example: manifest.json file with multiple extentions: "extensions": [ { "type": "CMResolver", "name": "AssetUnpublish", "...


6

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


6

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


5

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


5

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


5

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


5

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


5

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


4

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


4

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: <My.Tridion.CustomResolving> <Keys> <add key="title" </Keys> </My.Tridion.CustomResolving> You need to have something next: public ...


4

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


4

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.


4

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


3

Since you are updating component after publish with datetime, I assume that you need that information on content management side and not on delivery side. If the above assumption is correct then the question why are you storing it as part of component? There could be two alternatives to store these data: Create another component with key / value pair ...


3

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


3

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


3

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


3

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


3

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


3

In a scaled out deployment, the publisher service typically runs on a different server than the CME. If you installed/configured your custom resolver on the CME server, but not on the publisher server, the resolver will only kick in when you press the “Show items to publish” button, but not when actually publishing.


2

While the answers from @Will and @Eric are correct, I just wanted to add that there is no specific need to recompile your 2011 based Custom Resover in order to use it on 2013. If you still have the 2011 compiled assembly (DLL) of your Custom Resolver you can use that directly on your 2013 machine. Once you start making changes, then it is advised to compile ...


2

After some more debugging, we found the problem. Actually, there was a bug in our code which was fixed some time ago, but the resolver dll was not yet updated on the CM server. The bug was in this line ComponentTemplate template = context.Session.GetObject(new TcmUri(<TCMURI>)) as ComponentTemplate; the tcm uri was not the uri of a component ...


2

How are you loading and storing the configuration? It might help to have a static configuration class, which loads the config the first time it is accessed and then 'caches' it for the application lifetime. To be honest though, I am not sure what the application lifetime is in this case - I would hope that its related to the publisher service process, and ...


2

It's not possible. The resolver doesn't know/care about the concept of Publish Transactions. To elaborate on this, the method signature Resolve has 4 parameters, none of which you can use to somehow trace back the ID you are searching for. Also, take the following scenario for example, when in the Publish dialog you click Show items to publish the resolver ...


2

With a powershell script running against the core service, you can extract the data like this: import-module Tridion-CoreService $core = Get-TridionCoreServiceClient filter PubTransToObjects (){ $returnValue = new-object -TypeName PSObject $transportSummary = ([xml]$_.Information).TransportSummary $prepareTransport = (Select-Xml -Xml $...


2

Like Rick asked in the comment, it depends on what you want to achieve... If you use a Custom Resolver, you will always end up with Publish Transactions, even if you remove all the items from the resolved items list. Such Transactions will have a Warning state (that lets you know that something is fishy about them). On the other hand if you use an Event ...


2

Clicking the Show items to publish button in the publish dialog will trigger all the related resolvers and show you the list of resolved items. The same thing (triggering of all the resolvers) happens in the resolving state of a Publish Transaction, by default. Hypothetically, the only way this can behave differently is if you programmatically check whether ...


Only top voted, non community-wiki answers of a minimum length are eligible