Why doesn’t WP_Image_Editor save images using the Filesystem API?

I was in the process checking some of my existing plugins for any unsafe filesystem accesses, when I ran across WP_Image_Editor‘s save function, which calls _save, which finally calls make_image (below). WP_Image_Editor was released in WP 3.5, while the Filesystem API has been around since WP 2.6, so I would presume that the reasoning is related to the specifics of the use-case rather than just not being changed to meet new standards.

protected function make_image( $filename, $function, $arguments ) {
    if ( $stream = wp_is_stream( $filename ) ) {
        ob_start();
    } else {
        // The directory containing the original file may no longer exist when using a replication plugin.
        wp_mkdir_p( dirname( $filename ) );
    }

    $result = call_user_func_array( $function, $arguments );

    if ( $result && $stream ) {
        $contents = ob_get_contents();

        $fp = fopen( $filename, 'w' );

        if ( ! $fp )
            return false;

        fwrite( $fp, $contents );
        fclose( $fp );
    }

    if ( $stream ) {
        ob_end_clean();
    }

    return $result;
}

My question is, what are the reasons for this? According to Otto, directly accessing the filesystem is evil, so what are the exceptions that make it alright in this instance? I want my plugins to behave in the best way possible, but this makes best practices a little difficult to discern.

Related posts

Leave a Reply

1 comment

  1. Directly accessing the filesystem for writing is evil… for most of the cases where people are actually doing that.

    If you’re editing an image file, and it is in the wp-content/uploads directory, then you know, whatever. That’s not the common case. Plugins and themes don’t typically do that because they don’t have to do that. WordPress has the code to do that for them. That’s perfectly safe.

    No, the thing plugins and themes want to edit are the dangerous things. They want to write PHP files with config information, or save custom CSS files, or things like that. They want to write all those things which are not safe to be world-editable.

    If somebody on the same cheapo shared server as my site is decides to fiddle with my images and such, that’s an annoyance. If they decide to fiddle with my PHP code or my CSS, that’s a security breach. The question about directly writing to the filesystem being evil depends entirely on what you’re writing and in what context it is used.