You should be able to add a pipeline element after the "Tridion-Commit-TX" pipeline and before the Cleanup Step, which then should act as a PostCommit. In XO, the same happens:
<!-- Add the following pipelines after the existing "Tridion-Commit-TX" pipelines -->
<Pipeline Id="Tridion-Process-PostCommit" Action="Deploy" Verb="Process">
The transport package format is undocumented, and not a valid extension point - therefore I doubt you'll find much information publicly.
However... it's really easy to figure this out, as all you need is a copy of a few Transport Packages and the ability to unzip files. You can easily configure your deployer to keep copies of the successful transport ...
The documentation contains example code and the developer who wrote it was probabaly trying to be funny by including an import to an imaginary Java package:
The line is just there to indicate that you can also import any third party package you might need in your custom Content Deployer Modules. The code is purely ...
Well, this wouldn't be Tridion if there weren't 15 ways of doing it. My preferred approach for this - given that you already have the sitemap logic built into CM Templates - would be to use a Custom Resolver.
While functionally it can achieve the same as an Event, the reason why I would choose this approach is that it would allow you to add the navigation ...
Unless you have specific requirements and constraints for when "EMERGENCY" publishing is allowed, I would recommend removing the daily publishing constraint, which sounds like a technical or architectural constraint rather than a business requirement.
You'll have a bit of extra work to prevent editors from always choosing Live given two options:
Firstly, using page/component name for cache invalidation is not a very solid approach, as this is not guaranteed to be unique so you will most likely get some undesired results should different editors create pages or components with the same name. You are better off using the tcm ids, or the URL/path of the published asset as these will be unique.
You can indeed place it into any subfolder within the services folder. I recommend creating a new folder called deployer-extensions or similar in order that it makes upgrading easier.
You will need to reinstall the service if you want the new folder to be added to the class path.
Since the microservices use Spring boot, you can startup the container using a Container Class available in the Deployer (for example : DeployerEndpointServiceContainer in Web 8.5). Additional modules and Configurations required for this should be available in classpath (resources) folder and running this Container should startup the service.
Seems interesting. I haven't tested it yet but it must be similar as the former Deployer debugging, but instead of running that class, starting the microservice.
This can be achieved by Running or Debugging as a Java Application on the main() method of the com.sdl.delivery.service.ServiceContainer class in the service-container-core library.
Including the ...
Go to your Content Deployer's config\ folder, and open deployer-conf.xml for editing.
Find the last Pipeline section in the file, and add the following two Pipeline sections below the last Pipeline section in the file:
In 2013 in your deployer extension you could get this with the following syntax:
String renderAddedMeta = page.getRenderAddedMetaData();
This example is for a PageDeploy. You have access to the page object in the processPage method. Similarly you can do the same for component presentations.
I am unable to verify at the moment, but Web8 must have ...
Simplest solution would be not to compress the JSON in your Templates, then you also wouldn't have to deal with decompression. This is done by removing the compression TBB from the Template.
Another option is to use the DD4T org.dd4t.core.util.CompressionUtils to decompress it. See https://github.com/dd4t/dd4t-2-java/blob/develop/dd4t-core/src/main/java/org/...
Welcome the tridion community.
Coming to your question about generating site map using event handler is not good idea, because when you publish in bulk, there will be performance and concurrency issues which are very difficult to handle and if you are able to handle them that will be at the cost of increased publishing time.
The better approach to ...
Although, there are multiple options to achieve this which may depends on detailed business requirements and the specific business restrictions you may have, but the best bet in "my opinion" would be to create a separate Publishing Target (and Target Types) and a separate deployer module in addition to your existing deployer. You may want to change the ...
I suspect this will be a polling timeout or something, where the publisher (or more accurately, the transport service) has basically given up on the job as a lost cause but the deployer has carried on regardless. You should be able to check by looking at the failure message in more detail.
You can change the polling settings in your
To piggyback on Saurabh's answer, a storage extension would be a better choice for your use case. A storage extension would better handle storing published items to any storage medium besides the standard content data store.
In the example below, I have shown how component presentations can be stored in a MongoDB server besides the standard content data ...
TBBs are not executed when unpublishing. A simple unpublish instruction is sent to the deployer and that takes care of any known dependencies that can be removed from the delivery system. This is why Will (correctly, in my opinion) suggests using a storage extension. I would consider revising your caching strategy accordingly.
As all of the specific deployer classes (Processor, ComponentDeployer, etc.) remain in the micro-service folder (and still are old fashioned "com.tridion..."); I would put it in there, but I think that it doesn't mind as some of the classes used by the deployer-service, are located in the lib folder.
This can be achieved using Event system. Only thing if your sitemap is bigger in size it will have some performance effect. But you can try the following:
Write a custom event handler on Page Publish/unpublish and make the phase TransactionCommitted which is suitable for auto publishing trigger. As if the action is a success then only you need to add url ...
My suggestion would be do to this change during publish at templating level before the package is created from publisher. Depending upon the publish target, you can take action on the page object as needed. The advantage of doing this at the templating level are a couple:
You can reuse the same template if you need for any other publishing target by adding ...
The action TridionBootstrap from the original deployer-conf.xml file is missing. It should be between the initial <Pipelines> and <Pipeline Id="Tridion-Process-Deploy"... tags:
<Pipeline Id="Tridion-Bootstrap" Action="TridionBootstrap" Verb="Content,Prepare,Commit">
It depends which classes you use in your code, for example, my Deployer extension (custom Module) is working with the dependencies listed below.
Just another point, in Tridion 2013 (SP1) you could create custom Processors, but they are no longer supported. Meaning, that if your old code has any, you will need to change the logic for Web 8.5, you cannot ...
Welcome to the community.
Please read the official SDL documentation to set up a deployed extension here. Also, there is this cool blog by @hemkant explaining step by step to set up a deployed extension.
I'd also suggest having a look at the storage extension option it might suit you better.
We also have SI4T which provides a generic framework for ...
Try to upgrade your deployer extension project with following 8.5 deployer jars dependencies to work for SDL Web 8.5
The documentation contains a very nice (yet completely fictional) example of how to do this, which you can find here http://docs.sdl.com/LiveContent/content/en-US/SDL%20Web-v5/GUID-894AB0F0-313C-45A3-B8FC-8A02DA894C93
The example code will look like this:
Having 2 Processor elements in 8.1 is totally valid. The one with the phase="post-transaction" will execute after the one without such an attribute. Example of such a scenario is when using SmartTarget.
Since you are extending page metadata which will be stored in broker database, deployer extension is not the recommended approach.
Instead of deployer extension, use storage extension, which specifically intended for extending data. Reference for storage extension:
Also, refer to article to find out difference between storage extension and ...