XML-RPC MetaWeblog newMediaObject overwrite problem

Reading through the code, that sounds like it’s working to me. That’s what it is supposed to do.

Overwrite set to true causes a new filename to be created in order to prevent browser-caching from confusing up your view of the file in a browser. It also causes the old attachment post (and the old file itself) to be deleted from the system.

With overwrite set to false, you’re creating an entirely new attachment post instead of removing the old one first.

Thanks. The caching solution sounds good to me. However, the old file does not seem to be deleted from the system for me. Is it supposed to get deleted instantaneously or all old files get deleted on a schedule (e.g. once per day)?

It should be deleted immediately. Perhaps your permissions are set wrong so it can’t delete the file.

Ok, thanks. In my case, I it does not delete it at all but at the same time I realized that the newMediaObject does not create the attachment post… it just uploads the file to the filesystem. Maybe that is the reason why it also does not delete it after. Do you believe it is a bug or is there something in my code that prevents creation of the attachment post?

I believe the following code is causing this problem:

if(!empty($data["overwrite"]) && ($data["overwrite"] == true)) {
          // Get postmeta info on the object.
          $old_file = $wpdb->get_row("
              SELECT ID
              FROM {$wpdb->posts}
              WHERE post_title = '{$name}'
                  AND post_type = 'attachment'
          ");

          // Delete previous file.
          wp_delete_attachment($old_file->ID);

          // Make sure the new name is different by pre-pending the
          // previous post id.
          $filename = preg_replace("/^wpid\d+-/", "", $name);
          $name = "wpid{$old_file->ID}-{$filename}";
      }

      $upload = wp_upload_bits($name, $type, $bits);
      if ( ! empty($upload['error']) ) {
          $errorString = sprintf(__('Could not write file %1$s (%2$s)'), $name, $upload['error']);
          logIO('O', '(MW) ' . $errorString);
          return new IXR_Error(500, $errorString);
      }
      // Construct the attachment array
      // attach to post_id -1
      $post_id = -1;
      $attachment = array(
          'post_title' => $name,
          'post_content' => '',
          'post_type' => 'attachment',
          'post_parent' => $post_id,
          'post_mime_type' => $type,
          'guid' => $upload[ 'url' ]
      );

      // Save the data
      $id = wp_insert_attachment( $attachment, $upload[ 'file' ], $post_id );
      wp_update_attachment_metadata( $id, wp_generate_attachment_metadata( $id, $upload['file'] ) );

Notice that the $post_id here is being set to -1. I believe this is incorrect because whenever I upload an image via the WP GUI, the post_parent field is set to 0.

Using metaWeblog.newMediaObject does not result in any record being created in the wp_posts table using the -1 parent post value. However, I tried changing that to 0 (xmlrpc.php line 2877 in version 2.8.4 of WP) and a record in the wp_posts table is now being created. I have yet to verify that a file is correctly overwritten when using overwrite=true using the XMLRPC call; but I’m guessing since there’s an actual record in the database pointing to the uploaded image, that it will be properly overwritten when wp_delete_attachment() is called.

The -1 is a known bug in the current version of the system: https://core.trac.www.ads-software.com/ticket/10521

Changing it to zero there and again in the query at line 2272 is known to correct the problem, for now. You have to change it both places though, otherwise attachments uploaded won’t attach to the correct post parent, when they’re created for a new post.

Ah, thank you for the response. I’ll be sure to look in the issue tracker first next time.

Hi, I still seem to be having an issue with files not being removed from the filesystem whenever specifying overwrite to be true (and this is with v2.7.1 and WP Mu). I’m running WP Mu against a MySQL 5.1 database (which does not exhibit the -1 issue discussed above because the -1 is automatically converted to a 0 due to a default value on the column in question). I also did not see anything related to file overwriting in your issue tracker.

Steps to reproduce:

1. Create a new media object via XML-RPC.
2. Attempt to create the same media object via XML-RPC with overwrite=true
3. Notice in the uploads directory there are 2 files when there should be 1.