Quote:

Ok, gotcha... I'll do that. I'm re-installing right now. Just cleaned out the whole thing and started over.

BAM

Seems that module requires AltSYs to function.

I have a similar problem. Looked at the situation more on my test XOOPS site Modules Administration page:

xoops/modules/system/admin.php?fct=modulesadmin

The page's generated code is weird. There are no doctype, html, or head lines at the top. The generated code just starts with a body tag and ends with a tr tag. My production XOOPS 2.3.3 site page's code looks normal. I suspect that the problem arose with the 2.4.4 update, but I cannot locate or identify what got corrupted.

The page is missing styling and all of the >> or << javascript links in the left sidebar of the admin control panel do NOT work. The "powered by" footer is missing as well.

The other sections on the page are okay. Anyone got an idea what to check?

What is your PHP and MySQL version?
Did you do the file check (see release notes)?
Did you try with the default admin GUI (general preferences)?

ghia, here's the info you requested on my problem with xoops/modules/system/admin.php?fct=modulesadmin

1. phpinfo.php shows:

PHP Version 5.2.12 and MySQL Client API version 5.0.32

2. Yes, I've only been using the default admin GUI.

3. checksum.php with checksum.md5 for full release 2.4.4 (versus an upgrade checksum.md5) results are below. Does anything stand out in particular as relevant? (Note that the current test site was upgraded from 2.3.3 to 2.4.4 and then to 2.4.5 beta.

./backend.php content invalid
./favicon.ico content invalid

./class/module.textsanitizer.php content invalid
./class/pagenav.php content invalid
./class/xoopsstory.php content invalid
./class/xoopstopic.php content invalid
./class/cache/model.php content invalid

./include/license.php content invalid
./include/version.php content invalid

./kernel/object.php content invalid
./kernel/user.php content invalid

./modules/profile/xoops_version.php content invalid
./modules/profile/class/category.php content invalid
./modules/profile/class/field.php content invalid
./modules/profile/class/profile.php content invalid
./modules/profile/class/regstep.php content invalid
./modules/profile/class/visibility.php content invalid

./themes/default/index.html missing !
./themes/default/screenshot.png missing !
./themes/default/style.css content invalid
./themes/default/theme_blockcenter_c.html content invalid
./themes/default/theme_blockcenter_l.html content invalid
./themes/default/theme_blockcenter_r.html content invalid
./themes/default/theme_blockleft.html content invalid
./themes/default/theme_blockright.html content invalid
./themes/default/icons/favicon.ico missing !
./themes/default/icons/favicon.png content invalid

Quote:Not sure this is the right figure. MySQL (server) version?
Quote:I'll rephrase: Are you using the admin theme 'default'? (Opposite to default theme which is 'Oxygen')
3. I think you have to correct the listed files with the archive from 2.4.4 and then clean the caches and try again to update the system module (/modules/system/admin.php?fct=modulesadmin&op=update&module=system).

I found a possible source of the problem with the

xoops/modules/system/admin.php?fct=modulesadmin

page. In the

xoops/modules/system/admin/modulesadmin/modulesadmin.php

file, I commented out all lines in function xoops_module_list() between line 41 xoops_cp_header(); and line 138 xoops_cp_footer(); and formatting and other features were okay. Further study isolated the problem to the for each loop in lines 112 to 136 which displays inactive modules. I gradually removed inactive modules from the modules folder. When I removed protector, the page was fixed!

I am not using protector either in this XOOPS 2.4.5 beta test site or in my XOOPS production 2.3.3 site.

What changed from XOOPS 2.3.3 where there is no such problem?

Why does removing protector in xoops/modules/ (versus in the relocated out of html directory xoops_lib_new/modules/) fix the problem? How can leaving it in the modules folder corrupt the code?

Quote:
Most of the time this is caused by incompatible or missing Protector files in the "xoops_lib". To give you couple potential scenarios:

a) you update XOOPS to a new version, and you copy all the folders to your XOOPS directory, incl. xoops_lib. However, you have already an existing "trust path" directory, to which you point in your mainfile.php. This will cause a problem because XOOPS looks at the the current "trust path" which has older Protector files that don't match the current one

b)you update XOOPS to a new version, and you copy all the folders to your XOOPS directory, incl. xoops_lib. And you delete the protector files from your existing "trust path" directory, to which you point in your mainfile.php. This will cause a problem because XOOPS looks at the the current "trust path" where there are no files

You have to make sure:

a) You have ONLY one set of "trust path" Protector files
b) the mainfile.php points to that directory as your "trust path"

Mamba, neither scenario applies to my situation; so, your reply did not help.

At a detailed technical level, it would appear that the code in the file

xoops/modules/system/admin/modulesadmin/modulesadmin.php

does not handle something gracefully as it lists unloaded modules, as it gets to protector. And why would trust path be an issue in the for each loop in particular?

In mainfile.php, by the way, I've always left

define("XOOPS_TRUST_PATH", XOOPS_PATH);

I trust that still is correct, that is, XOOPS_TRUST_PATH is the same as XOOPS_PATH.

I will study the problem more ...

PM me your site and FTP login/password, and I'll take a look

BTW - I assume, you did run the 2.4.4 "upgrade", right?

And your mainfile.php has the paths for xoops_lib and xoops_data, right?