Products.Plone3Cleaners: cleanup after migration from Plone 2.5 to 3
====================================================================

This package is a collection of browser views that you might need when
migrating from Plone 2.5 to Plone 3.  And actually, some of these can
be handy also when not migration, like removing portal_factory items
from the portal_catalog.

Add this package to the eggs of your buildout; no install inside Plone
is needed.


Five local sites
----------------

Local sites from Products.Five have changed a lot since the Plone 2.5
days.  They need migration.  Products.Five offers the manage_site.html
page; just add this to the url of your local site and click the
'Migrate to Five.component' button.  You should try that first, but in
my experience that usually does not work.

Note that a default Plone 2.5 Site does not use localsites, so if you
have them, then they are from a third party product.  If you see an
error like this in the logs when looking at your Plone 3 Site you have a
problem::

  2009-06-23 12:30:17 ERROR ZPublisher BeforeTraverse: Error while invoking hook: "__local_site_hook__"
  Traceback (most recent call last):
    File "/home/maurits/zopes/Zope-2.10.7-final-py2.4/lib/python/ZPublisher/BeforeTraverse.py", line 145, in __call__
      meth(*(container, request, None)[:args])
  AttributeError: __call__

We have two browser views that help in fixing this:

- @@find_local_sites: add this to the url of your Plone Site or of
  your Zope root.  Click the submit button to find all objects with a
  problematic local site hook.  Your zope instance log will have some
  details and the page will display links to the objects that need
  fixing.  The links will point to our second browser view:

- @@update_local_site: add this to the url of an object with an old
  local site hook that needs fixing.  Likely, calling this will give
  that same AttributeError once or twice, but you can ignore that as
  you are about to fix it : click the 'Migrate to Five.component'
  button.

The object that had the old local site hook may need some fixes in the
python code as well.  Ask the developer of the product that this
object is from.  Note that a local site hook is not always the right
solution; and this migration is not always enough.  In a client
project I got rid of one hook and used a simple attribute instead; a
second hook worked fine after the above migration; a third hook needed
a different migration.


portal_factory in portal_catalog
--------------------------------

You have seen this: you write a catalog query, on one of the brains
you do a ``brain.getObject()`` and this fails because the object was
wrongly added to the catalog while being created and it was not
cleaned up.  Clean it up with @@factory_cleanup.  You can choose to
remove those portal_factory brains or remove any brain where
getObject() fails.  For various reasons this may find less or more
items; certainly it takes a lot longer.

