Jump to content

mistahp

Members
  • Content Count

    7
  • Joined

  • Last visited

Posts posted by mistahp

  1. If you want to get really fancy, like if you intend this theme for public release and want to prevent the average user removing your credits, you can hook the wp_footer by adding to your theme's functions.php something like this:

     

    >function my_credit_links() {
    // your output here
    echo '<a href="foo">Name of theme</a>';
    }
    
    add_action('wp_footer','my_credit_links');

  2. The help desk wasn't as helpful as I would have expected, but I got it resolved anyway.

     

    The solution was a combination of three things.

     

    1. .htaccess needs this rule:

     

    ><IfModule mod_security.c>
    <Files async-upload.php>
    SecFilterEngine Off
    SecFilterScanPOST Off
    </Files>
    </IfModule>

     

    ...which selectively turns off mod_security for only the uploader.

     

    2. wp-content must be chmod to 777. The Flash uploader uses wp-content to store uploads temporarily before moving them to whatever's consistent with the blog's user-specified upload settings. The HTML uploader does not do this, so 755 is ok on that folder.

     

    3. The newest version of the Bad Behavior plugin (2.0.13) rejects the "Shockwave Flash" user agent, so one line in Bad Behavior's blacklist.php needs to be commented or removed. This one really threw me, because normally Bad Behavior returns a 417 error, not a 403.

     

    But, either way... the issue is now resolved and Flash uploads are working swimmingly for me.

  3. It authenticates as the appropriate WordPress user, but does not perform any other login steps.

     

    The HTML uploader works just fine with 777 permissions on the relevant folders, but the Flash uploader doesn't. I've messed around adjusting permissions on all sorts of things to no avail.

     

    I have a ticket open with the help desk. We'll see what they have to say.

  4. I've been working with svn and beta builds of WordPress 2.5 for a few weeks and now that it's final I have an issue.

     

    Part of the admin revamp is an all new interface for uploading images and other media. In browsers that support the feature (Firefox and Safari) a Flash-based multi-file uploader is used. In browsers that don't support the Flash uploader fully (Opera and Internet Explorer), a one-file-at-a-time HTML uploader is used. The HTML uploader works perfectly, but the Flash uploader does not.

     

    The multi-file uploading capability introduced in recent versions of Flash contains a bug that sends a malformed header to the server. Because of that header, Apache's mod_security rejects the upload out of hand with a 406 error. Following the troubleshooting advice of one of the WordPress developers, I've temporarily disabled mod_security by adding to my .htaccess

     

    >SecFilterEngine Off
    SecFilterScanPOST Off

     

    and this changes the problem but does not resolve it. Instead of a 406 error, the upload fails with a 403 error.

     

    In the testing surrounding this issue, the WP dev team eventually added to the default .htaccess rules

     

    ><IfModule mod_security.c>
    <Files async-upload.php>
    SecFilterEngine Off
    SecFilterScanPOST Off
    </Files>
    </IfModule>

     

    and this resolves the issue for most people, but not for me. Uploading images with Internet Explorer and Opera works fine because WordPress falls back to serving the HTML uploader to those browsers, but it always fails when WordPress serves the Flash uploader to Firefox and Safari.

     

    Through many e-mails with the developer who built the uploader (not the Flash applet itself, but all the parts of WordPress that use it), I've begun to suspect that this is a server configuration issue, that there's something about how TCH configures their machines that may be exacerbating the problem. All the potential fixes that I've seen fail to do anything for me.

     

    Does anyone have an idea on what might be the problem? Failing that, can anyone else confirm or refute this behavior on their own sites? (I'm hosted on grievous.)

×
×
  • Create New...