The MU forums have moved to WordPress.org

IE won't log in: wants to download/save wp-login.php? (16 posts)

  1. dgilmour
    Member
    Posted 12 years ago #

    I'd appreciate any pointers for where to look with this one. It doesn't make sense to me, so I need to learn a bit more but don't know where to focus.

    Attempts to use IE to login to new blogs fail. Clicking the link to wp-login.php results in IE wanting to download/save the wp-login.php file instead of running the script and displaying the login username/password dialogue box. Firefox and Safari work normally.

    Example problem blog: http://edubuzz.org/blogs/p7yester2008/wp-login.php
    Any older blogs tested, e.g. http://edubuzz.org/blogs/student2/wp-login.php , have been OK.

    There is a similar previous post http://mu.wordpress.org/forums/topic.php?id=6216 .
    In that one, disabling plugins was the solution. I have disabled all plugins, but that hasn't helped.

    The problem has been replicated with a number of different PCs, with both IE6 and IE7.
    The problem has only been seen since 1.3.3 upgrade.
    The site uses WPMU object caching ((define('ENABLE_CACHE', true);). Switching that off hasn't helped.

    Setting Apache LogLevel to debug doesn't generate any helpful errors in error_log.
    PHP is logging (E_ALL & ~E_NOTICE) to syslog but nothing there looks relevant.

    Environment is: WPMU 1.3.3, Apache 2.0.55 Ubuntu, PHP V5.1.2, using CGI/1.1 gateway interface, My SQL 5.0.22

  2. dgilmour
    Member
    Posted 12 years ago #

    Today I've gathered some more information. It points to encoding, but I can't see how the encoding-related difference I've found could cause the symptoms I'm getting. Does anyone know if there could be a link, or have a better idea?

    Details:
    1. If I use IE to log in to an older blog which doesn't show this problem, the backend menu options work.

    2. If I stay logged in and change to the backend of a problem blog, any attempt to use a menu option there, such as Write, results in an attempt to download/save the corresponding PHP script.

    3. The new blogs which have this problem have been created with "Encoding for Pages and Feeds" (under Options/Reading) left blank - I don't know why. Older blogs without this problem have it set to UTF-8. DB_CHARSET is set to 'latin1' in wp-config.php following problems with display of some characters after 1.3.3 upgrade.

    4. Encoding value in Options / Reading can be manually changed to UTF-8, and that gets stored OK, but it doesn't solve the problem.

    5. A database mysqldump file has create table statements which specify latin1 encoding for all tables of both faulty and working blogs, e.g.

    CREATE TABLE wp_1007_postmeta (
    ...
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

  3. dgilmour
    Member
    Posted 12 years ago #

    Raised call with hosting company. They claim that the problem is with .htaccess rewrite rules, but haven't provided any evidence to support that.

    The right files are being located, so rewrite seems to be happening correctly. Now puzzled. Don't see how an error in rewrite rules could cause the URL to be correctly rewritten to point to the correct script files, but cause them to be downloaded, not processed? And only for some blogs?

  4. macgruder
    Member
    Posted 12 years ago #

    What headers are your servers sending? That's probably where the problem lies.

  5. dgilmour
    Member
    Posted 12 years ago #

    Thanks macgruder, I'll check that.

  6. infobih
    Member
    Posted 12 years ago #

    I have same problem after upgrade to 1.5.1. It gives error ciode 302 for every single post/ My installation is subdomains MU

  7. dgilmour
    Member
    Posted 12 years ago #

    @macgruder: Thanks, this gives a clue. Blogs that work send:

    Content-Type: text/html; charset=UTF-8

    Those that don't (newer blogs created since 1.3.3 upgrade) send:

    Content-Type: ; charset=UTF-8

    Next question is why...

  8. dgilmour
    Member
    Posted 12 years ago #

    Editing blogs shows that faulty blogs have no "Html Type" field, which exists and is set to text/html on healthy blogs.

  9. lunabyte
    Member
    Posted 12 years ago #

    Have you tried hard coding that part into wp-login.php, to verify that's the issue?

  10. dgilmour
    Member
    Posted 12 years ago #

    Thanks lunabyte, I've now tried that. Replacing (line 37):

    <meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

    with

    <meta http-equiv="Content-Type" content="text/html; charset=<?php bloginfo('charset'); ?>" />

    led to wp-login.php still wanting to download in IE.

    And examining headers with Live HTTP headers shows that we still have Content-Type blank.

    Extract from Live HTTP headers:

    http://edubuzz.org/blogs/rossbiology/wp-login.php

    GET /blogs/rossbiology/wp-login.php HTTP/1.1
    Host: edubuzz.org
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    Accept-Language: en-gb,en;q=0.5
    ...

    HTTP/1.x 200 OK
    Date: Wed, 21 May 2008 22:58:45 GMT
    Server: Apache/2.0.55 (Ubuntu) mod_ssl/2.0.55 OpenSSL/0.9.8a
    X-Powered-By: PHP/5.1.2
    ...
    Connection: Keep-Alive
    Transfer-Encoding: chunked
    Content-Type: ; charset=UTF-8

  11. dgilmour
    Member
    Posted 12 years ago #

    I've now found that the problem blogs are being created without most of the options data that should be visible in the Edit interface. I've confirmed that by examining the wp_<blog ID>_options tables.

    The missing fields include "HTML Type", which is normally set to text/html. This is probably why HTML headers are missing this info, leading to IE offering to download/save the login.php file.

  12. MrBrian
    Member
    Posted 12 years ago #

    Have you added the option and confirmed that was what caused it? You might try upgrading to latest trac version.

  13. billdennis5
    Member
    Posted 12 years ago #

    Contact your host. Chances are they are using a program called eAccelerate that is causing this.

  14. dgilmour
    Member
    Posted 12 years ago #

    @MrBrian: Creating a string of test blogs (using Site Admin/Blogs/Add Blog) I've found that every second blog is created properly. (They have the full set of "Edit Blog" settings, including "HTML Type", work properly in IE, and have the correct HTML header as follows:
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />)

    What I now need to figure out is how on earth the same 1.3.3 scripts (even with all plugins, mu and user, removed) can alternately produce faulty and good blogs. What could be changing? Any pointers appreciated.

  15. dgilmour
    Member
    Posted 12 years ago #

    @MrBrian: I have now upgraded from 1.3.3 to 1.5.1 and creation of new blogs is working properly. (Took Donncha's advice in this thread to take things one step at a time.)

  16. MrBrian
    Member
    Posted 12 years ago #

    Glad you got it working :)

About this Topic

  • Started 12 years ago by dgilmour
  • Latest reply from MrBrian