[Setup] Re: portal_atct CMF Topic missing FTI error migrating from Plone 2.0.5 to Plone 2.1.2

[Nick Davis]

Jon.Lim at hawaii.gov wrote:
> 
> Hi Nick,
> 
> Ah, apologies for not replying to your email on the plone-user list.   
>  Thank you for the reply to my question....  My inbox got filled when I 
> signed up for the plone-users mailing list so I unsubscribed to keep my 
> inbox from filling up.  I did see the email you sent on that other list, 
> however.   Is the plone-setup list the appropriate place for this question?
No worries. Sorry, didn't mean to give you a hard time. I had just 
answered a number of people and wondered if it helped them. :-)
I believe the "Gods" (Limi & Runyaga) do prefer migration questions to 
be asked on the setup list than plone-users, yes.

> As you have suggested, I started by migrating the 3rd party products 
> first before migrating Plone to 2.1.2.   
Just to check no misunderstanding here, what I meant was, take an empty 
2.1.2 site, add in the 3rd-party products, and see if at this point you 
need code changes to make them work. Then go back and try migration from 
2.0.5, with this updated code. (Probably this is what you did already...)

> *PORTAL_ATCT ERROR:*
So your Topics are blowing up trying to migrate. We didn't have Topics 
on our 2.0.5 site, so I never experienced this problem.

You can try the type migration alone by installing portal_atct with 
portal_quickinstaller, then go to portal_atct, do version migration, 
recatalog CMF, then type migration. I suggest this just in case the 
recatalog CMF didn't happen when you did the normal migration.

You might also try doing the migration on both Zope 2.7.8, and 2.8.5 and 
comparing the results for clues. They official recommendation is to do 
it on 2.7.8 but we found 2.8.5 worked better.

Could you simply get rid of all your Topics and add them back by hand 
after migration? Or are there too many?


> "/usr/local/zope/instances/01_zope278/Products/CMFPlone/migrations/v2_1/alphas.py", 
> line 29, in two05_alpha1
>     convertPloneFTIToCMFDynamicViewFTI(portal, out)
You might go to this function, put an import pdb; pdb.set_trace().
In case you do't already know, to debug in emacs, open a couple of file 
buffers, then do Esc-X shell, ./runzope from this shell, then run 
migration from the ZMI and eventually emacs will open up the debugger 
with the source code in another buffer which is a nice way to debug.
This assumes you're on *nix. If you're on Windows, I've heard PloneShell 
is a good way to go.

If you run out of ideas, I must say that migration was painful for us 
and at one point Alan Runyan suggested we might pay them or some other 
plone developer to do some of the work. It wasn't an option for us, but 
I can see why he suggested it. One problem I find with Plone is that 
sometimes rough edges, edge case bugs , do not get fixed and that is 
largely because the possible pain and uninterestingness of fixing them 
stops anyone doing it unless they get paid. If they're coding for free 
it makes sense that they'd rather write a cool new feature than fix an 
old one. This however means there is this sometimes brittle-ness about 
things which detracts from Plone. So that might be an option too...... 
But I do recognise many organisations with theoretically deep pockets 
cannot understand why they would ever pay anything for open source when 
it's all supposed to be "free". ;-)

Regards,
Nick


Nick Davis
University of Leicester