WordPress.org

Support

Support » Installation » [Resolved] Upgrade to 2.2 – Dashboard not working

[Resolved] Upgrade to 2.2 – Dashboard not working

  • My blog is running on MySQL 4.0, phpMyAdmin 2.7.0.

    Hello,

    after the upgrade from 2.1.3 to 2.2, the dashboard doesn’t show the ‘Other WordPress News’, ‘WordPress Development Blog’,
    and the ‘Incoming Links’, but a ‘Forbidden’ message.

    The server error log shows the following:

    mod_security: Access denied with code 403.
    Pattern match “!(^application/x-www-form-urlencoded$|^multipart/form-data;)” at HEADER(“Content-Type”)
    [severity “EMERGENCY”] [uri “/wordpress/wp-admin/index-extra.php?jax=incominglinks”]
    (…) [uri “/wordpress/wp-admin/index-extra.php?jax=devnews”]
    (…) [uri “/wordpress/wp-admin/index-extra.php?jax=planetnews”]

    My server is running MySQL 4.1.20 and phpMyAdmin 2.8.2.4.

    Any ideas? Thanks.

Viewing 15 replies - 1 through 15 (of 55 total)
  • Hey, I got the same access denied error. When I enter the ‘forbidden’ uri in my browser, the page shows up just fine.

    The problem is how the mod_security rules are set up. If it’s your own server then go in to http.conf and change the rule

    # Only accept request encodings we know how to handle
    # we exclude GET requests from this because some(automated)
    # clients supply "text/html" as Content-Type
    SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
    SecFilterSelective HTTP_Content-Type "!(^application/x-www-form-urlencoded$|^multipart/form-data;|^text/xml;)"

    to

    `
    # Only accept request encodings we know how to handle
    # we exclude GET requests from this because some (automated)
    # clients supply “text/html” as Content-Type
    SecFilterSelective REQUEST_METHOD “!^(GET|HEAD)$” chain
    SecFilterSelective HTTP_Content-Type “!(^application/x-www-form-urlencoded;|^multipart/form-data;|^text/xml;)”

    The problem is that WP is adding a content encoding after the type and the mod_sec rules are expecting nothing after the type.


    Content-Type: application/x-www-form-urlencoded; charset=UTF-8

    Replace the $ with a ;.

    If it’s not your server then contact the administrator so they can change the rule to let the request through.

    Specks

    I need to change what I said before. Instead of changing the rule to add just a ; at the end of application/x-www-form-urlendcoded you need to add ;? this will match zero or 1 ; as adding the ; at the end will block all posts that don’t have a ; in the Content-Type field.

    Well isn’t that convenient 🙂 I hate having to contact the support dept.

    Thank you though.

    Why did WordPress change that in the first place? In all previous versions the dashboard was OK to me.
    Any tweaking of the source files to prevent this behavior?

    My host says I need to make the changes in my .htaccess file

    How would I go about this?

    Deerhunter04
    Member

    @deerhunter04

    I don’t have access to my http.conf, so .htaccess is all i can get. I put this in, but i still have the same error. Any other ideas on what to try?

    Same here…

    One thing to note, I’m not getting the same error.

    I’m getting:

    Forbidden
    You don’t have permission to access /wp-admin/index-extra.php on this server.

    I too put the code into .htaccess and got nothing.

    Why was this a vital change in the way WordPress works… it seems like more of a pain in the ass than it’s worth.

    bleh, just turn off mod_security for the wp-admin area:

    IF YOU DO NOT HAVE an .htaccess in your wp-admin/ directory:

    create a text file on your desktop:

    put the following inside it:

    <IfModule mod_security.c>
    SecFilterInheritance Off
    </IfModule>

    save the file.

    Upload the file to your wp-admin directory.

    Rename the uploaded file to .htaccess (with the .)

    IF YOU DO HAVE an .htaccess in your wp-admin/ directory:

    Edit it:

    <IfModule mod_security.c>
    SecFilterInheritance Off
    </IfModule>

    save the new .htaccess

    Post back if that helps. and if you do what I say, delete all that other crap.

    Deerhunter04
    Member

    @deerhunter04

    My error was the same as Righton’s. I went ahead and edited my .htaccess in my root directory and added this:

    <Files index-extra.php>
    SecFilterInheritance Off
    </Files>

    That fixed my problem. I didn’t want to turn off mod_security for the entire wp-admin folder, so this way just turns it off for index-extra.php file.

    there you go.

    i just talked to my hosting company and they told me that they are getting this error: [Thu May 17 13:41:39 2007] [error] [client 72.12.208.4] mod_security: Access denied with code 403. Pattern match “!(^application/x-www-form-urlencoded$|^multipart/form-data;)” at HEADER(“Content-Type”) [severity “EMERGENCY”] [hostname “loveju1ie.com”] [uri “/wp-admin/index-extra.php?jax=devnews”]

    how can this be fixed????

    Why did WordPress change that in the first place? In all previous versions the dashboard was OK to me.
    Any tweaking of the source files to prevent this behavior?

    WordPress has changed nothing in this area. The 2.2 version of the index-extra.php file is identical to the 2.1.3 version of the same file.

    The problem is that WP is adding a content encoding after the type and the mod_sec rules are expecting nothing after the type.

    Content-Type: application/x-www-form-urlencoded; charset=UTF-8

    Okay, WordPress *should* be sending back a type of “text/html” for these requests. Because in the index-extra file, it’s doing this:
    @header('Content-type: ' . get_option('html_type') . '; charset=' . get_option('blog_charset'));

    And in upgrade_schema.php, you have this:
    add_option('html_type', 'text/html');

    The html_type should be text/html. Not form or anything else.

    its been discussed, and both I and deerhunter JUST provided solutions. Instead of typing, read.

    The latest .htaccess fix works!

    Thanks!

Viewing 15 replies - 1 through 15 (of 55 total)
  • The topic ‘[Resolved] Upgrade to 2.2 – Dashboard not working’ is closed to new replies.