It depends on whether you have the same Target Types for the child publication or not. If the Target Types are different in the child publications, then the one that you are selecting for unpublish in your current publication, it will not unpublish from the child publication. As long as the Target Types are same, it should work.
For each component
From the component determine the publication
For each publication target
From the publication target determine the publication bindings
If publication in publication bindings component can be published to this target (if not the component cannot be published to this target)
You can get the ...
So based on the fact that the deployer is able to deploy things to the Broker successfully, I'm guessing it does not have anything to do with the Broker DB connection.
I would check the Processor Modules in the /bin/config/cd_deployer_conf.xml file. Are there any "non-standard" ones such as Smart Target? If so, are those also properly configured (i.e. ...
When you call AddBinary() you are responsible for ensuring that the binary will have a unique location on the content delivery file system. If you are not specifying a structure group, then all your binaries will end up in the folder specified in the Images Path property of your publication. As the editors can upload images with duplicate filenames, this ...
The error you describe when publishing the CT will be evident in the log stacktrace. This is probably a "Request Entity Too Large" error, meaning that the number of Component Presentations that end up being rendered and sent to the Deployer based on the CT amounts to a bigger size than you have configured in your cd_deployer_conf.xml (default is 10 megs).
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 ...
If you are using normal Modular templating, the usual approach is to write a .NET TBB which you can put in your page template(s) and which uses some logic to read the 'Main' component on the page, extract the metadata from it and push it into the package to be written out in your Page Template Layout.
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:
On a related note to those of you that are using SmartTarget, this can also occur if your deployer is setup to publish to a WebService that is not running. A simple default setup of this WS might use Tomcat, so poke for an instance that might not be running. By default this service is called SmartTargetDeploymentWebService
Just want to add a comment, not related to how to render static a component template that is dinamic, but related to something that you should consider in your scenario.
As you handle the render at the page template level, in case that the component is published separately from the page, the page won't be published, as the component is using a dynamic ...
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 ...
Check following things in your smarttarget_conf.xml:
Deployer does have access to place the file at Fredhopper location which would be something similar to "C:\fredhopper\Indexer\data\fas-xml-incremental\catalog01" (should be defined at IndexeServer=>Deployment=>Location of your smarttarget_conf.xml on your deployer)
The error stack shows that deployer is ...
In your deployer Role, try updating the value to dotnet in following property
<Property Name="tcdl.target.language" Value="dotnet" /> in the cd_deployer_conf.xml file
Restart the deployer services and unpublish the page once and publish it again to see whether it helps to generate the tags<tcdl:ComponentPresentation type="dynamic" ComponentURI="...
First thing that you should try to figure out whether the issue is related to the publishing process or the code which is fetching the dynamic content from the Broker DB to display on the web pages.
You may try to check in the Broker DB whether the corresponding component have an entry over there (Please mind that you won't be able to see the actual content ...
A Dynamic Component Template is linked to a Schema (which forms the links to Components based on that Schema).
By default when you publish a Dynamic Component Presentation (either by publishing a Component using the linked Schema in the CT, or by publishing one of the Dynamic CTs), the Publish Resolver will add all available DCPs to the Publish Transaction.
After playing around with some options, what I ended up with is using the TemplatingRenderer's Render method. From the Page Template's design TBB, rather than calling RenderComponentPresentation for this specific Component Template, I pieced together the necessary ResolvedItem, PublishInstruction, PublicationTarget, RenderedItem, and RenderContext instances....
We solved this by dropping down the number of workers for the Deployer to three:
<Location Path=".../work" WindowSize="20" Workers="3" Cleanup="true" Interval="15s"/>
We think the server threads were being over worked according to the logs:
StorageManagerTransactionMonitor - Rolling back a stale transaction:
tcm:0-9818926-66560, transaction was ...
The error message points to an issue where the filename of the published binary (tcm:30-78675) is equal to the filename of an already published binary (tcm:30-78718) in the same location.
Location and filename of published binaries are determined by the AddBinary call in your Template. The error message also indicates that the existing binary is using the ...
As per the SDL Tridion design, this is out of the box behaviour that if you publish a Component using Dynamic Component Templates, the entire chain of linked components will get published; so out-of-box you can not prevent this behaviour. However, Tridion is quite rich in APIs and you can create a custom solution to do so by using any of the following ...
If you are quering from a local machine then it could be an issue with your license file.
Common issues are:
The license file can't be found
The license file doesn't contain a broker license
The license file is not valid for your machine
In all cases the broker will fall back to using its built-in ItemType mappings. In other words: it will only support ...
I've had the same issue before, I managed it in the same way you did, I just added <tcdl:ComponentPresentation type="Dynamic" />, I think you can continue doing it. What I did is to add a .NET TBB at the end in order to keep it as Embedded when it is in preview mode and Dynamic with it is in Publishing mode
Checking a little bit the source code ...
Is the component presentation stored in the broker database?
The code you are listing
will not be executed by the ComponentPresentationAssembler if the source is in the database; DCPs with ASP.Net server side code must be located on the filesystem for their code to be executed (in an SDL Tridion Content Delivery ...
Several thoughts here, may be something helpful:
Have you performed a where used on the Component in Tridion CMS to
identify any further information about it's Published use?
In the cd_deployer_conf.xml is there any custom module setup for
handling the unpublish of component presentations?
If you search the Broker Database (Items), are you able to see the
Connection Refused indicates that the Deployer is not able to connect to the database. This could be due to a bad connection string, a changed DB password, or the DB could be down.
The cd_core.log or cd_deployer.log will show a more specific reason.
ComponentPresentationBuilder: exception while deserializing into CP:
There is an error in XML document (2, 2).
happens on the rendering side of things and in my experience can be one of three things:
The generated output of the template is not XML at all, because something was not configured right on the template, eg. the proper DD4T was ...
There could be some special characters in your Component data which is causing this, to check just capture the package via setting Cleanup=false in cd_deployer_conf.configand validate XML
<Location Path="F:\tridion\environment\incoming" WindowSize="20" Workers="10" Cleanup="false" Interval="2s"/>
If the SI4T storage extension is working correctly then the index data would be removed from the content stored in the broker database. The fact that this index data is still in there indicates a problem with the storage extension. Perhaps your Elastic Search indexer implementation is causing an exception which does not prevent indexing, but stops the index ...
From the old forum, someone asked about the java.util.Map<java.lang.String,java.lang.String> renderingParameters parameter in ComponentPresentationAssembler's getContent().
Nuno Linhares suggested this might be optionally used by XSLT Component Templates (CT). CTs set to XML Document can store run-time XSLT which might use parameters like Publication ...