Thursday, October 26, 2017

Forcing Workflow on Templates (Design Items) in Tridion

The main purpose of  Tridion Workflow is to audit content before it is published to a particular environment, but it is also important to audit the design changes before making those available for a end user on a particular environment. Without proper auditing wrong version of the layouts (and possibly JS functionality) could make all the way to Live application and can have all sorts of user experience issues.





Importance of Workflow Enforcement on Tridion Items:

 

When a tridion item is updated outside of the workflow or a new item created, item was set to approval status 'undefined'. With this 'undefined' approval status there was no restriction on publishing those items at all, means the item (content/template) which was yet to be approved by workflow process could be published.

To make sure any unaudited item (content/template) doesn't get published. Tridion provides OOB functionality to Enforce Workflow on Components and Templates.

In one of my previous blogs, I explained how to force workflow on Components. Here I am going to explain how you can force workflow on Templates (TBBs, CTs and PTs).


Forcing Workflow on Templates:


1. Enable workflow on the publication:
Before forcing workflow on the items, you should always enable the workflow on that particular publication otherwise new and updated items would be waiting forever for a workflow to be enforced, as user would not be able to trigger a workflow process on the templates.

To do so, open publication properties and inside workflow tab check the checkbox "Enable Workflow Process Associations in Shared Schemas and Structure Groups" and save the publication properties.









2. Force the workflow on design items:
To force workflow, open publication properties and inside workflow tab check the checkbox "Any changes made to a Template in this Publication require approval by a Bundle Workflow Process" and save the publication properties.










Once the workflow enforcement on templates is set on the publication, Now if you updates/creates template (or TBB) outside of workflow, Instead of being checked-in and available for use, a minor version of the template will be created in "Waiting for Workflow" state. To use this version, you must add it to a bundle and start the workflow on it. Once the workflow is finished, the minor version is converted to a major version and is ready for use.

Thursday, October 12, 2017

Five Basic Things you should know before developing a Alchemy Plugin



Alchemy for Tridion is getting popularity by every day passing. More and more plugins are being submitted to Alchemy Web Store. I have developed few and it's really a fun. So if you want to give it a try go ahead, all you need to do is:

1. Install the Alchemy on your DEV CMS Machine.

2. Get the Alchemy development framework to visual studio using Nuget Package or VS Pack.




Now when you are all set to develop a Alchemy Plugin from your idea. Ask the below questions to yourself and note the answers:
  1. What does it do?
  2. What do you want to extend?
  3. Where to show your extension?
  4. When to show your extension?
  5. What resources you need to have in your extension?


What does it do?

The answer to this question will help you with
1. You can copy and paste the answer to the description element value of the "a4t.xml" file in your visual studio solution.
2. This will help you identify the possible conflicts with existing OOB GUI/Functionality. Which is quite important consideration before developing a plugin.


What do you want to extend?

So Tridion provides some extension points/areas OOB. In Alchemy Framework you would have all those extension points as Base Classes as below: 


  • CommandExtension
  • ContextMenuExtension
  • ExtendedAreaExtension
  • ExtensionGroup
  • RibbonToolbarExtension
  • TabPageExtension

You have to answer which extension point(or points), you want to extend. And based on this answer, you would create your Extension class by extending one of the above listed classes.

Where to show your extension?
So other than command extension, you need to tell Alchemy where you want to show the extension. This is really a important question as you need to make sure your extension doesn't break the existing GUI and not in conflict with another Plugin/Extension.

When to show your extension?
So there could be conditions when to show (or execute in case of command extension) the Extension. For example, a particular Extension could be available for any particular User Group. So if you have any condition like it, you would have to take care of this during the development. There are different ways to control it for different type of Extensions.

What resources you need to have in your extension?
You could have additional resources to support your extension like JS, CSS, ASPX ans ASCX files. You need to identify the resources and the place to put those. Alchemy Framework has a very specific structured way to organize those files.

I will cover all above points in detail in my coming blogs. I hope this high level information helps.