Jump to content

Recommended Posts

  • Replies 34
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Posted

Only way I could get this working when I was testing was to get it set up properly with all the files and databases on a separate host and then transfer the entire thing here (and change all site URL's in the database, easy for someone like me, not easy for the newbies). I am fairly certain the problem is here with HH but I have no way of knowing for certain if this is the case because I can't get an error message out of it and the same files work perfectly where server load is low.

 

I'll keep looking in to it for you guys though.

Posted

Wizard: from a quick try in cPanel's "Zone Editor", it looks like no?

 

rvt: wait, so this works when server load is low?

Posted

Unfortunately I have been unable to fully test this here because I have yet to find a time when server load is low (below 4). However, when I duplicate your settings on my local development machine (with practically no load), it installs without a problem. As soon as I can find a time when the server load here is low, I'll test it here.

 

------------------------

 

 

Update: this is affecting more than just WordPress. Take a look at your phpinfo file: http://www.heliohost.org/phpinfo.php. Easiest way to see the problem is to view source and then scroll all the way down. Notice how it cuts off in the middle of the odbc configuration?

 

Now the problem with Wordpress is it tries to check the php.ini file to make sure it can rewrite URL's. Since the phpinfo isn't printing out completely, it doesn't find what it is looking for and therefore doesn't match any of the conditional statements. When I change the Wordpress function that checks the phpinfo to always return true, the page loads completely.

 

Therefore, I am left to conclude that if you fix the phpinfo() problem, it should fix the Wordpress problem. As for what is causing this phpinfo() problem, I'm still researching.

Posted

MySQL seemed to be taking a whole lot of CPU time. After restarting it, load is back in reasonable ranges. It's below 4 right now...

Posted

Hmm...seems not to be related to CPU load as now that it is below 4 it hasn't changed anything (but everything is much quicker and their aren't as many 500 errors so that is encouraging).

 

More food for thought:

 

In my public_html directory I have a blank php.ini file which I am using to troubleshoot this problem. With this custom php.ini file phpinfo() loads fully (http://thh1.thehosthelpers.com). The directory I have my test Wordpress installation in does not have a php.ini file in it and the phpinfo() does not load fully (http://thh1.thehosthelpers.com/wp3test/rew.php). If I put a blank php.ini file in that subdirectory then the Wordpress network page does load fully (as does php.ini).

Posted
That's outside of HelioHost, right?

 

Nope, thh1.thehosthelpers.com is running here. www.thehosthelpers.com is running outside of HelioHost. I am aware about the php.ini policy, just wanted to test something with it. Now that you have seen its effects I will of course remove it...

 

--------------------------------

 

EarnSimply.com: give me a couple minutes and I'll cobble together a Wordpress 3 install for you that should only be used here at HelioHost. Reason is that I have to disable some of the system checks it does here because of phpinfo() problem. It might work on other hosts, it might not. Difference is, here I know what the system specs are and I know they meet WP3's needs. Other hosts I can't guarantee.

Posted

That was actually a security vulnerability; thanks for catching it. php.ini overrides are now disabled (again).

 

So, there is something wrong with our php.ini. Does Wordpress mention that it requires any specific functions, or how much memory it usually takes?

Posted

Well, I can't say specifically what functions Wordpress needs or doesn't need. Most blogs run on less than 32MB of RAM but the more plugins people have the more RAM they need. That being said, most people can run Wordpress and other HTML sites on a VPS with 256MB of RAM (this includes Apache, MySQL, SSH, FTP, etc).

 

The code that Wordpress is using is this:

 

<?php
function apache_mod_loaded($mod, $default = false) {
    global $is_apache;
//added by rvt:  return true;
    if ( !$is_apache )
        return false;

    if ( function_exists('apache_get_modules') ) {
        $mods = apache_get_modules();
        if ( in_array($mod, $mods) )
            return true;
    } elseif ( function_exists('phpinfo') ) {
            ob_start();
            phpinfo(8);
            $phpinfo = ob_get_clean();
            if ( false !== strpos($phpinfo, $mod) )
                return true;
    }
    return $default;
}
?>

 

First it checks to make sure the server is running Apache (this part is OK).

 

Then it tries to check if the PHP function apache_get_modules() exists. On this host (and many others that I've tested), this returns false.

 

Therefore, it runs phpinfo() and captures the output in an output buffer. The argument "8" tells PHP to just print out the loaded modules in PHP's configuration. This prints out the same way as I have shown above (except without the beginning part which is excluded with the "8" argument). Since this gets cut off before it loads details rewrite, it doesn't realize that that mod_rewrite is installed properly. Thus, none of the conditional statements where this function is called return properly and Wordpress dies without outputting all of its information.

 

If I uncomment the line in the function and remove the part that says "added by rvt:", then Wordpress works great.

 

--------------------------------------------

 

Earnsimply.com: Once you have Wordpress 3.0 installed on your account here, download this ZIP file: http://thh1.thehosthelpers.com/wp3test/functions.zip. Extract the file (it will be called functions.php) and replace the current functions.php file located in the wp-includes directory. This should allow you to install the Networks feature...

Posted

Okay, so here's what we know: something in php.ini is causing phpinfo() to break before it finishes. Am I correct?

Posted
Okay, so here's what we know: something in php.ini is causing phpinfo() to break before it finishes. Am I correct?

 

Correct.

Guest
This topic is now closed to further replies.

×
×
  • Create New...