Importing mojoportal 1.x site data into 2.x install

1/20/2009 8:15:36 AM

Rene Mayrhofer

Total Posts 29

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Hi Joe,

Deleting these lines from mp_modulesettings did the trick, the Setup page now ran through successfully. Thanks for helping me debug it this far! Your excellent support is one of the reasons why I like mojoportal so much.

Concerning skinning, it seems that only part of the skin is applied: When I change the skin and then look at the page source, I see that the style files seem to be selected correctly, e.g.

link href='http://localhost/Data/Sites/1/skins/extjs-viewport1/style.css' type='text/css' rel='stylesheet' />
<link href='http://localhost/Data/Sites/1/skins/extjs-viewport1/styletext.css' type='text/css' rel='stylesheet' title='Normaltext' />
<link href='http://localhost/Data/Sites/1/skins/extjs-viewport1/styleprinter.css' type='text/css' rel='stylesheet' media='print' />
<link href='http://localhost/Data/Sites/1/skins/extjs-viewport1/stylemenu.css' type='text/css' rel='stylesheet' media='screen' />
<link href='http://localhost/Data/Sites/1/skins/extjs-viewport1/styletreeview.css' type='text/css' rel='stylesheet' media='screen' />

or


<link href='http://localhost/Data/Sites/1/skins/extjs-viewport1/styletreeview.css' type='text/css' rel='stylesheet' media='screen' />

This also shows in the way the top menu is painted. Although still horribly broken, I see that it changes depending on the selected skin. On the other hand, the whole page "master" layout does not change, as evident e.g. in the footer part:

        <a title="Visit the web site of the designer" href="http://www.styleshout.com/">Design by styleshout</a>

The weird thing is that with the same installation on fht filesystem, skins work with the empty default database, just not with the converted one. So it's (IMHO) unlikely to be a filesystem (permissions, links, whatever) reason.

best regards,

Rene

1/20/2009 8:23:39 AM

Rene Mayrhofer

Total Posts 29

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Hi Joe,

I now tried the full ...csshandler... URL (which I got from the footer where it links to jigsaw.w3.org) directly. No error, just a (long) and seemingly valid CSS line. The URL matches the skin I selected last (http://localhost/Data/Sites/1/skins/extjs-viewport1/csshandler.ashx?skin=extjs-viewport1&config=style.config).

best regards,

Rene

1/20/2009 8:27:21 AM

Joe Audette

Total Posts 18439

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

The only reason you see urls to static css files is if you have

The default is true and you end up with a most css combined into one url that looks like ...csshandler.ashx?....

I don't recommend using extjs-viewport skin that one is experimental.

You may need to clear your browser cache frequently in solving css problems.

Something seems not right, style.css file no longer exists and the latest code does not write that into the page if StyleSheetCombiner is used in the layout.master (and it is if you have the correct files)

Are you sure you are using mojoPortal 2.2.8.2-c? If so then I think your skins under /Data/Sites/[SiteID]/skins is not correct versions in spite of what the diff says, it must be different than in the clean install. View the source of the clean install page and it should not output a link to style.css

Best if you can get it to work with CombineCSS = true

Hope it helps,

Joe

1/20/2009 8:31:54 AM

Rene Mayrhofer

Total Posts 29

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Dear Joe,

I'll try to debug it further and use all your hints. Right now I'll need to run to the next lecture, but I hope to continue with my conversion later in the evening.

Thanks,

Rene

1/20/2009 3:32:21 PM

Rene Mayrhofer

Total Posts 29

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Hi Joe,

is set in Web.conf and I can't see anything otherwise. I have not modified Web.config besides adding my database connection details. This seems to be acknowledged by the fact that I get a single, long line CSS by the csshandler.aspx link.

At the moment, I can reproducable switch between the two cases:

- Using the empty default database setting (with just 2 pages added and the style changed to styleshout-refresh) gives me the working site with the following header:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="ctl00_Head1"><title>
	Rene Mayrhofer - Home
</title>
<link rel='stylesheet' type='text/css' href='http://ajax.googleapis.com/ajax/libs/yui/2.6.0/build/tabview/assets/skins/sam/tabview.css' />
<link href='http://localhost/Data/Sites/1/skins/styleshout-refresh/csshandler.ashx?skin=styleshout-refresh&amp;config=style.config&amp;add=' type='text/css' rel='stylesheet' />
<!--[if lt IE 7]>
<link rel="stylesheet" href="http://localhost/Data/Sites/1/skins/styleshout-refresh/IESpecific.css" type="text/css" id="IEMenuCSS" />
<![endif]-->
<!--[if gt IE 6]>
<link rel="stylesheet" href="http://localhost/Data/Sites/1/skins/styleshout-refresh/IE7Specific.css" type="text/css" id="IE7MenuCSS" />
<![endif]-->

- Using my converted database (now with the same style set) gives me the broken layout with this header:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="ctl00_Head1"><title>
	Rene Mayrhofer - Einstellungen Website
</title><link rel="stylesheet" type="text/css" href="../App_DesignTimeStyle/style.css" /><link rel="stylesheet" type="text/css" href="../App_DesignTimeStyle/blogmodule.css" /><link rel="stylesheet" type="text/css" href="../App_DesignTimeStyle/aspcalendar.css" /><link rel="stylesheet" type="text/css" href="../App_DesignTimeStyle/stylemenu.css" /><link rel="stylesheet" type="text/css" href="../App_DesignTimeStyle/styletreeview.css" />
<link href='http://localhost/Data/Sites/1/skins/styleshout-refresh/style.css' type='text/css' rel='stylesheet' />
<link href='http://localhost/Data/Sites/1/skins/styleshout-refresh/styletext.css' type='text/css' rel='stylesheet' title='Normaltext' />
<link href='http://localhost/Data/Sites/1/skins/styleshout-refresh/styleprinter.css' type='text/css' rel='stylesheet' media='print' />
<link href='http://localhost/Data/Sites/1/skins/styleshout-refresh/stylemenu.css' type='text/css' rel='stylesheet' media='screen' />
<link href='http://localhost/Data/Sites/1/skins/styleshout-refresh/styletreeview.css' type='text/css' rel='stylesheet' media='screen' />
<!--[if lt IE 7]>
<link rel="stylesheet" href="http://localhost/Data/Sites/1/skins/styleshout-refresh/IESpecific.css" type="text/css" id="IEMenuCSS" />
<![endif]-->
<!--[if gt IE 6]>
<link rel="stylesheet" href="http://localhost/Data/Sites/1/skins/styleshout-refresh/IE7Specific.css" type="text/css" id="IE7MenuCSS" />
<![endif]-->

To switch between the two cases, I only stop apache2 (with mod_mono), drop the mojoportal database, re-create it, and populate it with either of the dumps, and finally start apache2 again. Ctrl-F5 loading in Firefox triggers the switch. As nothing besides the database changes, I'm pretty sure the mojoportal installation is fine otherwise.

Which DB settings are important for the skinning? Is there anything I could check?

best regards,
Rene

1/20/2009 3:40:40 PM

Joe Audette

Total Posts 18439

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Skin name is set in mp_sites, I would look for any difference between the 2 dbs but probably they are the same and the problem eludes me.

I would try do away with the sym links for folders so its for sure using /Data/Sites/[SiteID]

I'll keep pondering it but it makes no sense to me.

Best,

Joe

1/20/2009 4:01:39 PM

Rene Mayrhofer

Total Posts 29

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Skin name appears to be correct, but I just noticed that the guid in mp_sitesettingsex is all zeros. Could that have something to do with it?

Rene

1/20/2009 4:05:56 PM

Rene Mayrhofer

Total Posts 29

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Other differences in mp_sites: sitealias is set to '\N' for the working (empty) site but to 'p_default' for the broken (updated) one. And the siteguid is also all zeroes in here.

I'll try to do a more thorough comparison of these two based on their SQL dump.

best regards,
Rene

1/20/2009 4:29:31 PM

Joe Audette

Total Posts 18439

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Hi Rene,

SiteAlias is a legacy field it can be safely ignored.

I'm not sure it may be possible that guid issue is the problem, it would be ideal to replace the empty guid with a real guid. It doesn't matter what the guid is, you could copy the one from the good db.

The main thing is after you add it to mp_sites, you need to look at every other table for the field siteguid and if that field is present populate it with the correct one using a query.

The siteguids for your 2 sites need to be different, if you have no other way to generate them, using a new db should generate a new one each time.

Sorry this upgrade is so painful, but its a very old version and so much has changed.

Best,

Joe

1/21/2009 12:08:12 PM

Rene Mayrhofer

Total Posts 29

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Hi Joe,

The siteguid was indeed the issue messing up skinning. I generated two fresh guids with the "uuidgen" utility under Linux and inserted them into the tables like that:

update mp_sites set siteguid='03aa973f-358d-42aa-8164-00c136049a1f' where siteid = '1';
update mp_sites set siteguid='816f7a30-72c1-4eaf-88d1-6d5243974706' where siteid = '2';

I found that for the features/modules I use, tables mp_sites mp_friendlyurls mp_modules mp_pages mp_roles mp_sitehosts mp_sitemoduledefinitions mp_sitesettingsex mp_users needed an update.

The fact that this was possible indicates that there is quite some redudancy in the current database schema (the guids correlate with primary keys) and that it in fact doesn't conform to third normal form. Is there any specific reason for having e.g. the guids in there at all? The risk of inconsistency is a real one (as demonstrated by this failed automatic update).

The missing thing is the member list, which still returns an error:

System.FormatException: Invalid format for Guid.Guid(string).
at System.Guid+GuidParser.ThrowFormatException () [0x00000]
at System.Guid+GuidParser.ParseChar (Char c) [0x00000]
at System.Guid+GuidParser.ParseGuid2 () [0x00000]
at System.Guid+GuidParser.Parse () [0x00000]
at System.Guid..ctor (System.String g) [0x00000]
at mojoPortal.Business.SiteUser.PopulateFromReaderRow (mojoPortal.Business.SiteUser user, IDataReader reader) [0x00000]
at mojoPortal.Business.SiteUser.GetPage (Int32 siteId, Int32 pageNumber, Int32 pageSize, System.String userNameBeginsWith, System.Int32& totalPages) [0x00000]
at mojoPortal.Web.UI.Pages.MemberList.PopulateControls () [0x00000]
at mojoPortal.Web.UI.Pages.MemberList.Page_Load (System.Object sender, System.EventArgs e) [0x00000]
at System.Web.UI.Control.OnLoad (System.EventArgs e) [0x00000]
at mojoPortal.Web.mojoBasePage.OnLoad (System.EventArgs e) [0x00000]
at System.Web.UI.Control.LoadRecursive () [0x00000]
at System.Web.UI.Page.ProcessLoad () [0x00000]
at System.Web.UI.Page.ProcessPostData () [0x00000]
at System.Web.UI.Page.InternalProcessRequest () [0x00000]
at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x00000]

Next, I will try to adapt my skin to the new version and hope to get the update online by the end of this week.

Summarising, the following hints my help others trying to update from mojoporal 1.<old> to 2.x:

- Don't use postgresql 8.3 until the mojoportal data layer can deal with it (8.1 works).
- Watch out for schema changes during upgrade (somewhere along the update scripts, this seems broken).
- Watch out for empty uids in the database after the upgrade.
- Many skins are badly broken when you have sub-menus that are marked to be shown (two that work are e.g. mitchinson-earthy or jsavard-blue).

Thanks for your help so far!

Rene

1/21/2009 12:20:44 PM

Joe Audette

Total Posts 18439

View Posts

Re: Importing mojoportal 1.x site data into 2.x install

Hi Rene,

The reasons for the failure to upgrade smoothly are due the evolution of the project and the imperfections of the upgrade scripts due to historical errors

Yes, there are reasons for this as there are often good reasons for deviating from third normal form, especially in web applications.

The first reason is that it helps make it possible to integrate data from more than one installation and have the ability to restore the relationships even though the integer keys will have to be different. This supports the scenario of 2 companies merging with 2 different sites.

The second and more useful reason is that it makes it possible to do things you can't do with normal table relationships.

For example, I recently implemented a content rating system. Because of using guids I can use the same content rating system to rate articles, products, sites, pages, users, or any other feature where the content has guid identifiers.

Each thing can pass in its own guid and select its ratings, but there is no formal foriegn key relation to the ratings table from any of the tables that store their related ratings there. So many different tables can join to the rating table and get their own ratings.

The same solution will allow me to build a content versioning system, tagging, comments and re-use them across features.

Hope that makes sense to you.

Best,

Joe