12

We have around 5K pages in tridion, after upgrading from 5.3 to 2011sp1, Due to some business reason we are not upgrading the broker db, fresh publishing will happen to blank 2011 broker db and filesystem for new 2011 environment. so there would be two parallel environment of 5.3 and 2011.

Now QA wanted to compare pages from both the environment to ensure up-gradation has happen successfully so i am looking for some tool to compare the content of old and new. Is there any tool available from tridion to compare the page content.

Is it necessory to compare all the pages? anyone have any previous expererince on it any other suggestions for this kind of task are welcome

14

The biggest "gotchas" I've had with an R5.3 to 2011 upgrade were mostly on the Content Manager side. Definitely follow the other answers for ways to confirm your final presentation-side markup, but be sure to test and synchronize your CMS-side components manually or with code.

Issues the community's helped me with:

  • CM-side: Image References change, mainly for XSLT Component Templates
  • CM-side: XSLT Rich Text Filter namespace change (making content "disappear")
  • CD-side: Content Delivery (CD) storage (broker) database update and the impact on the CD API

These were specific to an XSLT CT with ASP.NET setup and may not apply to all upgrades.

Image References (just via XSLT CTs)

This seems to apply more if using now-legacy XSLT component templates.

  • SDL Tridion R5.3, image tags in rich text fields were "available" to XSLT templates as: <img xlink:href="tcm..." title="" alt=""/>.
  • SDL Tridion 2011 requires XSLT templates to look for a "src" attribute instead: <img src="tcm..."/>.

Compound Component Templates don't need changes as they seem to still use the previous xlink:href format.

Read more about the differences on SDLTridionWorld (requires login)

XSLT Rich Text filter

It seems like SDL Tridion 2011 added a new (or changed the default) namespace for the rich text filters, specifically: http://www.sdltridion.com/ContentManager/R6.

However we need all nodes to have: http://www.w3.org/1999/xhtml. You can add this namespace manually to XHTML nodes in the XSLT filter, but one work-around that worked for a R5.3 to 2011 GA upgrade was to add xmlns="http://www.w3.org/1999/xhtml” in the schema's rich text filter as another attribute.

Before:

<tcm:FilterXSLT xmlns:tcm="http://www.tridion.com/ContentManager/5.0">
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform”>

After:

Save & Close after you get the following, then open and save components based on the schema to confirm the fix.

<tcm:FilterXSLT xmlns:tcm="http://www.tridion.com/ContentManager/5.0">
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" >

Jaime Santos Alcón added additional steps in this forum post(requires login). Specifically, he added the xhtml namespace to each paragraph node.

Quote:

<xsl:variable name="xhtmlns">http://www.w3.org/1999/xhtml</xsl:variable>
<xsl:element name="p" namespace="{$xhtmlns}">
<xsl:apply-templates mode="copy"></xsl:apply-templates>
</xsl:element>

R&D has since updated the XSLT rich text filter to fix other issues (e.g. a difference in how the enter key was interpreted), so disregard if you don't see this issue.

Warning: as with any rich text XSLT filter change, double check the changes before applying this to live content. Some content and changes might seem okay, but test a variety of nodes as well as nested nodes before changing content porting your schemas to production.

CD storage and API change

At least in R5.3, custom meta in the broker database were stored as comma-separated string in the database. This let you do Custom Broker queries with some SQL (as a string in code). 2011 doesn't allow these queries (and they wouldn't work against the new database format anyways); instead 2011 uses Criteria Filters such as:

CustomMetaValueCriteria value = new CustomMetaValueCriteria(new CustomMetaKeyCriteria("city"), "San Diego");

If you use the CD API, you probably already noticed the change. It's just worth noting a Tridion upgrade isn't just functionality and infrastructure; be sure to check any presentation-server code.

Update: We've seen performance-related issues when setting up Criteria Filters as described below. Basically use CustomMetaValueCriteria() to do key=value type filters; avoid using ANDs, especially followed by an OR, when matching multiple key=value filters.

Bad, serious performance impact

This looks for (States AND All) OR (States AND California). It's wrong, don't do this.

CustomMetaKeyCriteria key = new
CustomMetaKeyCriteria("states");
CustomMetaValueCriteria value = new
CustomMetaValueCriteria("* All States");
CustomMetaValueCriteria value2 = new
CustomMetaValueCriteria("California");
AndCriteria first = new AndCriteria(key,
value);
AndCriteria second = new
AndCriteria(key,value2);
OrCriteria orCriteria = new
OrCriteria(first, second);

Correction for the AND

The AND is actually the wrong approach when dealing with custom metadata keys that have multiple values.

CustomMetaKeyCriteria key = new
CustomMetaKeyCriteria("Destination");
CustomMetaValueCriteria value = new
CustomMetaValueCriteria("Lisbon");

AndCriteria notreallyamatch = new AndCriteria(key, value); // this isn't always correct

Better, if trying to match key and value

CustomMetaValueCriteria value = new
CustomMetaValueCriteria(new
CustomMetaKeyCriteria("somekeyname"), "specficvalue");

Summary

By opening (maybe tweaking content by adding a space) and saving components, you'll manually synchronize them. This will help confirm:

  1. XSLT rich text filters match your expectations.
  2. Images are saved in the latest format.

You'll then want to confirm the the template code runs against updated content, either by previewing in the CME or following the recommendations in the other answers. If not using XSLT CTs, then focus on the rich text filters, template output, and any CD API code you might have.

  • We do have some SQL queries written for quering the broker using metadata(as you mentioned). Should we move to Broker API, Would there be any performance impact due to that? – Raj Kumar Mar 3 '13 at 14:27
  • My old team and I actually couldn't figure out how to use the old custom queries with 2011--I believe Intellisense showed "obsolete" in Visual Studio. I updated the answer with a "gotcha" we found with the new Criteria approach (we were doing it wrong). In terms of Broker queries, both the items as well as the queries themselves are cached with 2011. As you change you over shouldn't see much performance differences; you might see some improvements. Do let us know if you can get the old queries to work, though. – Alvin Reyes Mar 4 '13 at 21:17
  • How did you update all the rich text fields in all schemas for XSLT filter issue, is there any shortcut? also you mentioned above <xsl:stylesheet version="1.0" xmlns:xsl="w3.org/1999/XSL/Transform”> in before code, but i don't see xmlns:xsl, what i can see in 2011sp1 is only xmlns. is it a typ0? – Raj Kumar May 15 '13 at 13:39
  • 1
    It was a manual update, though an embedded "paragraph" schema consolidated the number of rich text fields to update. You might not need the xmlns:xsl for 2011 SP1, the above fix was specifically for 2011 GA and 2011 SP1 had some follow up changes to the RTF filter. The biggest issue with a 5.3 to 2011 GA update was the default namespace ("xmlns=" with no colon) was http://www.sdltridion.com/ContentManager/R6 in 2011 instead of http://www.w3.org/1999/xhtml as it was in 5.3. Be sure to test components' source before and after, including nested nodes, before changing everything! – Alvin Reyes May 15 '13 at 16:20
11

There is no out of the box tool from SDL which allows you to compare two sites. I would say you best bet is to use a tool like HTTrack to download a copy of the new and old sites, and then use a file/folder comparison tool like WinMerge to identify any delta between the two data sets.

Some similar suggestions have been made in this Drupal related post: https://stackoverflow.com/questions/707080/tools-to-compare-two-sites-structures

11

I actually think it's a pretty good idea not to upgrade the broker databases. Broker databases are in their nature ephemeral, and publishing afresh from the CM is the right thing to do.

Regarding the comparison of pages, I don't see why you would expect Tridion to have a tool for this when there are any number of excellent web testing tools. So for example, you could use Selenium, or HTMLUnit just to name two tools.

  • Right, but just thought to ask, But i got very good responses. this forum really rocks. – Raj Kumar Mar 4 '13 at 3:58
  • 1
    Dominic, I supose the workability of not upgrading the broker db and instead republishing everything depends on how many published items you have, how long it would take to republish all of them and how long you can keep your editors out of the system. – Glenn Stevens Mar 4 '13 at 4:23
  • Glenn - there are various possible strategies to mitigate the pain of a big publish. For example you could publish to a new target and switch over to it once publishing is done. Obviously, you'll only go there if you need to... – Dominic Cronin Mar 4 '13 at 22:05
  • 1
    I wouldn't say that it's the right thing to do. In just republishing from old CM to new, blank CD, you affect the integrity of CM. there is minimal knowledge on CM of where content is published to, but the relationship does exist. I think it needs to be mentioned. – Davina Erasmus Mar 5 '13 at 19:31
  • 1
    That's the point, Davina. If you publish to a fresh broker db, the CM's view of the world and the CD view are in sync. Copying databases around on the CD side can be done, but only while paying attention to this issue. Having said that, better support for making the CM "forget" a target would be good. – Dominic Cronin Mar 6 '13 at 6:41
9

Comparing the two broker databases

On the database side even though you are not going to use it for running your site, you can run the upgrade scripts against a copy of the 5.3 broker database (so that it has the 2011 schema) and then use straight up SQL queries to perform comparisions between the content in your old broker db vs. that in your new broker db.

Alternatively you can use a tool such as SQL Data Compare to simplify the data comparision process.

Comparing the published pages

On the published page side you can, as Chris suggested, use a tool such as Beyond Compare to perform bulk comparisions of the files and folders. Your exact approach for using a file/folder comparision tool would probably depend on exactly what level of testing your QA team wants to perform.

If they would be satisfied with direct comparision of the original source files, you can just point the comparision tool to the appropriate folders on your old and new server.

If they want to compare the final pages as served by your web server you can do as Chris suggested and use a tool to download all the pages from the old and new sites to a local filesystem and compare the saved files.

Another possibility in the later case is to write a small application that uses the urls of the published pages from the broker database to download the content of the pages from both the old and new servers and then programatically invoke a file comparision tool to compare the two versions of the pages and output any differences to a file for later review by a QA engineer.

Beyond Compare has scripting support that can help with the comparision part of this, you can even define 'unimportant differences' so it doesn't flag silly things like different date/timestamps in generated pages when it runs the compare.

2

Maybe you could write a script to check the publish status of each item and then re-publish the item to the empty Broker DB. I believe the API command is something like IsPublishedTo(PublishTargetUri).

This would be the best way to make sure the new situation is the same as the old one.

  • You can also use this technique to produce a report showing the differences in what is published to each publishing target. – Glenn Stevens Mar 2 '13 at 18:30
  • I would argue this should not even be necessary - If you simply alter your Targets destination of the migrated system to point at the new deployer - a simple republish should just republish all the items that were on the old CD system to the new one - But to be honest, I am not sure that even answers the question of comparing old to new. – Chris Summers Mar 2 '13 at 18:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.