Proposed upgrade; Plone 2.0.5 to 3.x
|
|
|
Phillip Abramson
()
Proposed upgrade; Plone 2.0.5 to 3.x
|
|
||||||||||||
|
Some javascript/style in this post has been disabled (why?)
Hi
all, Here’s
what I want to do: I have an intranet site for my organisation currently up and
running which I would like to upgrade. The current site is Plone version 2.0.5
(with 5Gb of data) and I would like to take it to one of the more recent 3.x
versions. I have a server for a test site and then a development site which
have an instances of the newer Plone version installed on each. I’ll just
muck around with the test for Plone exploration and the development one will
have stuff migrated to it. I’m
running on the assumption that to do so I need to first do an intermediary upgrade
to either 2.1 or 2.5 and then upgrade to 3.x. I have read the upgrade guide on
plone.org but I think this makes too many assumptions about the reader’s
abilities. I am completely new to Plone myself. The
following is what I thought to be a legitimate way to proceed 1.
Have
installations of plone 2.5 and 3.x installed 2.
Copy
data.fs (just that file?) to where its stored in 2.5 replacing the old data.fs 3.
Use
the portal_migration tool -> migrate to convert the content to 2.5 format. 4.
Copy
data.fs from the 2.5 location to the 3.x location and doing the same. I’ve
been trying to first practice this with instances that I’ve installed (using
the windows installer) onto a virtual computer utilizing some dummy data that I
came up with on the fly. (All on 8080 but just one running at once). When
I did this from the 2.5 to the 3.3.1, start the 3.3.1 instance and try to open
up the ZMI it complains that it can’t access the page. When I then chose
to instead copy all four files data.fs, data.fs.index, data.fs.tmp,
data.fs.lock to the 3.3.1 instance it says “we’re sorry but there
seems to be an error” the provided code matched this in the log: 2009-11-04T11:18:22 ERROR Zope.SiteErrorLog
1257293902.010.65774163263
http://localhost:8080/acl_users/credentials_cookie_auth/require_login Traceback (innermost last): Module ZPublisher.Publish, line 119,
in publish Module ZPublisher.mapply, line 88, in
mapply Module ZPublisher.Publish, line 42, in
call_object Module
Products.CMFCore.FSPythonScript, line 140, in __call__ Module Shared.DC.Scripts.Bindings,
line 313, in __call__ Module Shared.DC.Scripts.Bindings,
line 350, in _bindAndExec Module Products.CMFCore.FSPythonScript,
line 196, in _exec Module None, line 10, in require_login - <FSPythonScript at
/Plone/require_login used for /Plone/acl_users/credentials_cookie_auth> - Line 10 Module
Products.CMFFormController.FSControllerPageTemplate, line 90, in __call__ Module
Products.CMFFormController.BaseControllerPageTemplate, line 31, in _call Module Shared.DC.Scripts.Bindings,
line 313, in __call__ Module Shared.DC.Scripts.Bindings,
line 350, in _bindAndExec Module
Products.CMFCore.FSPageTemplate, line 216, in _exec Module
Products.CMFCore.FSPageTemplate, line 155, in pt_render Module
Products.PageTemplates.PageTemplate, line 98, in pt_render Module zope.pagetemplate.pagetemplate,
line 117, in pt_render Module zope.tal.talinterpreter, line
271, in __call__ Module zope.tal.talinterpreter, line
346, in interpret Module zope.tal.talinterpreter, line
891, in do_useMacro Module zope.tal.talinterpreter, line
346, in interpret Module zope.tal.talinterpreter, line
536, in do_optTag_tal Module zope.tal.talinterpreter, line
521, in do_optTag Module zope.tal.talinterpreter, line
516, in no_tag Module zope.tal.talinterpreter, line
346, in interpret Module zope.tal.talinterpreter, line
891, in do_useMacro Module zope.tal.talinterpreter, line
346, in interpret Module zope.tal.talinterpreter, line
586, in do_setLocal_tal Module zope.tales.tales, line 696, in
evaluate - URL:
file:c:\ploneformigrate\buildout-cache\eggs\plone-3.3.1-py2.4.egg\Products\CMFPlone\skins\plone_templates\global_defines.pt - Line 8, Column 0 - Expression: <PathExpr
standard:u'plone_view/globalize'> - Names: {'container':
<PloneSite at /Plone>,
'context': <PloneSite at /Plone>,
'default': <object object at 0x007CA528>, 'here':
<PloneSite at /Plone>, 'loop':
{},
'nothing': None,
'options': {'args': (),
'state': <Products.CMFFormController.ControllerState.ControllerState object
at 0x070AF530>},
'repeat': <Products.PageTemplates.Expressions.SafeMapping object at
0x06772D28>,
'request': <HTTPRequest, URL=http://localhost:8080/acl_users/credentials_cookie_auth/require_login>, 'root':
<Application at >,
'template': <FSControllerPageTemplate at /Plone/login_form>,
'traverse_subpath': [], 'user':
<SpecialUser 'Anonymous User'>} Module zope.tales.expressions, line
217, in __call__ Module
Products.PageTemplates.Expressions, line 163, in _eval Module
Products.PageTemplates.Expressions, line 125, in render Module
Products.CMFPlone.browser.ploneview, line 74, in globalize Module Products.CMFPlone.browser.ploneview,
line 139, in _initializeData Module
Products.CMFPlone.browser.ploneview, line 527, in have_portlets Module zope.component._api, line 207,
in getUtility ComponentLookupError: (<InterfaceClass
plone.portlets.interfaces.IPortletManager>, 'plone.leftcolumn') A
rather difficult to follow thing but if the first line is anything to go on I’m
mighty confused since whilst I installed each instance separately, I used
identical username and password for each for simplicity. I
had previously made a copy of what was in the plone 3 file-storage area so
copied that back into the filestorage area and that seemed to return it to a
state of normality but still leaves me with the same issue. I
can’t imagine how this might be important but just in case, when using
the virtual computer (via VMware, xp-sp3 installed on it, if you’re
interested), the buildout failed to access the servers to get add-on products
which I suspect to be a proxy issue since an identical version with an
identical buildout.cfg was used perfectly well on my home computer. If this has
no impact on upgrade or migration then don’t worry too much as I don’t
feel it will be an issue using the server site. I’m
only really interested in migrating the content across as the site wasn’t
using many products and those that it was using predominantly are redundant or not
tested with Plone 3.x. Since the alternative is re-uploading everything by hand
any advice you guys could give me (even if it doesn’t lead to a complete
solution) would be greatly appreciated. Thanks
in advance, Cheers, Phillip _______________________________________________ Setup mailing list [hidden email] http://lists.plone.org/mailman/listinfo/setup |
||||||||||||||
|
Steve McMahon
()
Re: Proposed upgrade; Plone 2.0.5 to 3.x
|
|
||||||||||||
|
Hi Phillip,
You may want to write to the plone-users list; this list has a smaller audience and is mainly concerned with initial setup. The problem you're seeing is likely coming from something in the theme (skin) customization. Try removing everything from the portal_skins/custom folder, or uninstalling any theme product you may have. You can worry about skinning after the data migration. On Tue, Nov 3, 2009 at 5:03 PM, Phillip Abramson <[hidden email]> wrote:
_______________________________________________ Setup mailing list [hidden email] http://lists.plone.org/mailman/listinfo/setup |
||||||||||||||
|
|
Phillip Abramson
()
RE: Proposed upgrade; Plone 2.0.5 to 3.x
|
|
||||||||||||
|
Some javascript/style in this post has been disabled (why?)
Hi
Steve, I
don’t think it’s skin customisation type things since and
there are currently no third party products installed. If
I get a similar problem in the proper migration I’ll I’m
sure this is the wrong place to say it but just in I
get the feeling that most of the documentation on They
need specifics of how to do things and where Thanks, Phillip From: [hidden email]
[mailto:[hidden email]] On Behalf Of Steve McMahon Hi Phillip, On Tue, Nov 3, 2009 at 5:03 PM, Phillip Abramson <[hidden email]> wrote: Hi all, Here’s what I want to do: I have an intranet
site for my organisation currently up and running which I would like to
upgrade. The current site is Plone version 2.0.5 (with 5Gb of data) and I would
like to take it to one of the more recent 3.x versions. I have a server for a
test site and then a development site which have an instances of the newer
Plone version installed on each. I’ll just muck around with the test for
Plone exploration and the development one will have stuff migrated to it. I’m running on the assumption that to do so I
need to first do an intermediary upgrade to either 2.1 or 2.5 and then upgrade
to 3.x. I have read the upgrade guide on plone.org but I think this makes too many assumptions about
the reader’s abilities. I am completely new to Plone myself. The following is what I thought to be a legitimate way
to proceed 1.
Have installations of plone 2.5 and 3.x
installed 2.
Copy data.fs (just that file?) to where
its stored in 2.5 replacing the old data.fs 3.
Use the portal_migration tool ->
migrate to convert the content to 2.5 format. 4.
Copy data.fs from the 2.5 location to the
3.x location and doing the same. I’ve been trying to first practice this with
instances that I’ve installed (using the windows installer) onto a
virtual computer utilizing some dummy data that I came up with on the fly. (All
on 8080 but just one running at once). When I did this from the 2.5 to the 3.3.1, start the
3.3.1 instance and try to open up the ZMI it complains that it can’t
access the page. When I then chose to instead copy all four files data.fs,
data.fs.index, data.fs.tmp, data.fs.lock to the 3.3.1 instance it says
“we’re sorry but there seems to be an error” the provided
code matched this in the log: 2009-11-04T11:18:22 ERROR
Zope.SiteErrorLog 1257293902.010.65774163263 http://localhost:8080/acl_users/credentials_cookie_auth/require_login Traceback (innermost
last): Module
ZPublisher.Publish, line 119, in publish Module
ZPublisher.mapply, line 88, in mapply Module
ZPublisher.Publish, line 42, in call_object Module
Products.CMFCore.FSPythonScript, line 140, in __call__ Module
Shared.DC.Scripts.Bindings, line 313, in __call__ Module
Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module Products.CMFCore.FSPythonScript,
line 196, in _exec Module None, line
10, in require_login -
<FSPythonScript at /Plone/require_login used for
/Plone/acl_users/credentials_cookie_auth> - Line 10 Module
Products.CMFFormController.FSControllerPageTemplate, line 90, in __call__ Module
Products.CMFFormController.BaseControllerPageTemplate, line 31, in _call Module
Shared.DC.Scripts.Bindings, line 313, in __call__ Module
Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module
Products.CMFCore.FSPageTemplate, line 216, in _exec Module
Products.CMFCore.FSPageTemplate, line 155, in pt_render Module
Products.PageTemplates.PageTemplate, line 98, in pt_render Module
zope.pagetemplate.pagetemplate, line 117, in pt_render Module
zope.tal.talinterpreter, line 271, in __call__ Module
zope.tal.talinterpreter, line 346, in interpret Module
zope.tal.talinterpreter, line 891, in do_useMacro Module
zope.tal.talinterpreter, line 346, in interpret Module
zope.tal.talinterpreter, line 536, in do_optTag_tal Module
zope.tal.talinterpreter, line 521, in do_optTag Module
zope.tal.talinterpreter, line 516, in no_tag Module
zope.tal.talinterpreter, line 346, in interpret Module
zope.tal.talinterpreter, line 891, in do_useMacro Module
zope.tal.talinterpreter, line 346, in interpret Module
zope.tal.talinterpreter, line 586, in do_setLocal_tal Module
zope.tales.tales, line 696, in evaluate - URL:
file:c:\ploneformigrate\buildout-cache\eggs\plone-3.3.1-py2.4.egg\Products\CMFPlone\skins\plone_templates\global_defines.pt - Line 8,
Column 0 -
Expression: <PathExpr standard:u'plone_view/globalize'> - Names:
{'container': <PloneSite at /Plone>,
'context': <PloneSite at /Plone>,
'default': <object object at 0x007CA528>,
'here': <PloneSite at /Plone>,
'loop': {},
'nothing': None,
'options': {'args': (),
'state': <Products.CMFFormController.ControllerState.ControllerState object
at 0x070AF530>},
'repeat': <Products.PageTemplates.Expressions.SafeMapping object at
0x06772D28>,
'request': <HTTPRequest, URL=http://localhost:8080/acl_users/credentials_cookie_auth/require_login>,
'root': <Application at >,
'template': <FSControllerPageTemplate at /Plone/login_form>,
'traverse_subpath': [],
'user': <SpecialUser 'Anonymous User'>} Module
zope.tales.expressions, line 217, in __call__ Module
Products.PageTemplates.Expressions, line 163, in _eval Module
Products.PageTemplates.Expressions, line 125, in render Module
Products.CMFPlone.browser.ploneview, line 74, in globalize Module
Products.CMFPlone.browser.ploneview, line 139, in _initializeData Module
Products.CMFPlone.browser.ploneview, line 527, in have_portlets Module
zope.component._api, line 207, in getUtility ComponentLookupError:
(<InterfaceClass plone.portlets.interfaces.IPortletManager>,
'plone.leftcolumn') A rather difficult to follow thing but if the first
line is anything to go on I’m mighty confused since whilst I installed
each instance separately, I used identical username and password for each for
simplicity. I had previously made a copy of what was in the plone
3 file-storage area so copied that back into the filestorage area and that
seemed to return it to a state of normality but still leaves me with the same
issue. I can’t imagine how this might be important but
just in case, when using the virtual computer (via VMware, xp-sp3 installed on
it, if you’re interested), the buildout failed to access the servers to
get add-on products which I suspect to be a proxy issue since an identical
version with an identical buildout.cfg was used perfectly well on my home
computer. If this has no impact on upgrade or migration then don’t worry
too much as I don’t feel it will be an issue using the server site. I’m only really interested in migrating the
content across as the site wasn’t using many products and those that it
was using predominantly are redundant or not tested with Plone 3.x. Since the
alternative is re-uploading everything by hand any advice you guys could give
me (even if it doesn’t lead to a complete solution) would be greatly
appreciated. Thanks in advance, Cheers, Phillip
_______________________________________________ Setup mailing list [hidden email] http://lists.plone.org/mailman/listinfo/setup |
||||||||||||||
|
Ricardo Newbery-2
()
Re: Proposed upgrade; Plone 2.0.5 to 3.x
|
|
||||||||||||
|
In reply to this post
by Phillip Abramson
On Nov 3, 2009, at 5:03 PM, Phillip Abramson wrote: > Hi all, > > Here’s what I want to do: I have an intranet site for my > organisation currently up and running which I would like to upgrade. > The current site is Plone version 2.0.5 (with 5Gb of data) and I > would like to take it to one of the more recent 3.x versions. I have > a server for a test site and then a development site which have an > instances of the newer Plone version installed on each. I’ll just > muck around with the test for Plone exploration and the development > one will have stuff migrated to it. > > I’m running on the assumption that to do so I need to first do an > intermediary upgrade to either 2.1 or 2.5 and then upgrade to 3.x. I > have read the upgrade guide on plone.org but I think this makes too > many assumptions about the reader’s abilities. I am completely new > to Plone myself. > Not sure what you mean by this criticism of the upgrade guide. Are you looking at the same document I see... http://plone.org/documentation/manual/upgrade-guide ? In any case, your assumption is correct.... upgrade to 2.5.x first, then 3.x. This is also described in the guide... http://plone.org/documentation/manual/upgrade-guide/version/upgrade-pre-2.5-releases-to-the-latest-release > The following is what I thought to be a legitimate way to proceed > > 1. Have installations of plone 2.5 and 3.x installed > > 2. Copy data.fs (just that file?) to where its stored in 2.5 > replacing the old data.fs > > 3. Use the portal_migration tool -> migrate to convert the > content to 2.5 format. > > 4. Copy data.fs from the 2.5 location to the 3.x location and > doing the same. > These are the basic steps alright. But if you have third-party products installed, modified templates, or other customizations, then you will probably need to do a few more steps in addition. > I’ve been trying to first practice this with instances that I’ve > installed (using the windows installer) onto a virtual computer > utilizing some dummy data that I came up with on the fly. (All on > 8080 but just one running at once). > > When I did this from the 2.5 to the 3.3.1, start the 3.3.1 instance > and try to open up the ZMI it complains that it can’t access the > page. When I then chose to instead copy all four files data.fs, > data.fs.index, data.fs.tmp, data.fs.lock to the 3.3.1 instance it > says “we’re sorry but there seems to be an error” the provided code > matched this in the log: > > 2009-11-04T11:18:22 ERROR Zope.SiteErrorLog > 1257293902.010.65774163263 http://localhost:8080/acl_users/credentials_cookie_auth/require_login > > Traceback (innermost last): > Something about this url looks suspicious. How do you reach the Zope root and where is the Plone instance relative to this root? A typical Windows installation sets up two ports: port 8080 to reach the zope root and port 80 to reach the plone subdirectory. The Plone site can also be reached through port 8080 by navigating to the Plone subdirectory. It looks like you were redirected to http://localhost:8080/acl_users/credentials_cookie_auth/require_login which suggests that localhost:8080 gives you the root of your Plone site not your Zope root. The Plone login form (cookie-based login) may not work in a not-yet- migrated site. I suppose sometimes the authentication credentials from the previous install will "just work" with the new install but I can imagine several situations where it will not. You probably need to re-login using the Zope basic authentication process. This means first figuring out the proper URL to reach the Zope root. > I can’t imagine how this might be important but just in case, when > using the virtual computer (via VMware, xp-sp3 installed on it, if > you’re interested), the buildout failed to access the servers to get > add-on products which I suspect to be a proxy issue since an > identical version with an identical buildout.cfg was used perfectly > well on my home computer. If this has no impact on upgrade or > migration then don’t worry too much as I don’t feel it will be an > issue using the server site. > Probably not relevant but did you check to see if the new Plone install actually worked before replacing the virgin Data.fs with the to-be-migrated version? Ric _______________________________________________ Setup mailing list [hidden email] http://lists.plone.org/mailman/listinfo/setup |
||||||||||||||
|
|
Phillip Abramson
()
RE: Proposed upgrade; Plone 2.0.5 to 3.x
|
|
||||||||||||
|
Hi Ric,
"Not sure what you mean by this criticism of the upgrade guide. Are you looking at the same document I see... http://plone.org/documentation/manual/upgrade-guide ?" One criticism would be length, whilst it's all useful information it's imposing when you first see it. Especially with dot points one should be very careful with their length. Long paragraphs don't get read or at least not properly unless you know to look there. This requires rereading to find potentially vital pieces of information. Also occasionally bits of coding are given in the documentation or command line stuff without saying where put it or run it from. (not an issue with the upgrade guide but others I think, this may simply be due to documents looking wordy though and I may simply be missing it) "Probably not relevant but did you check to see if the new Plone install actually worked before replacing the virgin Data.fs with the to-be-migrated version?" Yep, worked fine before and fine after when I copied back the original data "The Plone login form (cookie-based login) may not work in a not-yet-migrated site. I suppose sometimes the authentication credentials from the previous install will "just work" with the new install but I can imagine several situations where it will not. You probably need to re-login using the Zope basic authentication process. This means first figuring out the proper URL to reach the Zope root." Do you mean "localhost:8080/manage"? or "localhost:8080/manage_main"? or something like that? I did try navigating directly to them both but simply got redirected back. I managed to avoid this issue recently by instead making a new mime type in the to be migrated plone site for text\x-web-intelligent and exported and imported into the 3.3.1 version and it looks like I can export from 2.0.5 to 2.5 without a hitch. I don't know if it's really a good idea to use import export for the 5Gb of data that will be involved in the real migration. Maybe doing it in small chunks rather than the full Plone object in one go would solve that. Thanks, Phillip -----Original Message----- From: Ricardo Newbery [mailto:[hidden email]] Sent: Wednesday, 4 November 2009 6:31 PM To: Phillip Abramson Cc: [hidden email] Subject: Re: [Setup] Proposed upgrade; Plone 2.0.5 to 3.x On Nov 3, 2009, at 5:03 PM, Phillip Abramson wrote: > Hi all, > > Here's what I want to do: I have an intranet site for my > organisation currently up and running which I would like to upgrade. > The current site is Plone version 2.0.5 (with 5Gb of data) and I > would like to take it to one of the more recent 3.x versions. I have > a server for a test site and then a development site which have an > instances of the newer Plone version installed on each. I'll just > muck around with the test for Plone exploration and the development > one will have stuff migrated to it. > > I'm running on the assumption that to do so I need to first do an > intermediary upgrade to either 2.1 or 2.5 and then upgrade to 3.x. I > have read the upgrade guide on plone.org but I think this makes too > many assumptions about the reader's abilities. I am completely new > to Plone myself. > Not sure what you mean by this criticism of the upgrade guide. Are you looking at the same document I see... http://plone.org/documentation/manual/upgrade-guide ? In any case, your assumption is correct.... upgrade to 2.5.x first, then 3.x. This is also described in the guide... http://plone.org/documentation/manual/upgrade-guide/version/upgrade-pre- 2.5-releases-to-the-latest-release > The following is what I thought to be a legitimate way to proceed > > 1. Have installations of plone 2.5 and 3.x installed > > 2. Copy data.fs (just that file?) to where its stored in 2.5 > replacing the old data.fs > > 3. Use the portal_migration tool -> migrate to convert the > content to 2.5 format. > > 4. Copy data.fs from the 2.5 location to the 3.x location and > doing the same. > These are the basic steps alright. But if you have third-party products installed, modified templates, or other customizations, then you will probably need to do a few more steps in addition. > I've been trying to first practice this with instances that I've > installed (using the windows installer) onto a virtual computer > utilizing some dummy data that I came up with on the fly. (All on > 8080 but just one running at once). > > When I did this from the 2.5 to the 3.3.1, start the 3.3.1 instance > and try to open up the ZMI it complains that it can't access the > page. When I then chose to instead copy all four files data.fs, > data.fs.index, data.fs.tmp, data.fs.lock to the 3.3.1 instance it > says "we're sorry but there seems to be an error" the provided code > matched this in the log: > > 2009-11-04T11:18:22 ERROR Zope.SiteErrorLog > 1257293902.010.65774163263 > > Traceback (innermost last): > ... [snip] Something about this url looks suspicious. How do you reach the Zope root and where is the Plone instance relative to this root? A typical Windows installation sets up two ports: port 8080 to reach the zope root and port 80 to reach the plone subdirectory. The Plone site can also be reached through port 8080 by navigating to the Plone subdirectory. It looks like you were redirected to http://localhost:8080/acl_users/credentials_cookie_auth/require_login which suggests that localhost:8080 gives you the root of your Plone site not your Zope root. The Plone login form (cookie-based login) may not work in a not-yet- migrated site. I suppose sometimes the authentication credentials from the previous install will "just work" with the new install but I can imagine several situations where it will not. You probably need to re-login using the Zope basic authentication process. This means first figuring out the proper URL to reach the Zope root. > I can't imagine how this might be important but just in case, when > using the virtual computer (via VMware, xp-sp3 installed on it, if > you're interested), the buildout failed to access the servers to get > add-on products which I suspect to be a proxy issue since an > identical version with an identical buildout.cfg was used perfectly > well on my home computer. If this has no impact on upgrade or > migration then don't worry too much as I don't feel it will be an > issue using the server site. > Probably not relevant but did you check to see if the new Plone install actually worked before replacing the virgin Data.fs with the to-be-migrated version? Ric _______________________________________________ Setup mailing list [hidden email] http://lists.plone.org/mailman/listinfo/setup |
||||||||||||||
|
|
Ricardo Newbery-2
()
Re: Proposed upgrade; Plone 2.0.5 to 3.x
|
|
||||||||||||
|
On Nov 4, 2009, at 5:48 PM, Phillip Abramson wrote: > "Not sure what you mean by this criticism of the upgrade guide. > > Are you looking at the same document I see... > http://plone.org/documentation/manual/upgrade-guide ?" > > One criticism would be length, whilst it's all useful information it's > imposing when you first see it. Especially with dot points one > should be > very careful with their length. Long paragraphs don't get read or at > least not properly unless you know to look there. This requires > rereading to find potentially vital pieces of information. I agree the length may be a bit imposing. But I'm not sure how you would get around that considering the long history of Plone and the many changes since it first came out. I suppose the document could use some editing; I'm sure the authors would be very happy to receive any concrete suggestions for improvements. > "The Plone login form (cookie-based login) may not work in a > not-yet-migrated site. I suppose sometimes the authentication > credentials from the previous install will "just work" with the > new > install but I can imagine several situations where it will not. > You > probably need to re-login using the Zope basic authentication > process. This means first figuring out the proper URL to reach > the Zope root." > > Do you mean "localhost:8080/manage"? or "localhost:8080/ > manage_main"? or > something like that? I did try navigating directly to them both but > simply got redirected back. Either "manage" or "manage_main". If a non-authenticated request came in for a ZMI page in the zope root rather than the plone root, you would get a standard basic authentication request response and not the plone login form. The fact that you are getting the plone login form (which then breaks) suggest that you are not actually requesting the ZMI page in the zope root. Perhaps an accessrule or VHM mapping is redirecting your port 8080 requests to the Plone subdirectory. > I managed to avoid this issue recently by instead making a new mime > type > in the to be migrated plone site for text\x-web-intelligent and > exported > and imported into the 3.3.1 version and it looks like I can export > from > 2.0.5 to 2.5 without a hitch. I don't know if it's really a good > idea to > use import export for the 5Gb of data that will be involved in the > real > migration. Maybe doing it in small chunks rather than the full Plone > object in one go would solve that. The export/import option you see in the ZMI is usually not recommended for moving content across upgraded instances. The items exported this way are very context sensitive and generally require that you match the zope environments in both setups very closely. There are other ways to export/import content that are less context sensitive but, as far as I know, nothing that works out-of-the-box without some prep work. In any case, I'm not sure why you want to do this. Are these custom content types? If so, then you still need to upgrade the third-party product that contains the content type code, which hopefully also provides you with an upgrade path if needed. If these are built-in content types, then the regular Plone migration process is all you need. Ric _______________________________________________ Setup mailing list [hidden email] http://lists.plone.org/mailman/listinfo/setup |
||||||||||||||
|
|
Phillip Abramson
()
RE: Proposed upgrade; Plone 2.0.5 to 3.x
|
|
||||||||||||
|
I agree the length may be a bit imposing. But I'm not sure how
you would get around that considering the long history of Plone and the many changes since it first came out. I suppose the document could use some editing; I'm sure the authors would be very happy to receive any concrete suggestions for improvements. I don't know if I could give concrete advice, it's usability, you only notice when its difficult and don't even think about it when it's not. but you can't usually tell someone how to change it. Only things I can think of are, just space things out more, lists (more readable than paragraphs), and clear signposting by which I mean "<b>Item:</b> bla bla bla bla" "<b>reasoning:</b> bla bla bla", etc. rather than putting them together in several sentences The fact that you are getting the plone login form (which then breaks) suggest that you are not actually requesting the ZMI page in the zope root. Perhaps an accessrule or VHM mapping is redirecting your port 8080 requests to the Plone subdirectory. In which case I'm not quite sure what to do about it I'm not sure why you want to do this. Are these custom content types? If so, then you still need to upgrade the third- party product that contains the content type code, which hopefully also provides you with an upgrade path if needed. If these are built-in content types, then the regular Plone migration process is all you need. Not custom content, it's all standard stuff, I did the import/export just for the moment whilst the data.fs way doesn't work. I had to make a mime type since when I imported the content it complained about not having text/x-web-intelligent so I just made one which worked and no content was corrupt or anything. -----Original Message----- From: Ricardo Newbery [mailto:[hidden email]] Sent: Thursday, 5 November 2009 2:13 PM To: Phillip Abramson Cc: [hidden email] Subject: Re: [Setup] Proposed upgrade; Plone 2.0.5 to 3.x On Nov 4, 2009, at 5:48 PM, Phillip Abramson wrote: > "Not sure what you mean by this criticism of the upgrade guide. > > Are you looking at the same document I see... > http://plone.org/documentation/manual/upgrade-guide ?" > > One criticism would be length, whilst it's all useful information it's > imposing when you first see it. Especially with dot points one > should be > very careful with their length. Long paragraphs don't get read or at > least not properly unless you know to look there. This requires > rereading to find potentially vital pieces of information. I agree the length may be a bit imposing. But I'm not sure how you would get around that considering the long history of Plone and the many changes since it first came out. I suppose the document could use some editing; I'm sure the authors would be very happy to receive any concrete suggestions for improvements. > "The Plone login form (cookie-based login) may not work in a > not-yet-migrated site. I suppose sometimes the authentication > credentials from the previous install will "just work" with the > new > install but I can imagine several situations where it will not. > You > probably need to re-login using the Zope basic authentication > process. This means first figuring out the proper URL to reach > the Zope root." > > Do you mean "localhost:8080/manage"? or "localhost:8080/ > manage_main"? or > something like that? I did try navigating directly to them both but > simply got redirected back. Either "manage" or "manage_main". If a non-authenticated request came in for a ZMI page in the zope root rather than the plone root, you would get a standard basic authentication request response and not the plone login form. The fact that you are getting the plone login form (which then breaks) suggest that you are not actually requesting the ZMI page in the zope root. Perhaps an accessrule or VHM mapping is redirecting your port 8080 requests to the Plone subdirectory. > I managed to avoid this issue recently by instead making a new mime > type > in the to be migrated plone site for text\x-web-intelligent and > exported > and imported into the 3.3.1 version and it looks like I can export > from > 2.0.5 to 2.5 without a hitch. I don't know if it's really a good > idea to > use import export for the 5Gb of data that will be involved in the > real > migration. Maybe doing it in small chunks rather than the full Plone > object in one go would solve that. The export/import option you see in the ZMI is usually not recommended for moving content across upgraded instances. The items exported this way are very context sensitive and generally require that you match the zope environments in both setups very closely. There are other ways to export/import content that are less context sensitive but, as far as I know, nothing that works out-of-the-box without some prep work. In any case, I'm not sure why you want to do this. Are these custom content types? If so, then you still need to upgrade the third-party product that contains the content type code, which hopefully also provides you with an upgrade path if needed. If these are built-in content types, then the regular Plone migration process is all you need. Ric _______________________________________________ Setup mailing list [hidden email] http://lists.plone.org/mailman/listinfo/setup |
||||||||||||||
|
|
Ricardo Newbery-2
()
Re: Proposed upgrade; Plone 2.0.5 to 3.x
|
|
||||||||||||
|
On Nov 8, 2009, at 2:15 PM, Phillip Abramson wrote: > The fact that you are getting the plone login form > (which then breaks) suggest that you are not actually requesting > > the ZMI page in the zope root. Perhaps an accessrule or VHM > mapping is redirecting your port 8080 requests to the Plone > subdirectory. > > In which case I'm not quite sure what to do about it I'm not too familiar with the current Windows install. Does it come with a controller to set "management" and "plone" ports? You are looking for the management port. Alternately, look in the "zope.conf" of your instance for "address" under the "http-server" section of the config (if using buildout to generate the instance, "zope.conf" can usually be found under "[buildout root]/parts/instance/etc/zope.conf"). The "address" directives will tell you which ports the instance is listening to. If it's listening to multiple ports, one of them is probably the management port. However, it's possible that a misconfiguration is sending all ports to the Plone subdirectory. In this case, you will need to temporarily suppress the function that is causing this. There are three possible culprits so there are three different bypass routes: To suppress an accessrule (the most likely case), set "suppress-all- access-rules" to "on" in the zope config and restart. To remove the accessrule permanently, log into the ZMI, select "Set Access Rule" in the add menu and remove the access rule. To suppress a siteroot (very unlikely), set "suppress-all-site-roots" to "on" in the zope config and restart. To remove the siteroot permanently, find the siteroot object in the ZMI root and delete it. To suppress a "Virtual Host Monster" mapping, access the ZMI with the raw IP address instead of the hostname. To remove a VHM mapping, find the VHM object (usually in the ZMI root, usually labeled "virtual_hosting"), navigate to its "mapping" tab, and delete the errant mapping (most folks don't use the mapping feature). Ric _______________________________________________ Setup mailing list [hidden email] http://lists.plone.org/mailman/listinfo/setup |
||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
