Mamba, yes, I ran the 2.4.4 "upgrade" on version 2.3.3b using shell command line to overwrite prior files by extracting the tar.gz package as usual. And mainfile.php has the paths for xoops_lib and xoops_data, as it did for 2.3.3 as well.

I am considering restoring 2.3.3 and redoing the upgrades, as I've found the upgrades sometimes are missing files -- will be comparing contents of full 2.4.4 installation package.

(I just spent a few hours debugging modules for html validation. News 1.66 had an old bug which I'd fixed in version 1.63, for example.)

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 ...

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?

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

I have a similar problem as limcity's original post and screen image on January 15. I posted in another similar "Display Problem with Modules Admin in System Module" topic:

https://xoops.org/modules/newbb/viewtopic.php?viewmode=flat&type=&topic_id=70088&forum=72

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?

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?

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 other sections on the page are okay. Anyone got an idea what to check?

gerry_2, you asked if this new file resolves also the problem with html special characters in backend.php.

xoops/backend.php

And it appears that the problem persists, as you mentioned. However, xoops/modules/news/ itself looks okay.

And I discovered another problem in exploring what you mentioned. In XOOPS 2.4.5 beta with News 1.66, all of the >> or << javascript links in the left sidebar of the admin control panel

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

do NOT work. (It's working on my XOOPS 2.3.3 production site.)

In order to validate for XHTML 1.0 Transitional, I had to redo the Smart FAQ Recent Q&A List sidebar header to use "&amp;" in the block title. Change is not visible in System > Blocks > SmartFAQ after submittal. As advertised, the revised 2.4.5 XOOPS core textsanitizer regressed code which had previously corrected special html character processing for module?

Re problem with html special characters in SmartFAQ 1.08 module:

Using the info in trabis' posts, I left my XOOPS 2.4.4 installation intact and merely replaced the xoops/class/module.textsanitizer.php file with Revision 4359 posted at:

http://xoops.svn.sourceforge.net/viewvc/xoops/XoopsCore/branches/2.4.x/2.4.5/htdocs/class/module.textsanitizer.php?view=log

No other changes were made (xoopsstory.php and xoopstopic.php left as is in 2.4.4).

The newer module.textsanitizer.php file appears to have fixed the problem with html special characters that I noticed in questions in the Recent Q&A List and Did You Know blocks and in block title headers in:

xoops/modules/smartfaq/admin/myblocksadmin.php

More testing probably in a good idea, for this module as well as others.