Issue with certain uploads and dynamic CSS creation.

[Grendel61]

Joe,

I had another issue that I opened before, that you can close out. I wanted to open a new issue, so we could try to figure this out.

I was having problems with a theme that writes out a CSS file dynamically, and it first checks to see that the file exists, and fails, causing the CSS for the whole site to be broken until I manually copy the CSS that gets created to the S3 directory with your copy utility.

Similarly, I have another app that was getting an error condition with respect to cover photos for a Buddypress Profile or Buddypress Group. I was able to fix the error condition on that one.

However, Buddypress Avatars which use the same process, are now failing. You upload the image and it can't find it because its already moved.

It seems that all of these issues resolve around the same problem wordpress, the theme, or plugin (in one case Buddypress) tries to lookup the file right after it is created, and fails.

I have a couple ideas how to fix this, but wanted to get your input. This seems to be happening only during the upload process or in the case of the dynamic CSS when it is being generated. It seems like it could be a timing issue. For example in all these cases, if there was already an uploaded image or a CSS S3-Uploads and Wordpress finds it fine to display it. It only is the check for an error condition, like the file didn't upload and the plugin wants to throw an error. Or maybe this is general problem with an absolute look up? Where the plugin looks in a directory its expecting to find things like TMP, and errors because it isn't there?

Your thoughts are appreciated.

[Grendel61]

Here is what finds the error condition. This is actually in the Wordpress wp-admin>includes>file.php

     * A writable uploads dir will pass this test. Again, there's no point
     * overriding this one.
     */
    if ( ! ( ( $uploads = wp_upload_dir( $time ) ) && false === $uploads['error'] ) ) {
        return call_user_func( $upload_error_handler, $file, $uploads['error'] );
    }

    $filename = wp_unique_filename( $uploads['path'], $file['name'], $unique_filename_callback );

    // Move the file to the uploads dir.
    $new_file = $uploads['path'] . "/$filename";
    if ( 'wp_handle_upload' === $action ) {
        $move_new_file = @ move_uploaded_file( $file['tmp_name'], $new_file );
    } else {
        $move_new_file = @ rename( $file['tmp_name'], $new_file );
    }

    if ( false === $move_new_file ) {
        if ( 0 === strpos( $uploads['basedir'], ABSPATH ) ) {
            $error_path = str_replace( ABSPATH, '', $uploads['basedir'] ) . $uploads['subdir'];
        } else {
            $error_path = basename( $uploads['basedir'] ) . $uploads['subdir'];
        }
        return $upload_error_handler( $file, sprintf( __('The uploaded file could not be moved to %s.' ), $error_path ) );
    }

[Grendel61]

[Grendel61]

As another idea. Is there way to exclude a directory? If we could exclude a directory within uploads (e.g. Temp directories) then we could eliminate the problem.

[Grendel61]

I've been looking into the ticket you wrote up on stream wrappers. This looks like the problem. I think that the issue I am having may be that you are copying the tmp directory on a media library attachments(?), but some of these other scenarios: avatars, and temporary CSS from the theme, may be failing because that fix you put in doesn't catch them.

[joehoyle]

@Grendel61 I'm possibly following along, however this would be a lot easier for me to dig into with an example plugin or piece of code that demonstrates the problem. If you can isolate the issue to a given plugin / theme and the S3 Uploads plugin, that gives me something reproducible to work with. I think that route is going to be easier than speculating why it's not functioning as expected.