We are iterating the components in a folder in Tridion 2011 and creating our custom XML to be used on CDS on the basis of the publishing status of component. I am giving below example to make you understand the problem.
Supppose we have 10 components in a folder which are all published and we publish our XML then the XML gets generated for 10 items.
Now we make change in one of the component and don't publish it.
After modification of component, we publish the XML again. then the XML get updated for the modified component also. So it creates the difference between the published version of that component and the that is in our XML.
So I want to publish the custom XML in such a way that it should only contain that data which is in sync with published version of component.
So you want to:
determine the XML of the Component that was last published
determine the changes between that XML and the current XML of the Component
only publish the changes
Tridion doesn't keep track of the version that was published (on the Content Manager at least). So the closest you can do is find out when the Component was last published and retrieve the XML of that time. This question is a great starting point for more information on that approach. Based on that XML you can then do steps 2 and 3 above.
Alternatively you can keep a snapshot of the XML that you published "somewhere" (for example in Application Data) when you're rendering the Component. Then when the Component gets published next time, you can retrieve that XML and do steps 2 and 3 above.
Note that with any of those solutions you should really wonder if you should be implementing it to begin with. You are overriding some of Tridion's default rendering behavior and circumventing part of its architecture (a clear, explicit disconnect between Content Management and Content Delivery, with the former knowing "nothing" about the latter) and anything you do will come back to haunt you in time. In this use-case you have to wonder what will happen when the CDS and TCM get out of sync. Simply republishing the content suddenly won't be good enough anymore, since your code will be in there deciding that "nothing changed since last publish, so we'll publish nothing".
Please forgive me if I jump to conclusions, but I strongly feel this question has arisen from a lack of understanding of Tridion. Publishing in Tridion does more than just raise a flag to indicate the item is 'published', in other words ready to be shown to the outside world. I know this is how some (many) content management systems operate (which may explain why you are asking this question).
In Tridion, however, publishing means that the item is actually - physically - transferred from the content management environment to the content delivery environment. This environment always contains versions of your content that represent the state when the item was last published - simply because it was the very act of publishing that created them.
In my opinion, what you are really asking is how to rebuild this publishing functionality. This is never a good idea. Instead, you should take Bart's comment seriously and look at one of the content delivery APIs that Tridion has on offer (the broker API or the OData web service). Optionally you might want to look into DD4T, which is built on top of the broker and exposes the full Tridion data model.
Then your solution is to
Write an event handler on the Publish Transaction Save event
Which saves the publish info (version data) to Application Data of the published Component
I'm mentioning the Publish Transaction Save event because from there you can ensure that the publish info is only saved when the transaction is successfull.
Also be aware that this publish info can go out of sync when the event handler fails to execute, and you might loose all of the application data when moving to another environment.
So when this information is absolutely crucial I would save it to a separate database, and not to Application Data.
Related
We have a requirement that on a page publish, we need to:
Find a component presentation that has a component based upon a particular schema.
Extract certain field vales from that component and store them in a custom database table that's available to our .NET application (on the Content Delivery side).
I think this is a good candidate for either a Deployer extension or a Storage extension - but I'm a little unclear which and why having never written either?
I've ruled out the Event System as this kind of code would be located on the CM, which seems like the wrong "side" to me - my focus is on extending what happens on the CD-side after a page is published.
Read a few articles on Tridion World (this, this, this and this) and I think a storage extension would be the better choice?
Mihai's article seems to be very close to what we need, where he uses a new item type mapping:
<ItemTypes defaultStorageId="brokerdb" cached="true">
<Item typeMapping="PublishAction" cached="false" storageId="searchdb" /></ItemTypes>
But how does Tridion "know" to use this new item type when content is published, (its not one of the defined TYPE_NAMEs, which is kind of the point)?
I should clarify I'm a .NET/C# dev not a Java dev so this is probably really obvious to Java people - apologies if it is!
Cheers
Tridion will not know by default how to deploy your new entity. My advise is to create a Deployer Module (your links should give you enough information about how you can do that) that executes in post-processing phase (of the deployment process), that processes all components from the deployment/transport package, extracts the needed information and uses a custom Storage Extension to store the needed information.
Be careful: you need to set-up in config your new type but you also need to use it yourself from that Deployer Module.
Hope this helps.
Needed to understand your inputs on: Is there a way in Tridion 2011 to Publish or Unpublish components/pages/templates in a custom resolver code. I understand we can play with the list of resolved items. (By giving a CP,etc). But is there a way to push an item in the publishing Q from a custom resolver code.
You can add or remove any number of items to be part of the existing package / transaction.
If you want it to be part of a new entry in the Publishing Queue instead, the event system seems more appropriate than a resolver. But the items you are publishing automatically won't show up in the "Items to Publish" screen if you Publish them separately, so you need to decide if that's a good thing or not.
Peter (and Nuno) have really answered your question in the best way. You should use a resolver to add the Pages or Component Presentations to the package rather than making new publish transactions. However you can publish items using the core service, so there is no reason you could not call the core service from a resolver and initiate your new publish actions that way.
However it does not sound like a good idea, perhaps you can update you question to explain why you need to do this.
I used to use the PublishEngine object in my templates to add items to the Publish Queue (see http://www.tridiondeveloper.com/the-story-of-sdl-tridion-2011-custom-resolver-and-the-allowwriteoperationsintemplates-attribute), but custom resolvers and other techniques are far superior.
I'm trying to publish a page during Workflow. There are two environment that we are publishing to during workflow process: one to test and one to live. During the first automatic activity we are publishing to test and during that process the Components on the Pages don't need to be approved. We got that to work.
However when we approve the Page and the Page is being published to live, we need to make sure that we only publish approved Components (i.e. major versions).
In my code I'm using the Page.Publish method, but with that I can't specify that it should only publish approved items.
The publish method accepts an argument called activateWorkflow. When set to True it publishes both approved and unapproved items; but when set to False it gets added to the queue and we get a success message, but nothing gets published.
Anyone have any ideas how I can fix this, using the publishing method and without manually checking?
Thanks.
I ran into a similar issue when going through Component Workflow and having to publish static pages (no dynamic component presentations).
When publishing to test, as you mentioned, simply do activateWorkflow=true. For your Live environment you need to kick off publishing after workflow completes. I've resolved the issue via the event system for this. Here an article that discusses this in more detail that may help you:
http://www.tridiondeveloper.com/autopublishing-on-workflow-finish
It is not clear where you are performing the activities, are you doing this from within your workflow activities in Visio?
Publishing will always only publish items that are either in the approved status for that target and items that have finished workflow (major versions).
All that said, I believethe reason you are getting empty PublishTransacctions is because you are calling the Publish() method on new items before you finish the page workflow activity (which means your new item is still in workflow, so the false value means there is nothing to publish which is not in workflow). Try calling FinishActivity() before the Publish() method is called.
Perhaps you could post your code from the final step so we can see exactly what you are doing.
I've struggled with a better solution for the following setup. I'm not actively working on this, but know some that might appreciate other ways of handling this.
Setup:
Tridion-managed page has a single "linked list" component Linked list
Single component has component links to other components in Tridion
Linked-to components often link to multimedia component (mm)
An XSLT component template (XSLT CT) renders XML with above content and with links to PDF
XSL document() function used to grab embedded (linked-to) content, all content converted to XML nodes and attributes
TCMScriptAssistant namespace with publishBinary() publishes related PDF and other media
Page template just outputs the result of the CT
Business requirements:
improved publishing (last I worked on this, some of these files created a 2GB publishing transaction because of the PDFs)
published XML content file must reference the associated PDFs; hyperlinks work but identifiers might not help because of...
no Tridion content delivery APIs, mainly for independence from the storage database but also to avoid Tridion-specific code on the presentation server (loosely coupled setup and less training for developers)
The biggest issue is the huge transport package during publishing. The second problem is publishing any of the linked-to PDFs will cause the page to republish.
How could this setup be improved or re-engineered, preferably without too many changes to the existing templates, though modular templating could be considered.
Dynamic component presentations could possibly work, but would need to be published to the file system and not use dynamic linking or broker objects (e.g. no criteria filters, binary metadata, etc).
There are indeed 2 questions. I will handle them in reverse order.
To prevent the page from being republished when you publish a binary, you can use the event system in older versions of Tridion (pre-2011) to turn off link resolving, or with newer versions you can use a custom resolver to prevent this. There is an article by Nuno which explains this(http://nunolinhares.blogspot.com/2011/10/tridion-publisher-and-custom-resolvers.html)
Your second one is a bit tougher, in no small part because of your criteria for not using the SDL Tridion CD APIs. I would have suggested publishing the binaries separately (this would keep the file size down of your transaction package), and using Binary Linking to resolve the paths at request time.
Given this is not an option, I think the only was I would approach it would be to still use dynamic component presentations, and then use predictable unique file names for the PDfs (i.e. use something like 317-12345.pdf based on the URI), and use one directory for all the binaries. That way you could enter the paths to the binary using your XSLT template, as you know where the binaries will be located later. You could then use a custom resolver to publish the binaries when you publish the main list component or page.
Hope that helps
Chris
Setting the scene:
My asp.net web application carries a version number which is incremented during every release. We're releasing every week internally for our test team and after four weeks or so to our client.
The question:
I want to include the version number on our application. What methods have you used so that your web app carries the version number? meta tag? simply added it to the footer?
If you are in contact with the client a lot (for bug fixes or changes) you should keep the version number in a place that is easy to find (such as the footer). You will find yourself asking the client what version they are running, if they cannot find it it is frustrating for both the client and the support staff.
Make sure your footer is a user control or that the version is stored in either a database table or a resource file so that you update once rather then going through each page updating. My recommendation is a user control and if you want to track versioning store the version numbers in a database and read it into your user control.
You can take the MS route of doing a help->about given a menu and displaying the version number in say a js popup or on another page.
If for some reason you do not like the version number on a footer or even a help menu popup and you do not deal with the client regularly you can put it as meta data or in the source code of your HTML.
I've seen a lot web applications (and websites) I've seen that add the version number as a comment within the generated HTML. The BBC is one of them - view the source and you'll see <!-- Barlesque v34.8 --> in the header. (Barlesque is the BBC's layout system.)
We have some information page where we display the version number (SaaS application).
But seriously, with web software version numbers are irrelevant. It is the point of migrating to the web - so that the users finally forget about those versions, updates, service packs etc. Otherwise the idea of a constantly updated web application (perpetual beta) is not really grasped by either party.
In some Projects we added the Version number to the footer. We displayed the Assembly (any of our Assemblies) Version number.
With that method we did not have to care about the text in the footer as long we incremented the Assembly Version.
Assembly Version was extracted with Reflection.
Check out the code posted here. It will gather and display the .NET Framework version info. Anytime you need the version information of the current assembly, you can use
Assembly.GetExecutingAssembly().GetName().Version
Similarly, to get the version info for a particular assembly, you can either reflect directly on the assembly, or simply use a class in the assembly
typeof(ClassKnownToBeInTheTargetAssembly).Assembly.GetName().Version
where ClassKnownToBeInTheTargetAssembly is a class declared in the assembly you want the version info for.
BTW, these comments assume that the assemblies are signed.