UpGr to WP 2.8.1.: PHP is sending my browse loc outside my wordpress folder

has to be an .htacess problem either in your site root or wordpress root
try deleting .htaccess in wordpress root and regenerate permalinks
admin – settings -permalinks

Samboll, thank you for your reply. But no, it’s not a .htaccess problem. In at least one blog folder trial, I excercised a trial where I deleted the whole wordpress folder out of existence and then uploaded a new copy of 2.8.1 into a rebirth of that folder(name) with all of WP 2.8.1 files and added one config file. The .htaccess file was eliminated in that such a process. My install of 2.8.1 was nearly snow-white. I deleted my cookies and I cleared my cache, uploaded a fresh copy and added wp-config.php and spit twice on the carpet. Still, php code locating me to https://mySite/wordpress would convert in the browser’s location field to https://mySite.

But to be sure, I’ve followed your advice to the letter and deleted .htaccess. (I had actually added a .htaccess file just to see if something like .htaccess was sorely missed. But it did not change the outcome. So I deleted it, reran everything but to no improvement.) Your prescription affected no progress.

I’m satisfied that the wp-config file does its job in pointing to the database. What those four lines inside wp-config.php mean in the new wp-config-sample.php for adding Auth_Key, Secure_Auth_Key, Logged_in_key and Nonce_key, I don’t know much about but a visit to https://api.www.ads-software.com/secret-key/1.1/ provides me with an cut and paste to replace exactly those lines with the proper syntax and unique phrases.

I even uploaded a config file from 2.5 that doesn’t mention those four lines regarding security keys and their “Your unique phrase here”. Still didn’t matter. In the 2.8.1 wp-config.php file, I since filled those four lines with generated code from https://api.www.ads-software.com/secret-key/1.1/ . No, the .htaccess file existence or not isn’t having any effect on my problem . Could the Auth, Secure_Auth, Logged_In, or Nonce Keys have anything to do with my problem?

It’s no longer a matter of ‘upgrading’. I’ve created a new database via phpMyAdmin called ‘test’. I’ve created a new folder on my server named ‘testblog’ and have uploaded all the files in WordPress 2.8.1 to folder- ‘testblog’. One additional file gets hand-edited and uploaded, which is the wp-config.php file. So if there’s a problem with my skills, its going to have to be with wp-config.php.

After creating ‘test’ (or dropping all the tables in ‘test’ to try this excercise all over again),

I point my browser’s location to https://mySite/testblog/wp-admin/install.php

The installation is successful- My ‘test’ database gets populated with ten tables, as usual. Browsing the table wp_posts even reveals those “Hello World” default posts, populated into the database during the install.

WordPress provides a form for me to answer with my blog’s name and my email address. Then, WordPress congratulates me on a successful install and gives me a username- admin and password- 5f34fd355s, which I dutifully track.

My browswer is pointed to https://mySite/testblog/wp-login.php and the spartan page loads. I enter my information and my browser’s next location is-

https://mySite/?step=2/wp-login.php —!!!!!!!!!

Notice how, at this point, the directory “testblog” has been parsed out of the url? I guess I never really get to step 2, whatever step 2 is.

I can repeat this process simply by dropping all the tables in the database- ‘test’ and pointing my browser’s location to /wp-admin/install.php as many times as I wish.

The problem, by elimination, would probably be solved either by something I did with the wp-config.php file or by WordPress putting out a corrected installation version. Things like .htaccess and permalinks are irrellevant to these trials. My newly minted folder never had .htaccess in them.

Short and Sweet

My new trials are attempting to install a fresh version WP 2.8.1. The database name is ‘test’ and folder is ‘testblog’. I’ve repeated the process several times now by clearing the database of tables and then running the installer again. Each time, the database populates and WordPress provides me with user= admin, password= blahblah, and proceeds to queary me to login. After entering the information and clicking “Log in”, WordPress drops ‘testblog’ out of the URL and it tries to go to https://mySite/?step=2/wp-login.php, immediately. The end. I never accomplish a fresh installation. The database is populated with ten tables and the posts table includes those “Hello World” messages. But WordPress fails near the end of ‘set-up’.

The folder has no .htaccess file. So during my last trial, I add an .htaccess file just to see if its existence (.htacces) is ‘expected’ in the php code of WP 2.8.1. Adding the .htaccess protection and restarting the browser and repeating the installation, I find the existence of a .htaccess file makes no difference.

I’ve even gone so far as to actually check that I’m meeting the minimimum requirements- My server runs on version mySql 4.1.22 and supports PHP versions 5.2.3., 4.4.7., and 3. I believe that I exceed the minimum requirements to host WP 2.8.1.

Should I be looking closer at all code that deals with “absolute path”?

I should add that I have several blogs on my site already, WP version 2.5. Each blog is in its own directory. As directed in “Giving WordPress Its Own Directory ? WordPress Codex“, my “mainblog” is in its own directory but in the root directory, the index.php file reads-

<?php
/* Short and sweet */
define(‘WP_USE_THEMES’, true);
require(‘./mainblog/wp-blog-header.php’);
?>

So that if a user were to go to https://mySite , the index.php would direct them to the ‘Main Blog’ in its own directory. But this shouldn’t be effecting my installation of Testblog because Testblog has it’s own directory and should never be looking outside its own directory. None of my other WordPress blogs do.
–Hans

WordPresss is now at 2.8.2.

I’ve run a new install of WordPress 2.8.2 as “testblog” at https://mySite/testblog/ using a wiped database named ‘test’. The database installs, the tables fill, and I progress as far as entering name, password and clicking Login. At this point, the WordPress Install Part Two falls out of bed by sending the browser location to https://mySite/?step=2/wp-login.php/. The Site URL parsed out ‘testblog’.

Some pages that might be helpful to this problem are-
Codex: Changing_The_Site_URL.

and

In thread – Website no longer formatted….
samboll wrote-
use the phpmyadmin option and change BOTH url’s to reflect where the actual install is
https://www.tamba2.org.uk/wordpress/site-url/
while you’re in there – reset your password
https://www.tamba2.org.uk/wordpress/phpmyadmin/
–end

The website at tamba2.org.uk/wor… is how to manually change the ‘site url’. Considering what’s said in Codex: Changing_The_Site_URL, I might want to change ‘home’ as well.

-Hans

501 Not Implemented

With regards to ‘siteurl’ and ‘home’,

I have dropped all the tables from the ‘test’ database and run wp-admin/install.php many times now.

I’m now thoroughly familiar with the wp_options table in the ‘test’ database and can edit both ‘siteurl’ and ‘home’. The install writes these values as https://mySite/?step=2 which I’ve manually changed to https://mySite/testblog/?step=2 in both siteurl and home. Then I’ve clicked ‘Login’ and I get the same results as above. See: 501 Not Implemented.

I’ve also scrutinized Codex:Installing_WordPress and thus, I’ve eliminated any possibility of the mentioned ‘BOM issue’ in using my own text editor by utilizing wp-admin/setup-config.php. This sets up the config file on my server via a webform. By the way, WordPress needs to update “wp-admin/setup-config.php” to also ask for those four unique phrases for the security keys.

I’ve eliminated a long series of possiblities as to where the problem might originate by my own hand. I’m looking to the WordPress programmers now for an update.

Over many trials, I’ve run a new install of WordPress 2.8.2 as “testblog” at https://mySite/testblog/ using a wiped database named ‘test’. The database installs, the tables fill, and I progress as far as entering name, password and clicking Login. It’s just after clicking Login, the WP Install Part-Two falls out of bed by sending the browser location to https://mySite/?step=2/wp-login.php/. The “destination URL” has parsed out ‘testblog’ and WordPress has descended to the root directory, outside of its folder. The installation is a failure.

Repeating the process means again viewing phpMyAdmin to drop all the tables in the database, and sending my browser to … ” wp-admin/install.php”. I’ve been re-trying the process now, making one slight change after another and reinstalling, for about 30 trials.

In the process of working through all these failures to install, I’m now thoroughly familiar with accessing the ‘test’ database’s wp_options table in the ‘test’ database and can edit both ‘siteurl’ and ‘home’. The install writes these values as https://mySite/?step=2. which as mentioned above, causes the install to fail. So just after entering Blog Name and email address and clicking “Install” and right before entering Username and Password and clicking “Login”, I’ve manually edited these fields to https://mySite/testblog/?step=2 in both siteurl and home. This didn’t work either.

However, I then tried changing the siteurl and home fields to “https://mySite/testblog&#8221; ,dropping off the “?step=2” and then clicking “Login”. And this time WP takes me to my Dashboard. Hello World! Pages can be viewed because they have full URLs with suffix like /?p=1. But clicking “View Site” will take me to seeing in my browser’s location bar- https://mySite/testblog/ and then https://mySite/ . Retyping https://mySite/testblog/?p=1 into the location bar would get me back to my Testblog. But it seems that any process that involves putting the browser location to https://mySite/testblog/ is going to result in WP falling out of the directory again.

I’ve worked primarily with the Safari 4.0.2 browser but have run some of the trials in Firefox 3.5 also, just to see if browser choice has any effect. I cannot discern any difference. I’ve also used the config.setup to add a config file without using my text editor which then eliminates that remote BOM issue mentioned in Codex:Installing_WordPress. I’ve also ruled out a myriad of other other possible interferences such as there is no .htaccess file. I’ve tried adding “define(‘WP_MEMORY_LIMIT’, ’64M’);” and I’ve paid attention to the existence of the “?>” as final characters in the config file. I’ve tried elimination, addition, subtraction, etc. I’ve eliminated a long series of possiblities as to where the problem might originate by my own hand. I’m looking to the WordPress programmers now for an update.

In Codex: Editing _wp-config.php under the Advanced Options, I’ve discovered that I can define siteurl and home within the config file.

This is a good thing because as I’ve written above, on_install, these have been miswritten to the database and it was only by manually ‘fixing’ them using phpMyAdmin was I able to get a Dashboard. Without fixing these manually, I got nothin’!

So I am adding –
define(‘WP_SITEURL’, ‘https://example.com/wordpress&#8217;);
define(‘WP_HOME’, ‘https://example.com/wordpress&#8217;);

with the appropriate changes in the URL to my config file. And this works! I reinstall and get the Dashboard and as about as much functionality as when I was manually fixing these options. But they shouldn’t have been written to the database with the wrong information in the first place. WordPress needs to work on its version!

I’m also paying attention to thread- Front Page redirects to site home page because it’s exactly my situation. The question that needs answering immediately is can we eliminate the issues with .htaccess by installing this test blog into a folder that has no .htaccess or does WordPress somehow require .htaccess’ existence? With regards to Permalinks, the Codex says that WordPress expects its existence and tries to write new rules to .htaccess. And if WordPress cannot write to .htaccess that the .htaccess file’s permissions need to be corrected. Unfortunately for me, on Concentric, the command CHMOD isn’t recognized. As it is right now, the security on .htaccess is 660. I may have to contact Concentric.

As it still is, any time the browser is attempting to go to https://mySite/testblog, it redirects to https://mySite …

How this WP problem in this thread was solved for me-

“PHP is sending my browser’s location outside my wordpress folder“

To Recap:
Here WAS my problem: After my manual upgrade to WP 2.8.1., Anytime the php is “intending” to locate me to https://mysite/wordpress, it rattles for a second mid-script and then the URL in the location field changes to https://mysite . At the root directory of mysite, wordpress has fallen out of bed- it’s no longer operating inside the wordpress folder. MySite/index.php has its own unrelated splash screen. I’m dead.

Within the wordpress folder, there’s something spoiled about index.php or its handshake with wp-blog-header.php or whatever comes next down the line. I don’t know. Oh, I can view particular pages in the blog by manually typing in https://mysite/wordpress/?p=1 (or 2 or 3 or X) to see that page with its theme and content intact but something like clicking HOME sends my browser location to https://mysite/wordpress and then a second later to https://mysite . This sends me outside the wordpress directory to the site’s root directory. I die.

There were two reactions to my problem by this arena’s public. One was that I have something wrong with my .htaccess file. But eliminating the .htaccess files altogether didn’t solve anything. Nonetheless, I did learn that the .htaccess file does define what the ‘default’ file will open when the browser is directed to a directory. So it’s good to have knowledge that your .htaccess file might want to have the following line at the top of its file-

DirectoryIndex index.php index.html index.htm

I eliminated using .htacces altogether for the time being while I worked to solve the problem of the browser’s redirect.

What really solved the issue for me on my Concentric/XO Communication server was to Disable Canonical URL Redirection. (cite)

Create a text file with the following text and name it: disable-canonical-redirects.php

<?php
/*
Plugin Name: Disable Canonical URL Redirection
Description: Disables the "Canonical URL Redirect" features of WordPress 2.3 and above.
Version: 1.0
Author: Mark Jaquith
Author URI: https://markjaquith.com/
*/
remove_filter('template_redirect', 'redirect_canonical');
?>

Place this text file in wp-content/plugins/ and make it active. You may want to install the WordPress folder and add this plugin to its appropriate location and then run the installation script so as to activate this plugin at the get-go.

Thanks to danielmaxwell and to the unnamed Tech Support person at Concentric/XO Communication.

Great post and very helpful info! I just used your fix on my XO hosted site, too. Thank you!