Let me ask a couple of questions.

How much traffic does your site get per day?

Has that number increased lately? You might have to check your hosting provider logs if they keep that information for you.

I've taken a look at this, and there seem to be a few things about that way we are using stopforumspam.com that should be fixed. It is possible that if you have enough activity that your site IP gets flagged by stopforumspam.com and it stops sending the information. If it returned an error message instead of the formatted response we expect, that would cause your error.

It appears that we are checking every post, and we are not doing local caching

If a site gets a lot of post traffic it could easily get flagged with the current setup. This article is specifically about a Drupal mod, but the issue sounds similar:

http://www.stopforumspam.com/forum/viewtopic.php?id=5136

This might take a little while to solve. Does anyone else have similar issues?

Quote:

Just run the module update in the admin area.

modules/system/admin.php?fct=modulesadmin

The yellow arrow in a circle icon toward the right of each module line will launch an update, which refreshes XOOPS internal view of the module, including the templates.

It would also be a good idea after that to clean the caches in maintenance (the broom icon):

modules/system/admin.php?fct=maintenance

Just select all three items, smarty_cache, smarty_compile and xoops_cache and then submit the form.

Then things should work correctly, like they did before.

Quote:

This is definitely configuration related, and definitely not a new issue with 2.5.7.

Protector is comparing the XOOPS_ROOT_PATH and XOOPS_TRUST_PATH and trying to use the difference to build a directory traversal that can be used in a URL. The URLs only show us where it ended up, not how it got there. For that we need the actual directory paths.

I'll use Ubuntu 12.04 LTS as a point of reference since I have it available. The default web site is at /var/www. If we define a www directory under that, the paths of everything underneath will have two 'www' components in the full directory, so the match might get confused. It should also get confused if you add a 'var' directory.

Ideally, xoops_lib should be completely outside of /var/www (or whatever the root is,) and protector will be unable to build a URL to it. If for some reason it has to be inside the web root, a .htaccess file that restricts the web access will be better than leaving it completely exposed. Usually protector can build a URL to that, and the test will determine if the .htaccess is actually working.

Since protector has internal knowledge of both paths, it ideally should be able to reliably determine the needed traversal. But this also highlights the need for real human analysis of the conditions, and protector's broken image test is a poor substitute for that.

One could devise a new test that did something more sophisticated, possibly testing multiple variations with curl and checking the return codes instead of asking the user to verify that an image link doesn't work. But it still won't beat proper setup and human analysis.

Quote:

I'm guessing the upgrade was to 2.5.7.

It looks like you should be able to log in here:
http://fla-ts.com/modules/profile/

Try to login, and update the profile module in administration. The templates changed, and that could be the problem.

Quote:

That doesn't look like the line that a multibyte language should be going through. Check the global.php in your active language directory to make sure XOOPS_USE_MULTIBYTE is set correctly.

Make sure that in your htdocs/language/(language name)/global.php there is a line that reads:

Looking in SVN to get the context I am suspicious of line 171 in \modules\TDMCreate\admin\fields.php:



The 'edit' case is always $fieldsObj =& $fields->get('edit');

Hope that helps.

The 500 error might be the server objecting to world write. A 775 permission might make it happy. But, I can't verify that.

Let's try this. Create a mainfile.php file with the following:


Upload that to the root directory and set the file permission to 777, then retry the install.

If this works, we can add a file to extras, so we have a solution ready for problematic servers. I use Linux almost exclusively for development and production, and I don't have any environments where this is a problem. Even my Windows boxes seem happy with the changes. But there are always other ways to configure systems.

The whole reason for this change was to make it impossible to accidentally overwrite mainfile.php while upgrading a production system. If you've ever done that, it is a great way to induce panic and ruin an otherwise good day (OK, I am speaking from experience, I admit it, but I won't put a number on how many times I've done it.)

Sorry this is such a problem.


Edited to add this from support.hostgator.com:

Quote:
suPHP solves the whole problem. Too bad they are not "most hosting companies"

Sounds like a permission issue, and it can't write the new mainfile.php.

The main xoops directory needs to be writeable by the web server php process. When mainfile.php exists, permission to write comes from the file itself. When it doesn't exist, the permission comes from the directory it is in. I'm guessing the server doesn't have permission to write to the xoops root directory.

Can you change the permissions of the root directory? If yes, you could try setting the main xoops directory writable long enough to run the install, and setting it back when you are done.

What type of OS is this running on?

Looks like there is a slash missing in line 20 of modules/pm/admin/about.php

I should read:
include_once dirname(__FILE__) . '/../../../include/cp_header.php';

Shouldn't take too long to get this patched.

Quote:

I think we made the mistake. The green button now points to 2.5.7.

Thanks!