[EMAIL PROTECTED] 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
_______________________________________________
Setup mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/setup
