Situation
I am working in the Comments Manager on the admin side reviewing comments from Anonymous Users to decide whether a particular comment should be approved or deleted. When I click on any comment to view it I get a blank page (no error messages even with XOOPS debug turned on). When I click on Edit or Delete I am immediately logged out and I get the “Sorry, you don't have the permission to access this area”. I can log on again OK but I cannot view, edit or delete any comments using the Comments Manager, including existing, approved comments. However, I can view, edit or delete comments from the user side (if I can find them).

Actions Taken
I’ve searched these forums very carefully and I’ve tried every possible suggestion but the problem persists. Here is a summary of the things I’ve tried:
1. Check all permissions – I am logged on as Webmaster (UID=1) with all permissions set for everything.
2. Check the web host error log – no messages.
3. Check the PHP error log – no messages.
4. Turn on XOOPS debug – no error messages.
5. Run SQL Repair Table on the sessions table.
6. Delete all rows in the sessions table.
7. Run SQL Repair Table on the online table.
8. Delete all rows in the online table.
9. Clear the cache.
10. Clear the templates-c directory.
11. Test with custom sessions and without custom sessions.
12. Disable IP bans.
13. Deactivate all modules except for admin module (the theory being that there might be a module conflict).
14. Upload all files in admin folder again.
15. Run update module on admin module.
16. Temporarily disable XOOPS protector.

Xoops Environment
• XOOPS version - XOOPS 2.0.16
• Software server - Apache/2.2.10 (Unix) mod_ssl/2.2.10 OpenSSL/0.9.8b DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_jk/1.2.25
• PHP version - 5.2.6
• MySql version - 5.0.67

Browsers
I have tested with:
• Firefox 3.0.5
• IE 7.0
• Safari 3.2.1 for Windows.

PHP INI Settings
The php.ini file has these settings:
• session.use_trans_sid = 0
• session.use_only_cookies = on
• register_globals = off
• allow_url_fopen = on
• post_max_size = 40M
• upload_max_filesize = 32M
• max_execution_time = 1800
• memory_limit = 80M
• log_errors = On
• error_log="phperror.log"

Hypothesis
I am running the same XOOPS software on other hosts and I’m not seeing this problem on the other sites. I am beginning to think that there might be something in the hosting environment which is causing this. However, I don’t know what to look for. Any suggestions?

looks like you thoroughly checked just about everything. Wonder if your host is running mod_security with apache... I have had similar problems like this, particularly if one of the comments you are trying to view/load violates a mod_security rule. Not sure if you would have access to modsec_audit.log with a v-hosted environment but it would show there if this is the problem.

edit: you could check the comments in the database for this possibility also.

Quote:

Thanks for the suggestions. I've looked at the text of the comments in the database and it looks OK - it's just simple text. I don't have access to modsec_audit.log so I will open a support ticket with my hosting company.

dbman,

I got the web host technical support guys to check the modsec_audit.log. They found something but after a number of interactions we finally discovered that I needed a php.ini file in the comments folder within the admin folder.

I had copied my php.ini fle into my XOOPS root directory and all of my second level and third level folders but I had overlooked the fourth level folders. Once I had copied my php.ini into these folders the problem was resolved. I'm not sure what parameter was needed but I suspect it could have been register_globals = off.

Hey Tom,
Glad to hear all is well. I am not familiar with a v-host environment but you shouldn't have to copy a version of your php.ini on every directory level. You should be able to add it to your path using a .htaccess file. Your host should be able to provide details.

dbman,

I read about the need to have multiple copies of php.ini in the XOOPS forums.

This advice is very clear in this post: xoops forum post re php.ini
Quote:

I will check with the host about how to add it to my path using a .htaccess file.

just skimmed the post you mention. It looks like poster is overriding the main php.ini directives (register_globals, session.use_trans_sid) turning them to off and 0 respectively. This makes sense from a security prospective. If your host has these directives enabled I would follow the advice in the post.

Quote:

I've just received a response from my host re how to set the php.ini path in .htaccess.

"Our configuration does not allow you to set this in your .htaccess file."

I'll just have to remember to continue to add it whenever I have a dir with php code in it.

Seems you can make your custom php.ini accessable from every directory with .htaccess:
Quote:

Thank you very much for this advice. This has been an enormous help.

I found that I was getting logged of when using the xhelp module. There's nothing wrong with xhelp itself. I probably missed out on adding the php.ini file to one of my PHP folders or perhaps one of them was out of date.

After including this entry in my .htaccess file, the “Sorry, you don't have the permission to access this area” problem disappeared.

This has solved 2 big problems for me:
1. I no longer have the “Sorry, you don't have the permission to access this area” problem.
2. I no longer have to have 361 copies of php.ini.

Thank you.