There’s been quite a lot written about Duplicate Binary Issues in SDL Tridion. A couple of years ago I released a PowerTool to solve this issue. Knowing it can still be troublesome for some SDL Tridion users, I decided to give it a little rewrite and release it as an alchemy plugin.
This small blog post isn’t really something Tridion-specific. However, with SDL Web 8, installing or configuring the CMS or content delivery usually involves running a few powershell commands. Usually, we run these commands to install a database, or to create a topology, or install or manage the microservices.
The last few versions of Alchemy have allowed you to update it’s software directly within the CMS. As we make improvements to the API and new functionality, it is key to update to the later versions. To show you how simple this process it, i’ve made a quick recording to walk through the process.
With the advent of SDL Web 8.5, we’ve seen many nice improvements to the software. We’re able to move items in the blueprint hierarchy, we can now set up a whole content delivery environment with a number of powershell scripts, … but in our most recent upgrade, we’ve found a big problem.
I’ve been keeping a little notepad file on my machine for a while some of common code snippets that help when building SDL Tridion Gui / Alchemy extensions. I thought it would be great to share them with the community in the hope that they can help someone, and others can contribute.
Last week I had the pleasure to attend SDL Connect as a guest, speaker and sponsor. My presentation was focused on creating a Technical Strategy for Customer Experience (CXM).
So why another MVP blog?
I promised myself I’d put something together after my first MVP Retreat but it’s taken me a while to ‘get over it’ (this is, of course, a reference to the amount of food that was eaten).
We recently worked with one our customers looking to implement personalization within their SDL Tridion environment. The client was looking to use either SDL’s Experience Optimization (XO)* or Adobe’s Target product.
We had a scenario while building a form on Java DXA 1.7 and tried to have it submit via POST, not GET. We had the form working perfectly via GET, but when we changed the method to POST the response was a 403 Forbidden. We poked in many directions, such as directory security settings and web.xml configs. In the end it was the CSRF configuration built into DXA that was the answer…