Indeed the com.tridion.storage.ComponentPresentation class was changed. The create, remove and update methods now receive the Component Presentation content as byte-array.
If you need the string contents, you can simple do:
public void create(
You can always try to access the package as described here using a deployer extension. Or if you want to stick to the Storage extension, you might be able to re-use the Utilities class provided in the link above and then use its getComponentPresentationsDocument method (or another method in such class) to access the package files and/or contents.
As you've realized, this cannot be achieved using templating. If you wish to do this this way, you will need to use a different extension point, namely ITransportPackageHandler.
See my TDS presentation for more information here.
But... why don't you do this on the CM side? Make use of the Event System and the SetPublishStateEventArgs class. This is only ...
The behavior is because of the way the storage layer function for Tridion Docs.
As we know in Tridion Docs only Publications can be published/unpublished. While publishing, the storage layer stores the Publication along with its items (Page => Topic + Template, Component Presentations => Topic + Template) individually so the create methods execute for ...
You might be able to achieve that using a CM Event handler for PublishTransaction Save (Initiated phase).
If the Publish Transaction state is set to Failed and you recognize your error/warning message in the deployment feedback XML (stored in PublishTransaction.Information), you could change the state to Warning.
JPA DOAs are used only for non-filesystem storage. If you want to extend the behaviour of storage on the filesystem you need to extend the corresponding FSDAO class.
Note that you can change the storage ID (and caching settings) per publication to use and thus switch between DB/filesystem but you cannot change the DAO to use per publication as your custom ...
If it is for ComponentPresentationDAO then I can confirm that it will always be the create (for publish and Re-publish) and remove (for unpublish ) which will be called.
The Update method will never be called.
It might be because the super class JPAComponentPresentationDAO have this update method but it is not in use by the Storage Layer.
I hope it helps
FOUND IT! It has cost me (and you) a lot of time, and the issue was indeed not in the code / configuration itselves. The solution is so simple that I am almost ashamed to share it ...
When exporting the jar file I had to select 'Add directory entries':
Thank you all for your advise.
Rogier Oudshoorn's answer recommends looking into setting cache-expiration policy via headers that are set by your applications. That is absolutely the way to go for day-to-day operation of content expiration.
However, there are times when you really need to expire something more programmatically. For example, an item that is referenced from a home page ...
I remember facing the same issue. I went with converting the byte into a String the "java-way". As far as I remember the byte contains the published content, so yes, by converting it to a String it would give you the published content. Just remember the Encoding you want to use for such conversion, if you are publishing UTF-8, then use UTF-8, if you know ...
I realized that the JPAComponentPresentationDAO which is the base class we are using in our custom storage extension class have got changed a lot in terms of the class members and the method signature. This required us to re-write and re-build the class inherited from this DAO such that it implements and reflect correctly all the parent members.
I have built a very similar solution for a customer and the step of storing the binaries on the deployer filesystem had two advantages for us:
it makes it much easier to debug any issues (as you can see if the deployer is working in principal and only the extension is at fault)
it made the upload to S3 much easier as the library we used would determine the ...
Storage extension has nothing to do with CMS Templates, both belong to two completely different contexts.
Templates are executed in the CMS during the publishing action.
Once the Package is sent to the deployer, the deployer process the zip received and stores the items. This is when the Storage extension is executed.
Moving logic from an storage extension ...
Unfortunately, I did not find a solution to the issue as the issue resides in core libraries.
Currently, for SDL Docs, it is not possible indexing to the data-sources on CommitTransaction method as we do for SDL Sites because of the issue.
For a temporary solution, I start indexing the data to a temporary queue (Azure Servicebus in my case) from ...
I asked this question over an year back and per my knowledge, there is no straight-forward way to achieve this.
The data the deployer passes to your method (CharacterData page) is actually your rendered Component Presentation (the ouput that your PT will generate for your page), so if you want just a list of component presentations you could generate some ...
For this kind of issues you have to use two deployers. As you know, there could be the various options for this, but seems the simplest is just running two upload sites with different configurations.
You need to create 2 different storage for different and provide storage id in your publication configuration for different type of binaries.
You most likely need to use the addbinary method of the TOM.NET api as described in the comments, but it's also possible to edit your storage configuration to store different file types in different storages. Actually there's a lot you can do with storage (cd_storage_conf.xml) so id recommend reading the docs to see what's possible.
this might mean you don'...
Since you are using a custom storage extension, as mentioned in my comment, I think the error is in there.
As Peter mentions, the mime type is not part of the file, but should be set by the web application serving the file.
If you have added an additional mime type in Tridion, and that is also used when calling AddBinary in your TBB, then you should have ...
MIME types (or "Internet media types" as they are known these days) are not stored in the file itself, so the Content Deployer isn't involved.
The type should be set in the response headers by the web server, when it serves the file.
For example, I might store a file as a simple text file -- and then have my web server return it as "text/html" if I want ...
I've just been having this same discussion with some colleagues for a requirement they have. Here's the approach we (that's the Royal 'We' - by which I mean 'they') are looking into:
We have a page (essentially a dummy page).
The TBB generates the stream of output (a SASS JSON setup for AD, JSON config settings for DXA).
Then the TBB writes this out as a ...
Instead of doing @Override, can you just call super.remove(), as per the example here?:
The undeploy mechanism in the Tridion Deployer requires not only the Page to be present but also the associated PageMeta object.
If you do a custom DAO implementation, you have to ensure that some minimal form of page metadata captured though a PageMeta object is present in your storage layer for the undeploy to be triggered.
You can modify the "output" in a storage extension, but is important that you understand where/when to do so. If/When possible, I'd recommend exploring the possibility to do so in a TBB which requires less (or none) deployment/infrastructure/configuration work.
If you could elaborate more on what is it that you are trying to accomplish and why, I'll be ...