[rcwatson]

I’ve tried reading through all the above posts, but my eyes started to bleed. Nothing looks like what I’m experiencing, so I’m hoping maybe someone can confirm that and help me find a solution.

When I upload a group avatar to BP on WP 3.1 (no multi-site) running on RHEL, I can see the file upload to /var/www/html/wp-content/uploads/group-avatars/4 . However, when I do the crop and save action, the file disappears from the directory. The permissions are set at 777 with apache:apache ownership, so I don’t know how much more open it could be. Something is removing the image at crop time.

Any ideas?

[rcwatson]

I know. I just keep forgetting about it. Thanks for your prompt help, though. It helped unstick my thinking.

[rcwatson]

Found the answer! Yet again, it’s that darn AllowOverride None to AllowOverride All thing. I wish that was configured during WP setup, but can understand why it isn’t.

[rcwatson]

Ok, I did finally realize that my problem of getting nothing at http://ip.address… was because I my index.php file went missing.

Duh.

But, despite the permalink update and correctly generated .htaccess file, I still don’t have access to posts and pages. Just the home page. BuddyPress isn’t installed yet. This is just the base WP 3.1 install.

[rcwatson]

Still not fixed.

I did a ground-up uninstall and reinstall of all the components of the LAMP stack:

Uninstall
1) yum remove httpd (preserved my httpd.conf file in the /etc/httpd/conf directory, deleting everything else)
2) yum remove mysql
3) yum remove php
4) deleted everything out of /var/www/html

This puts the server back to its fresh install situation before I ever added any packages. This is a brand new RedHat Enterprise Linux install with nothing else running on it.

Install
1) yum install httpd
2) yum install -y mysql mysql-server
3) yum install -y php php-mysql
4) Copied wordpress files to /var/www/html, which is the DocumentRoot setting in my httpd.conf file, ensuring that chown -R apache:apache and chmod -R 755 on everything, including html directory
5) Restored /etc/httpd/conf/httpd.conf from backup
6) Started httpd using /sbin/service httpd start. It starts with zero errors. All ok.

I type in http:// followed by the IP address currently standing in for my domain name (as yet undetermined). Earlier in our discussion thread, I used to get the wordpress install script. Now I just get the Apache server test page for RedHat Linux. If I put index.html with “

It Works!

” into /var/www/html, then I see that. If I remove the index.html, I still don’t see the install script starting up. Just that Apache RHEL default test page.

But, if I add /wp-admin to my URL, it DOES go into the install script. That was something I didn’t have to do before. But at least I’m getting this far. So I go through the install and get into the Dashboard.

I immediately go to the Permalinks menu and switch to a different scheme so as to generate the .htaccess file. That works just fine. I then immediately go to test the home page. Nothing but a 404. Earlier in this thread, I at least got the home page when none of the other links worked. Now that doesn’t even work.

This really sucks. I can’t figure out what’s wrong because this server is exactly like other servers our hosting provider has given us for the same thing, and those all work fine. They don’t troubleshoot WordPress installs because, well, they just don’t. Their business is server hosting. The app level is up to the customer.

What did I miss? How could this time through (the same as the first, second, third, and fourth time through) of the install have resulted in something so different?

Thanks.

[rcwatson]

Well, I definitely had PHP 4.3 or better, MySQL 4.1.2 or better, and Apache Module mod_rewrite enabled for “pretty permalinks”. I had installed it a couple of times over before that, but I can’t remember whether I tested the clickthrough to the single hello world post for that (just saw the home page and that the dashboard worked), so I wouldn’t know whether I had a fully stable WordPress install to begin with.

I’ll give the reinstall a try and report the results for posterity in this thread.

[rcwatson]

Noting that it wants to go to `wp/members` rather than where the buddypress install and BP Compatibility configuration directions had me put that and its other folders (which was in `/wp/wp-content/themes/bp-default`), I copied all the bp-themes directories to where WordPress and the web server are looking for them… `/wp/members`.

The URL that appears in the browser is http://098.765.43.210/members/admin/activity/

That’s not exactly right, though, as the structure “admin/activity” isn’t even part of “members”. The error log reflects this (correctly) as:
`[Tue Mar 08 14:48:36 2011] [error] [client 123.456.789.0] File does not exist: /data01/home/username/production/wp/members/admin`

And so does the access log:
`123.456.789.0 – – [08/Mar/2011:14:48:36 +0000] “GET /members/admin/activity/ HTTP/1.1” 404 301`

So I truncate the URL in the address bar to be http://098.765.43.210/members and now I get a blank page. No source.

The access log now says:
`123.456.789.0 – – [08/Mar/2011:14:53:01 +0000] “GET /members/ HTTP/1.1” 200 -`

But the error log now says:
`[Tue Mar 08 14:53:01 2011] [error] [client 123.456.789.0] PHP Fatal error: Call to undefined function get_header() in /data01/home/username/production/wp/members/index.php on line 1`

I’m soooo totally baffled by all of this. I thought the BuddyPress installation instructions were pretty straightforward, but it seems to actually work in a whole different way from what is documented.

[rcwatson]

Here are example lines from my error log and access log (IP numbers obfuscated for security):

Error log:
`[Tue Mar 08 14:25:49 2011] [error] [client 123.456.789.0] File does not exist: /data01/home/username/production/wp/members, referer: http://098.765.43.210/`

Access log:
`123.456.789.0 – – [08/Mar/2011:14:25:49 +0000] “GET /members/admin/profile/ HTTP/1.1” 404 300`

With Permalinks set to “Month and Name”, a hit to the hello world blog post for this install generates the following error and access log entries:

Error log:
`[Tue Mar 08 14:38:48 2011] [error] [client 123.456.789.0] File does not exist: /data01/home/username/production/wp/2011, referer: http://098.765.43.210/`

Access log:
`123.456.789.0 – – [08/Mar/2011:14:38:48 +0000] “GET /2011/03/hello-world/ HTTP/1.1” 404 298`

Setting the Permalinks to “Day and Name” gives this:

Error log:
`[Tue Mar 08 14:35:02 2011] [error] [client 123.456.789.0] File does not exist: /data01/home/username/production/wp/2011, referer: http://098.765.43.210/`

Access log:
`123.456.789.0 – – [08/Mar/2011:14:35:02 +0000] “GET /2011/03/05/hello-world/ HTTP/1.1” 404 301`

[rcwatson]

Paul,

Thanks for your suggestion. I deleted .htaccess, restarted Apache, did the permalink switch and changed it back, and saw that the .htaccess file was regenerated, but it didn’t fix the problem of getting 404s on everything but the home page.

I’m beginning to wonder if it’s the host. Problem is, the particular (corporate) hosting package i’m using (SAVVIS) is such that I’m responsible for all apps. They don’t support anything above the basic OS setup, so I can’t turn to them for troubleshooting. However, if you can think of anything at the network (maybe the firewall settings?) or OS level that I might be missing, then I could ask them to troubleshoot that part of it all.

[rcwatson]

I have tried adding all these settings, selecting all different forms of pretty permalinks, relocating my .htaccess file to various locations throughout the /var/www/html hierarchy, and restarting httpd over and over again, but none of them have worked.

The only other thing I can think of is that at one point I was using a symlink to point documentroot /var/www/html/wp to /data01/home/username/production/wp (i.e. /var/www/html/wp –> /data01/home/username/production/wp). Right now, documentroot points directly at /data01/home/username/production/wp for the VirtualHost DocumentRoot directive without using a symlink. I still can’t get WordPress posts or buddypress activity, group, member, etc. pages to appear. All 404s.

Any ideas of other things I could try?

[rcwatson]

Andrea_r: Thanks. So I commented out the current AllowOverride None directive and added AllowOverride FileInfo Options, like this:

`# First, we configure the “default” to be a very restrictive set of
# features.
#

Options FollowSymLinks
#AllowOverride None
AllowOverride FileInfo Options
`

Then I restarted httpd. Now I get 500 internal server error. Is there another place I should be putting AllowOverride FileInfo Options instead?

[rcwatson]

# There are lots of WordPress hacks designed to take the contents of your wp-config
# file (username and password) and dump them to a text file a spambot can pickup and
# send to a hacker. If you block access to wp-config file in your .htaccess using
# this method, you block those hackers from getting your database login information.
Order deny,allow
deny from all

# Turn off directory indexing to keep anyone from seeing the contents of a directory
# if there is no index file.
Options All -Indexes

# Block known spambots and crawlers. Update the following section with newly discovered
# spambots and crawlers. This blocks them from ripping off posts and images (costing
# bandwidth in the process.
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot mailto:craftbot @yahoo.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} Indy Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC Web Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]

RewriteCond %{HTTP_USER_AGENT} ^Offline Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web Image Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus
RewriteRule ^.* – [F,L]

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

[rcwatson]

As an experiment, I changed “wordpress” in the documentroot path to “wp”. Restarted apache. Still, the home page loads beautifully, yet every link in the site (buddypress link or blog post link) leads to 404. Totally confused here. Never had this happen before after many, many installs.

[rcwatson]

Grr. Ignore the part after “webmaster” in previous post. The forum is doing weird stuff to it. It’s supposed to be just the IP address.

[rcwatson]

Thanks, mercime. But when I add in “/wordpress/” in front of “/members/…”, I still get 404.

http://xxx.xxx.xx.xxx/wordpress/ also returns a 404. But http://xxx.xxx.xx.xxx/ returns the buddypress-enabled home page, fully themed and functional, except for the fact that clicking any deeper part of the admin menus returns 404.

My apache virtualhost settings are as follows:

`
ServerAdmin webmaster @xxx.xxx.xx.xxx
DocumentRoot /data01/home/username/production/wordpress
ServerName xxx.xxx.xx.xxx
ErrorLog logs/xxx.xxx.xx.xxx-error_log
CustomLog logs/xxx.xxx.xx.xxx-access_log common
`

Does anything need to change there to fix this problem?

[rcwatson]

Having the same problem on a fresh WP 3.0.5 install and mod_rewrite is enabled.