intoxination

WP doesn’t use Fulltext indexes on searches. It’s either a plugin causing it, or a change to the core search functionality. If it’s a plugin, I would check the installation routine and make sure the indexes were defined, or it could be something you have to do manually. Check the readme file.

Sounds like the taxonomy.php file didn’t upload when you upgraded. Try uploading just that file to /wp-includes/ (which is the directory it’s found in).

Look for this line in your template single.php file:

<div id=”wp_content”>

After that paste your adsense code in. That will make it show up on the single post view. You can also put it in your index.php file if you want it to show up on the front page.

There isn’t a plugin that will handle this the way you want. The reason is that there’s no real plugin hooks to inject the code in that position of the template. Having such a hook would also require everyone update their templates.

Make sure the file /wp-includes/compat.php is uploaded (maybe try reuploading it). Also try reuploading your /wp-settings.php file.

It looks like you got an older version of Google Sitemaps running. Upgrade to the latest version and that should be fixed.

Ronams,

I just did a test on my personal server. I just reinstalled everything on it 2 days ago, so Apache, PHP and MySql are all running at their default configuration right now. By default, PHP sets the maximum memory to 32m. Most servers I deal with have it set to 8meg. One site I manage gets over 200,000 hits a day and averages about 3,000 comments a day and that 8 meg limit has never been an issue.

Having said that, I changed my php configuration to 2meg and did a fresh install of WordPress and it did the same thing you were experiencing – just gave a page can not be displayed error. It also won’t log the problem in the Apache logs. At 4 meg, it gives you the php memory allocation error and even logs it in the file. At 6 meg is was running fine. That indicates that it isn’t actually a problem in WordPress, but rather a condition of PHP not being able to generate the error at the 2meg limit. My guess is it is dying while compiling the WordPress scripts.

As far as your logs go, you can have 10 different hosting companies with 10 different log locations. If you are on a shared hosting package then chances are you don’t get live access to your error logs. Most companies run a script that rotates your logs into a directory accessible by the user every 24 hours. Generally you can FTP in and there will be a /logs directory, or access them via C-Panel (if your hosting provider has it installed).

It should also be noted that at 2meg memory limit on PHP that PhpBB, PhpBB3, SMF, Durpal and VBulletin all fail to load and give the same “page not found” error. This is a really bad decision on the part of your hosting company to invoke this limit, especially since it will prevent a majority of PHP software out there from running. They might as well tell people they can run PHP scripts on their site as long as they are simple “hello world” scripts.

Well WP() is what actually parses the query variables. From here, the next best step might be to actually test inside the WP class from the Main method. You can find that in /wp-includes/classes.php. The Main method is towards the end of the file and looks like this:

function main($query_args = '') {
$this->init();
$this->parse_request($query_args);
$this->send_headers();
$this->query_posts();
$this->handle_404();
$this->register_globals();
}


Just start doing the die test before each of those lines and that will help narrow it down even further. I know it’s a pain, but sometimes this is the only way to figure out what exactly is going on.

It probably died because you were inside that if block. It didn’t really get to the die statement, but skipped past it (since we know you have a wp-config.php file) and you thought that was the point.

Try doing the die again moving it before each of these lines

require_once( dirname(__FILE__) . ‘/wp-config.php’);

wp();
gzip_compression();

require_once(ABSPATH . WPINC . ‘/template-loader.php’);

That will give us a better idea.

Just out of curiosity, have you tried to disable your gzip compression in WordPress? There is a possibility something screwy is happening in there (I have seen it happen on other platforms before).

Something else to try is go into wp-blog-header.php and start working down and add the following in the file:

die(“test point”);

See if when you go to the site you get the test point. If you do then move it down further in the code and see where you stop getting it at. It could be something causing the crash when wp() is initialized, but this will give a better idea of where the problem is occuring.

For some reason either WordPress or Apache is sending a redirect header (I would guess it is in Apache). It could be coming from your parent directory, but here is a raw dump of the packets going to your blog site:

GET /blog HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Maxthon; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.1)
Host: https://www.strategy2execution.com
Connection: Keep-Alive

HTTP/1.1 301 Moved Permanently
Date: Wed, 30 Aug 2006 18:40:58 GMT
Server: Apache/1.3.33 (Unix) ApacheJServ/1.1.2 PHP/4.3.10 FrontPage/5.0.2.2635 Rewrit/1.1a
Location: https://h2roadmap.com/blog/
Keep-Alive: timeout=15, max=96
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

e6
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved <A HREF=”https://h2roadmap.com/blog/”>here</A&gt;.<P>
</BODY></HTML>

0