nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Upgrading from 5.5.2 to 6.5

kshitiz

Hi All,

I want to know what change have to be made while migrating from 5.5.2 to 6.5. I mean will the existing presentation templates, datacapture.cfg etc will work on 6.5 as they are.

What will be the extent of the changes which have to be made?

Kshitiz Sharma
BT Wholesale | CMS
Mahindra British Telecom

Find more posts tagged with

Comments

Adam Stoller

I believe for the most part your DCTs and PTs can pretty much remain as-is without any problem especially if you are NOT using any FormAPI.

If you have something which is intending to take a vpath and treat it as a filesystem path (with or without pre-pending $iwmount to it) -- you need to be aware that any function (within FormAPI, cgi form variables, etc.) that returns a vpath in 6.x will be returning one in the form of "//tsservername/default/main/..." and not "/default/main/..." nor "/iwmnt/default/main/..." nor "/.iwmnt/default/main/..."

Also - at least as of 6.5 there is an actual supported method for getting the current DCRpath. I believe there was one unsupported solution for 5.5.2, and a different unsupported solution for 6.1

Most of the porting issues surround changes to CGI form variable parsing - for cgitask scripts, custom menu items, and cgi-callout scripts. Note: The information provided to cgi-callout scripts from the metadata capture DCT are significantly different in 6.x -- they only provide a usable field name value for the field directly associated with the callout and do not provide any handle to the path/name of the file being tagged (we got a patch from IWOV for this for 6.5 - which hopefully will make its way into an SP in the near future -- but for which we have been forewarned the entire mechanism will most likely change in the next version release (e.g. 6.7, 7.0, whatever).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

nipper

In theory little or none. Templates *should* be the same. Do you use any
callouts, Formapi etc ? PTs ? DD ?

Of course there are things that may fail. Since Perl was upgrade, if you are using
a lot of it, that *could* run differently. You may need to reload special PMs if you have
any.

I am in the process of moving a customer from 4.5 to 6.5. Talk about a quantum leap.
I will post later on the success of the templates there.

HTH

Andy

kshitiz

Hi Andy,

Do you mean to stay that iw-perl folder will be overwritten during the upgradation to 6.5?? If yes, then do I have to reinstall the additional perl packages that i had installed in 5.5.2.?? Or some backup will be created for original iw-perl??

One more request if you could keep me posted bout the issues you faced during the upgradation of 4.5 to 6.5 that you are doing right now!!

Kshitiz Sharma
BT Wholesale | CMS
Mahindra British Telecom

HolgerOstermann

Hello,

you will have to install the perl module again for TeamSite 6.x's new perl 5.8. Also make a backup of your custom configuration (iw.cfg, workflows, ...).

Best regards,

Holger Ostermann

nipper

It usually copies the perl to perl.old and reinstalls it. FYI, I have had good luck with
TS maintaining the rest of my files (available_templates, etc).

Andy

Adam Stoller

As has been mentioned - when upgrading from 5.x to 6.x - the version if iwperl changes - so expect the entire iw-perl directory tree to be replaced.
If you have custom modules installed in there for 5.x then you will want to hold on to them **but** you will probably want to download fresh copies as the versions of the modules you currently have may not work with the newer version of perl.

Also - as of 6.x - the iw-perl directory structure has changed and has become consistant across platforms - specifically there is:

iw-perl/lib --> core perl 5.8.2 modules
iw-perl/vendor/lib -> Interwoven supplied CPAN modules + Interwoven's own modules
iw-perl/site/lib -> customer supplied modules (CPAN and/or home-grown)

The beauty of this is that *now* you can put your modules into iw-perl/site/lib and Interwoven has promised never to muck with that directory -- a patch, SP, or upgrade may change the contents of the first two directories but it will *not* touch the contents of the third.

It's a much cleaner methodology.

A couple of pther things to consider regarding the new version of Perl and TeamSite:
- by default, the form variables that were passed to your CGI scripts (cgitask, custom menu, callout) have significantly changed with respect to the context information (area, files pre-selected, etc -- [not the taskid information though, fortunately]) and some of the information has moved from $cgi->{form} to $cgi->{cookie} [iw_user, iw_role]. You do have a choice however, in that if you want, you can use the supplied wrapper script wdpro_menu.ipl to get the old form variable information -- otherwise [and I generally recommend this] - you will need to rewrite code that used that information to use the new form variables.
- instead of putting a '-w' on the #! line of the script, use the pragma: 'use warnings;' (usually just under 'use strict;')

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com