alexk_ny

That would make absolutely the perfect sense if it works (it should – I will be trying it later today). If so, when WordPress is to be installed in a SUBdirectory of the site’s web root, I feel the install script should be adding these rules to the subdirectory’s .htaccess not the root site’s. I saw another .htaccess in the /oo_blog subdir and assumed I could not move the WordPress related rules there – that they specifically belonged to the site’s root (or blog’s parent directory) .htaccess …

When the blog directive #RewriteRule . /oo_blog/index.php [L] is commented out as shown, and 404 redirection works normally, I get the expected record in the Apache error log:

[Fri Mar 05 11:42:57 2010] [error] [client 74.73.xx.xxx] File does not exist: /home/karasa/public_html/notfound

… and the access log gets the following entry:

74.73.xx.xxx - - [05/Mar/2010:11:42:57 -0600] "GET /notfound HTTP/1.1" 404 2692 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 (.NET CLR 3.5.30729)"

When # is removed and the RewriteRule above is active, there’s nothing at all in the Apache error log, and the access log gets the following line:

74.73.xx.xxx - - [05/Mar/2010:11:42:16 -0600] "GET /notfound HTTP/1.1" 404 4599 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 (.NET CLR 3.5.30729)"

The blog conditions that are supposed to govern the blog (located in /oo_blog) are, again:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

These look pretty generic to me. Isn’t there a referer or path or file extension or another condition we can try that would be specific to the blog?

Thanks

Alex

Thank you for replying. I have initially failed to diagnose the problem correctly. In finding the answer to your question after some experimentation (renaming, logs, etc) I have determined the following:

1. If the URL is not found, the browser is being redirected to /oo_blog/index.php (as opposed to following the instruction ErrorDocument 404 /err404.shtml)

2. /oo_blog/index.php in turn prints the “Error 404 – Not Found”

3. The single line in .htaccess which, if commented out, restores the normal behavior (i.e. displaying /err404.shtml for docs not found on site) is RewriteRule . /oo_blog/index.php – not the RewriteBase one I’ve stated earlier.

4. When the RewriteRule was enabled, normal pages were not being affected – just the 404 error for which I had the ErrorDocument instruction in .htaccess.

5. The site is karasevstudio.com and the RewriteRule line is presently commented out. I can put it back in or place additional instructions, but basically the question is how we limit the scope of this rewrite to just stuff belonging to the blog. Thanks so much for your help so far – I’ve coded my own site but my expertise on .htaccess is close to 0

Tried – same exact behavior with the following contents:

<Files .htaccess>
order allow,deny
deny from all
</Files>

ErrorDocument 404 /404.shtml

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /oo_blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /oo_blog/index.php [L]
</IfModule>

If I take out RewriteBase /oo_blog/ the redirect works fine, but obviously the blog is impacted…

OOPS the posting appears to not allow nested markup. So in the .htaccess code section above, the part pertinent to WordPress is between the “strong” tags – which themselves are of course not a part of the .htaccess file as stored on my server.

I’ve failed to follow instructions fully in https://codex.www.ads-software.com/Editing_wp-config.php section “Moving wp-content”

Beside define( ‘WP_CONTENT_DIR’, $_SERVER[‘DOCUMENT_ROOT’] . ‘/blog/wp-content’ );
… I was supposed to also define( ‘WP_CONTENT_URL’, ‘https://example/blog/wp-content’);

SUGGESTION: it would be cleaner if the default DIR <-> URL relationship were established centrally by defining the web root dir of the site and the home page url in two constants. The paths down from there would by default be all identical, obviating the need to track separate DIR and URI vars for many resources. Just IMHO