Problem with IE and ?

The default install works great with Firefox – but ../htdocs/index.php will not display in IE.

The WordPress admin site works in IE – but when you link to the (view site) IE just spins on “connecting…” and nothing ever happens.

Is this an IE vs. xhtml issue? htaccess?

Can you verify that your default install works with IE?

Yes, it should work ok. Which Windows version are you installing on? What happens if you access from Firefox? what do you mean exactly with ‘admin site’? What address appears in the URL bar when it says “connecting”?

Thanks

Daniel

Are you using the stack on Windows 2003? What are your security settings in internet explorer?

Install OS is Windows Server 2003; I didn’t notice any issues with Firefox and thought everything was great until I invited my fellow employees to test the blog site (we’re evaluating different blog systems for a corporate blog) when those using IE said they couldn’t access the site.

I tried to access explicit php files in the WordPress/htdocs/ root – such as the wp-login page and everything worked in IE—so, from IE I can administer the site from all the php pages under the WordPress/htdocs/wp-admin/ root but can’t view the site from WordPress/htdocs/ ...

I am using IE-7; the status bar shows “web site found, waiting for reply” and my security setting was ‘medium-high’ and reduced to ‘medium’ with no change.

I did a second download and install on my local and everything is fine in IE; I am considering an uninstall/reinstall

Hi,

I am pretty sure this is due to the security settings in IE. By default the configuration of IE in Windows 2003 is extremely restrictive and it is likely interfering. Can you reduce the security setting even further? Can you access other sites with it?

Hi,

I know this is an old topic, but I’m having a similiar issue. I’ve installed the Wordpress 2.5 stack on a couple of Windows XP SP2 machines and Internet Explorer times out going to the main wordpress site, but not the admin side. Is there anything you know that fixes this? I tried the lower security settings and it still doesn’t work.

Hi Allen,

I’m unable to reproduce this issue. What version of Internet Explorer are you using?

Cheers

I recently put this stack on a PC to create an intranet. I am having the same problem. The server responds as expected in Firefox, but X.X.X.X/wordpress just hangs with connecting…at bottom of browser with IE. I downloaded the stack yesterday April 30th; the IE browser is ver. 7.0.5730.13; running on clean install of XP ver. 2002 SP2; on a machine Dell 4700 2.8Ghz w/2G Ram.; with no other software other than OS, not even office. Both OS and browser have all the latest updates.

I have had other people on the network try to access it, but they get the same problem. Everyone can access the BitNami main page at x.x.x.x/ , but once they try to get to the /wordpress directory IE just hangs. Also the browser settings on all browsers are set to medium. I also added a simple website to /htdocs in apache, and the IE browser worked fine. The problem seems to be specific to wordpress.

Hi david,

I’ll try to get that same version to see if I can reproduce it this time.

Regards

antonio

Did you ever find out what the problem is? If I try to access X.X.X.X/wordpress via firefox anywhere on the network everything is ok, but using IE the browser just hangs.

No, I’m sorry but I wasn’t able to reproduce it :S

Hi!,

Can you check if you have configured a proxy server in IE?. If you have configured a proxy, you can try to add the wordpress machine IP into IE>Internet Options>Connections tab>Proxy Servers Advanced settings>Exceptions; and all IP’s that you add in this box will not be asked to the proxy server.

Good luck!,
Cheers.
Manu.

Hello Manu,

Access to X.X.X.X/wordpress works fine in FireFox, but not in IE, it just hangs. No matter what computer in the network I use.
None have a configured proxy server.

I just went to our UAT group and had them try to duplicate the problem; and they did. Wordpress hangs on IE Version 6, 7 and 8 beta.

-If I go to X.X.X.X/wordpress/ it just hangs.
-If I go to http://localhost/wordpress from the server itself, it also hangs.

-If I go to X.X.X.X/ it is lightning fast.
-If I go to X.X.X.X/wordpress/wp-admin/ it is also fast.
-If I go to X.X.X.X/otherfolders it is also OK.

It seems to be confined to wordpress homepage and is not browser version specific.

Are there any alternatives available to me at this point?

Thank you for your attention!

Can you check apache2/logs/error.log ? Maybe there’s something in there

Cheers

Do not see anything there that could cause this problem. The only consistant error was a missing favicon.ico file, which I fixed.

access.log file keeps repeating the following line 5 times a second during browser hang:
192.168.3.202 – - [29/May/2008:12:04:47 -0400] “GET /wordpress/ HTTP/1.1” 301 -

This error code means the following

10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI.
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.

Can you check if that happens also when using Firefox? Also, try to connect from IE using your LAN IP, not localhost.

Cheers

12:14 is IE request
12:21 is FF request

192.168.3.202 – - [29/May/2008:12:14:45 -0400] “GET /wordpress/ HTTP/1.1” 301 -
192.168.3.202 – - [29/May/2008:12:14:46 -0400] “GET /wordpress/ HTTP/1.1” 301 -
192.168.3.202 – - [29/May/2008:12:14:46 -0400] “GET /wordpress/ HTTP/1.1” 301 -
192.168.3.202 – - [29/May/2008:12:14:46 -0400] “GET /wordpress/ HTTP/1.1” 301 -
192.168.3.202 – - [29/May/2008:12:14:46 -0400] “GET /wordpress/ HTTP/1.1” 301 -
192.168.3.202 – - [29/May/2008:12:14:47 -0400] “GET /wordpress/ HTTP/1.1” 301 -
192.168.3.202 – - [29/May/2008:12:21:12 -0400] “GET /wordpress HTTP/1.1” 301 327
192.168.3.202 – - [29/May/2008:12:21:12 -0400] “GET /wordpress/ HTTP/1.1” 301 -
192.168.3.202 – - [29/May/2008:12:21:12 -0400] “GET /wordpress/ HTTP/1.1” 200 5843
192.168.3.202 – - [29/May/2008:12:21:12 -0400] “GET /wordpress/wp-content/themes/cleaker-21/style.css HTTP/1.1” 304 -

Only using LAN IP right now, from dev machine.

I’m sorry but I don’t know what may be happening, seems like IE is having problems with the redirection :S Have you tried another PHP BitNami Stack? I think this also happened with Mantis in the past, but again, we weren’t able to reproduce the issue.

Antonio & Manu,

Fixed it.

You are not going to believe the fix.

Went to: Settings/General Settings

WordPress address (URL):
Default was X.X.X.X:80/wordpress – Changed to X.X.X.X/wordpress

and

Blog address (URL):
Default was X.X.X.X:80/wordpress – Changed to X.X.X.X/wordpress

URL resolved without hanging.

Thank you for your assistance!

Finally! :)

Could you help us improve the stack then? Please install another Wordpress Stack instance while having the first one running so that it takes another port for the web server, and please check if you also have the problem using a different port. If not, I think that we can implement some logic in the installer so that it will work from the beginning.

Thanks!

Hi David!

First, thank you for your collaboration. This bug appears to be resolved for new Wordpress stacks.

Thanks! Best regards.
Manu.

No problem! Its so amazing how the most simple things can create the most havoc. I would have never guessed that the default of :80 would cause such a problem. It never even entered my mind, since that is the standard default.

Best regards with Stacks!

Keep em coming!!