Hi Joe,

Addendum: if that table is mp_moduledefinitions, then I can't find that null value:

mojoportal=# select featurename,sortorder from mp_moduledefinitions;
          featurename           | sortorder
--------------------------------+-----------
 Html Snippet Include           |       500
 Feature Modules (Admin)        |       502
 Roles (Admin)                  |       505
 Pages                          |       500
 Site Settings (Admin)          |       501
 File Manager (Admin)           |       580
 Friendly Url Manager           |       700
 Url Manager (Admin)            |       700
 HtmlContentFeatureName         |       300
 SiteStatisticsFeatureName      |       500
 BlogFeatureName                |       500
 ContactFormFeatureName         |       500
 EventCalendarFeatureName       |       500
 FeatureName                    |       500
 FolderGalleryFeatureName       |       500
 ForumsFeatureName              |       500
 GoogleMapFeatureName           |       500
 HtmlFragmentIncludeFeatureName |       500
 ImageGalleryFeatureName        |       500
 LinksFeatureName               |       500
 PollFeatureName                |       500
 SharedFilesFeatureName         |       500
 SurveyFeatureName              |       500
 XmlXslFeatureName              |       500
(24 rows)
 

The same is true for mp_moduledefinitionsettings, mp_sitesettingsexdef, and mp_htmlcontent (other tables in which I could find a "sortorder" column). Any hints?

best regards,

Rene

Hi Joe,

He, you're already up :)

To answer your questions:

1. mp_moduledefinitions seems to be ok:

mojoportal=# select * from mp_moduledefinitions where sortorder < 300 or guid is null;
 moduledefid | featurename | controlsrc | sortorder | isadmin | icon | defaultcachetime |guid | resourcefile
-------------+-------------+------------+-----------+---------+------+------------------+------+--------------
(0 rows)
 

2. I'm not sure what you mean by orphan rows in mp_modulesettings. Its current definition is

mojoportal=# \d mp_modulesettings
                                               Table "public.mp_modulesettings"
          Column           |          Type          |                                Modifiers
---------------------------+------------------------+--------------------------------------------------------------------------
 id                        | integer                | not null default nextval(('"mp_modulesettings_id_seq"'::text)::regclass)
 moduleid                  | integer                | not null
 settingname               | character varying(50)  | not null
 settingvalue              | character varying(255) | not null
 controltype               | character varying(50)  |
 regexvalidationexpression | text                   |
 moduleguid                | character varying(36)  |
 settingguid               | character varying(36)  |
 controlsrc                | character varying(255) |
 helpkey                   | character varying(255) |
 sortorder                 | integer                | not null default 100
Indexes:
    "pk_modulesettings" PRIMARY KEY, btree (id)
    "ifk_modulesettings_moduleid" btree (moduleid)
    "mp_modulesettings_ix_modul-0" btree (moduleid, settingname)
Foreign-key constraints:
    "fk_modulesettings_modules" FOREIGN KEY (moduleid) REFERENCES mp_modules(moduleid)
    "fk_modulesettings_modules_fk" FOREIGN KEY (moduleid) REFERENCES mp_modules(moduleid)

and it doesn't seem to contain any non-default entries in sortorder:

mojoportal=# select * from mp_modulesettings where sortorder != 100;
 id | moduleid | settingname | settingvalue | controltype | regexvalidationexpression | moduleguid | settingguid | controlsrc | helpkey | sortorder
----+----------+-------------+--------------+-------------+---------------------------+------------+-------------+------------+---------+-----------
(0 rows)
 

3. Concerning guid columns: There are many of them, and it would take quite some time to check them all. Would it be necessary to check all columns with "guid" in the name or only those that are named exactly "guid" (I assume the former are generally foreign keys and should therefore be filled no matter what)?

The root page of the site does indeed start, but with two major problems right now (without checking any of the details):

4. Skinning seems broken. Although I managed to (using Tab a lot ;) ) change from the default skin to one that would not overlay the whole page with my menu und sub-menu entries (I currently selected jsavard-subblue, which is still broken in terms of the menu layout, but at least restricted to the top part), only the menu seems to change with it. That is, the other elements (general page layout, header image, colors, etc.) seem to remain fixed to the styleshout-techmania style (or something else that looks like the mojoportal 2 default). Is there any database setting that needs to be overwritten to make it work again?

5. I have the same problem as on my eariler try of converting to mojoportal 2: All static HTML content blocks are shown in "encoded" (i.e. HTML) form. I assume the reason is that in my mojoportal 1 database, all HTML content is stored in an escaped form, and thus doesn't get interpreted. What is the best way to change the encoding to the way mojoportal 2 handles it now?

best regards,

Rene

Hi Joe,

I'm still impressed by your speed on following up forum posts...

DB stuff

mojoportal=# Delete from mp_modulesettings where moduleid NOT IN (SELECT moduleid from mp_modules);
DELETE 0
mojoportal=# Delete from mp_modulesettings where moduleid  IN (SELECT moduleid from mp_modules WHERE moduledefid NOT IN (SELECT moduledefid FROM mp_moduledefinitions));
DELETE 0
So, seemingly no orphans -good.

Having been programming for too long now, failing consistency checks definitely make me worry, though ;) I assume the

Ensuring all features are installed in server admin sites... - 00:00:09.9047010

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