/blog redirect loop

Magus,

Thank you for the reply. Yes, I have checked every setting I can think of and those are indeed the declarations in my General Settings. Would showing my htaccess and index.php in a separate reply be helpful? Also, I can’t find any conflicts with any of my plugins (for example, Yoast). Everything seems internally consistent.

*correction to the last reply, they thought plugin AND stylesheet references to /blog could be causing the redirect loop. I think it’s a problem with my htaccess, but it all looks fine to me and the entire site is behaving as expected, minus the one url example.com/blog/

Magus,

Below, I am including the htaccess and the index.php as they appear in the root and in /blog.

 
htaccess in the root

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress


******************************
index.php in the root

<?php
/**
 * Front to the WordPress application. This file doesn't do anything, but loads
 * wp-blog-header.php which does and tells WordPress to load the theme.
 *
 * @package WordPress
 */

/**
 * Tells WordPress to load the WordPress theme and output it.
 *
 * @var bool
 */
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/blog/wp-blog-header.php' );



******************************
htaccess in the /blog folder

#RewriteEngine On

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress





******************************
Index.php in the /blog folder



<?php
/**
 * Front to the WordPress application. This file doesn't do anything, but loads
 * wp-blog-header.php which does and tells WordPress to load the theme.
 *
 * @package WordPress
 */

/**
 * Tells WordPress to load the WordPress theme and output it.
 *
 * @var bool
 */
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/wp-blog-header.php' );

Magus,

Thank you so much. Do you think the htaccess/index.php files in the /blog directory are fine? You’re a genius in my opinion :) You’ve helped me so much this week and I appreciate both your willingness to help and your very polite/patient replies :)

Addo,

Thank you for the reply, and I apologize for the delay in my response.

I have to say I am so reluctant to do a complete reinstall only because of the amount of time I’ve spent on this over the past 10 days. Some of the methods that my hosting tech support tried resulted in downtime and they messed up my entire url structure (fortunately I had a backup). My fear is that the more I keep taking the site down and such, I will begin to see a negative impact on my SEO. So let me ask you, do you feel like there is a good chance that something within the wordpress core could be causing this and that a complete reinstall stands a decent chance of fixing it? What we’ve done so far:

1) I’ve rebuilt index.php and htaccess for both /blog and root with the help of Magus and codex documentation.
2) I’ve disabled all plugins to make sure there weren’t inappropriate specifications of canonical
3) My webhost tested changing the general settings so that the website and blog urls match (using example.com/blog). This obviously eliminated the redirect loop, but it added /blog/ into my urls, which defeats the purpose of redirecting to root (I didn’t know they were going to do that as part of their fix and my site was up/live with those example.com/blog/file urls for about 4 hours before I caught it. I am surprised they weren’t working in a testing environment!
4) I’ve ensured all hyperlinks in my site are in the correct form

I discovered the example.com/blog/ redirect loop because I found the url indexed in Google. I went to my category listing in wp-admin and set /blog/ to noindex and excluded it from the sitemap.xml. I have also specified the canonical for example.com/blog/ to be example.com. These changes may be sufficient to at least get the url out of Google, and I can ignore the issue going forward. I have never used the /blog category, so what would happen if I delete it as a category? Would that conflict with the /blog directory folder? I was surprised to see that I have the option to “delete” showing on the /blog category page, but seeing it displayed is what led me to ask you about deleting it. Does /blog as a category have anything to do with /blog as a subdirectory of example.com? If not, could the existence of /blog as a category be causing the conflict?

All other pages of the site work flawlessly. Never have html errors. The only redirect loop is example.com/blog/ (but example.com/blog/testpage resolves perfectly).

If I have to rebuild, I will. I just wanted to inquire about how great the chance is that there is something corrupted or conflicting within my current installation. If I can delete /blog as a category without it messing up my directory /blog, I can certainly try that. I don’t see how they are related since my categories are stored in the database, not as a subdirectory of the root.

We replied at the same time :) I have a single installation, in a subdirectory named “blog”, but I am running the website from the root. My general settings in wp-admin are correct (regarding the blog/website urls). Also, my index.php and htaccess files are correct now that I’ve changed them based on the information you supplied in a previous comment above. Unfortunately, the redirect loop still occurs when trying to go from example.com/blog/ to example.com. I will check the table prefixes now, and I will also delete the /blog category since I’m not using it anyway.

Magus

I do not have wordpress files in the root. None at all. I have the htaccess file, which codex instructions tell me that I need. They specify to copy, not move, the wp-admin htaccess and index.php files to the root and make the required changes. Otherwise, no other wordpress files exist in the root. I simply have wordpress installed in /blog and the urls are redirected such that the blog appears to be running from the root.

CORRECTION:

the entire site works fine. It works as expected. The only problem is that the single url: example.com/blog creates a redirect LOOP. None of my other category urls do that. The only thing I can think of is a conflict between category=blog and subdirectory=blog

Ok,

Well I’ve change the root .htaccess so that it is identical to your instructions and matches the /blog .htaccess.
Even after clearing cache, clearing browser cookies, etc., there was no change in the website behavior. I simply don’t understand it. If I had an incorrect root-level htaccess, then how was the website functioning at all? Making the modifications caused not even the slightest change in the website behavior and the infinite loop still occurs on example.com/blog

Assuming my htaccess files are correct, I might try removing the category /blog.

Just a quick update…. I have resolved my problem. In case anyone else has a similar issue in the future, my experience and solution will be on record. I have searched for over a week on Google/Bing regarding naming conflicts and I can’t find anything. You’re more likely to find suggestions for naming your dog than you are to find anything about WordPress naming conflicts. That’s the unfortunate state of modern search, however.

It was indeed a conflict between having the installation directory AND a blog category using the same name. I changed the name of the installation folder, and now everything is working as expected. There are no longer any redirect loops occurring with the /blog category url.

Thank you for your help Magus. Your suggestion that the naming conflict may be the culprit led me to just change the name of the installation directory. The whole process took 5 minutes. I should’ve done that from the beginning, because I had that nagging suspicion given given that htaccess was involved.