hansumstranja

I was having similar problems with step=2 in my installation (summer 2009) and discovered that on the server side, I found remedy with Disable Canonical Redirection. My issue was “PHP is sending my browser’s location outside my wordpress folder” and the canonical redirect by the server was where the grievance was located. As an isolated experiment that can be done and undone, try the following-

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 (if you are having trouble getting it activate in the dashboard or mid process). If this is the remedy, reply success.

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.

The answer that would be most helpful would be to question: Truely, how interrelated or how irrelevent is .htaccess to WordPress? With regards to Permalinks, the .htaccess file is expected. But if we wanted to ignore ‘customizing’ our Permalinks, could the .htaccess file be ignored as totally irrelevant to the installation, at least until we get the blog installed and working?!

With regards to .htaccess and its necessity, WordPress documentation, in the context of updating Permalinks, assumes that the file exists, either by user insertion or by WordPress during installation.

If your installation of WordPress does not generate a .htaccess file or if it does not write the new rules onto your existing .htaccess file then there are a couple reasons that could be causing this.

I know that WordPress can create a file in my (sub)directory where I have my ‘testblog’ because I’ve used the wp-admin/setup-config.php. to create a config.php file. But I’ve never seen WordPress create the .htaccess file. It wasn’t until I added that file that a directory would have .htaccess. I suspect that the Codex is wrong or out of date with regards to WordPress installing an .htaccess file.

The recommendation at this point is to update the file permissions to .htaccess- “upload and chmod 666, now generate your permalinks again, chmod .htaccess to 644 for security”. A few other people have mentioned as well that you only want to give file permissions of 666 for a short period of time.

The implication is that the user would have to know when WordPress wants write access to .htaccess. This is a failure on the part of WordPress because, evidently, prudence dictates for that file should idle with only 644 access, and WordPress doesn’t prompt the Administrator that it is attempting to write to .htaccess, so how would we know to temporarily apply chmod?

By the way, if you aren’t seeing the .htaccess in any directories, you may need to find the menu item-“Show hidden files” which has to be a ubiquitous function in any FTP software; in as much as you’ll find a door knob on both sides of a door; It’s got to be there.

The .htaccess file exists when you go to your Concentric Gateway and use Files/Security/Protect Directory and mandate limits via the interface as to who can access that directory. It creates or updates the .htaccess file. And if you remove all limits to that directory, then Concentric follows through by deleting the .htaccess file from the directory. If you want to keep an .htaccess file, you use the Gateway interface to “padlock” the directory (creates .htaccess file) and then edit the .htaccess file manually via Concentric’s file manager or software-FTP.

Regarding Concentric and CHMOD: After a phone conversation, I’ve gleaned that Concentric limits permissions. There is no work around for CHMOD at Concentric because that functionality has been “locked down”. If WordPress truely is attempting to write to the .htaccess file, it’s not succeeding because the file security isn’t as leniant as 666 because its 660. With the Dashboard settings/Permalinks, ‘saving’ a new choice’ of radio button isn’t giving me any flags or text that would indicate that it is not able to the write to the .htaccess file, despite that the Codex says –

“If it can’t, it will say something like ‘You should update your .htaccess now’ and print out the rules for you to copy and paste into the file (put them at the end).”

Which brings things full circle to the question: Truely, how interrelated or how irrelevent is .htaccess to WordPress?

I am having the exact same problem(s)-

The PHP is sending my browser location outside my wordpress folder. I have long given up on trying to update and am now simply trying to do a fresh install, as simple as possible! My code/browser’s attempt to locate to https://mySite/testblog/ is dropping off the subdirectory -“testblog” and is going to https://mySite/.

I’ve been rewriting my issue for weeks now! Scroll toward the bottom firstly because you may find a re-cap of all that’s been written above it. My progress on things like scrutinizing .htaccess are journalled in that thread.

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’);
define(‘WP_HOME’, ‘https://example.com/wordpress’);

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 …

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” ,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.

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

https://www.tamba2.org.uk/wordpress/site-url/

I’m having this exact same problem-

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’.

My detailed thread is at UpGr to WP 2.8.1.: PHP is sending my browse loc outside my wordpress folder.

-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.

I’m getting a ‘hang’ as well….

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’.

My detailed thread is here-

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

-Hans

Regarding the index.php file, I’ve neglected to mention that this is the file named “index.php” that installs with WordPress.

Your goal should be to successfully install wordpress in its own directory and get it working. Then when you’re ready for prime time, you COPY the index.php file to your ROOT directory, change a line of code and then change your WP dashboard settings of blog address. When your user arrives at https://yourSite, their browser forwards to that directory named ‘blog’ where you wordpress.

You may have files in your server ROOT named index.html or index.php already which are unrelated to WordPress. You’ll have to decide how to handle those instances. You have to choose one and rename the others. One index.xxx per directory.

The focus of this post is on the WordPress index.php

With this assumption- that you have wordpress working just fine in https://yourSite/blog, you only need to add one file to your ROOT. Your ROOT directory is at https://yourSite. Blog, is a subdirectory of your ROOT at https://yourSite/blog

Using FTP or however you access your website, your goal will be to upload a file to the ROOT named “index.php.” You’ll also have a file named “index.php” inside the folder -blog. The difference is that (one particular line in) the index.php file in your ROOT will read-
require(‘./blog/wp-blog-header.php’);

so the code knows how to point the browser to your folder BLOG where all your wordpressing actually takes place. The (one particular line in) index.php file inside the blog folder will read-
require(‘./wp-blog-header.php’);

When a browser goes into a folder location, if there’s no name specified in the URL, the first name it looks for is “index”. The index file in your ROOT will point the browser to “blog” because you changed that code. The index file in your folder-Blog is good right there to handle things if someone tries the URL https://yourSite/blog.

In your WordPress dashboard using your browser, you will also need to fix your settings. This is important. There’s the blog address and the wordpress address. Your blog address will now be https://yourSite and the wordpress address will be https://yourSite/blog

Where to find your wp-config.php file:

Inside the WordPress folder, you will find a file named- “wp-config-sample.php”. You open this file, not in a word processor which embeds invisible characters, but in a simple text editor.

You save-as the file as “wp-config.php”. With the file “wp-config.php”, you will edit and save this file by adding in correct information about your blog’s location, database location, database user, database password, these being the four most important articles of information. You’ll need to edit other information as well. All Instructions are written as comments within the coded config file. Also, add “?>” to the last line if these two characters do not exist there already (their ommision is a bug). Then the “wp-config.php” will need to placed in your wordpress location on your server. Good luck.

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

Go to this thread where people are asking your very same question-
Fatal error on upgrade to 2.8.2.

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2355395 bytes) in /home/example/public_html/blog/wp-includes/http.php on line 380

Where Samboll replies-

add this line to your wp-config.php right after opening php statement

define(‘WP_MEMORY_LIMIT’, ’64M’);

— – – – – – – –
For the problem solvers amongst us, I have interesting install/update issues too.