Transferring Media
Overview
The RAMP process to transfer attachments from the media library works as follows:
- Staging server sends URLs of attachments to be included in a batch.
- Production server then requests those files from the staging server, one at a time, and loads them in as Media on the production server (as it processes the batch).
Notes
Unattached media files are not supported for RAMP batches, only files that are associated with posts, pages, or custom post types. This is because WordPress core does not track revision data on attachments - we can't easily show "recently changed attachments" in a the RAMP staging screen like we can with other content.
Error (-32300): transport error - HTTP status code was not 200.
Typically this error means that the production server was unsuccessful in communicating with the staging server. It may mean that:
- 401 authentication is in place with no exception for the production server
- there are routing or DNS issues preventing the request from reaching the server
- there are firewall rules preventing the request from reaching the server
The first step in debugging this issue is to figure out why you are seeing the error.
- Determine the URL to the media file on the staging server
- Before trying anything else, attempt to load one of the media files in your browser
http://staging.example.com/wp-content/uploads/2014/01/example.jpg
Assuming that works as expected, we'll move on to seeing why the production server is having trouble doing what your browser did.
The following steps assume that you can SSH into your production server and can edit the files on that server.
- SSH in to the production server and type:
host staging.example.com(where staging.example.com is the URL of your staging server). Confirm that the IP address returned is indeed the IP address of the staging server. - Manual steps to confirm availability of the staging server media files to the production server using cURL from the command line:
Using cURL to Check for Problems
- SSH into the production server
- Run:
curl -I -v --request 'GET' your-media-file-url
For example:
curl -I -v --request 'GET' http://staging.example.com/wp-content/uploads/2014/01/example.jpg
A request will look something like this; the line starting with HTTP is the one we're particularly interested in, since it shows the status code. Here, a successful request (indicated by the HTTP/1.1 200 OK line - a 200 status code for "everything worked fine"):
$ curl -I -v --request 'GET' http://staging.example.com/wp-content/uploads/2000/01/media.jpg
* Hostname was NOT found in DNS cache
* Trying 10.10.10.42...
* Adding handle: conn: 0x7fd332808200
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fd332808200) send_pipe: 1, recv_pipe: 0
* Connected to staging.example.com (10.10.10.42) port 80 (#0)
> GET /wp-content/uploads/2000/01/media.jpg HTTP/1.1
> User-Agent: curl/7.34.0
> Host: staging.example.com
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: image/jpg
Content-Type: image/jpg
< Last-Modified: Wed, 09 Oct 2013 01:35:39 GMT
Last-Modified: Wed, 09 Oct 2013 01:35:39 GMT
* Server nginx is not blacklisted
< Server: nginx
Server: nginx
< Content-Length: 14022
Content-Length: 14022
<
* Excess found in a non pipelined read: excess = 14022 url = /wp-content/uploads/2000/01/media.jpg (zero-length body)
* Connection #0 to host staging.example.com left intact
A failed attempt will have a line starting with HTTP with some number other than 200 after it.
For instance, a common situation is that the staging server requires a username and password (often called "401 auth", due to the HTTP status code 401 it returns), which will result in:
HTTP/1.1 401 Authorization Required
If the 401 status code is present, please refer to this page.
Other common error codes include: 301, 302. This means the request resulted in a redirect.
If the cURL steps do not reveal a problem, or you do not have the ability to get a shell on your production server, it's time to dig a little deeper.
It's time to make a small modification to a WordPress core file so that we can get a little more information about what is happening.
Locate the wp-includes/class-IXR.php file; in class IXR_Client, function query(), change this line:
$this->error = new IXR_Error(-32300, 'transport error - HTTP status code was not 200');
to this:
$this->error = new IXR_Error(-32300, 'transport error - HTTP status code was not 200 - first line was ' . $line);
This should give us more information about the error being experienced and will likely indicate the configuration or communication issue being experienced.
Can RAMP-ing media files change them on the staging server?
In general, no. RAMP requests the file from the staging server just like a web browser would.
However, we have seen one customer's configuration where they had both the staging and production servers pointing their media libraries to the same directory on a shared drive. In this situation, the following process would occur:
- The production server would see that there was already a file in place on the file system, and delete it so that the new file could be written.
- The production server would request to download the file from staging via HTTP (just like a browser).
- The staging server would then respond that the requested file was not available (404 error); as it had been deleted.
This is a bit of an extreme edge case that we've only seen reported once, but are including it here for completeness. Please do not point your staging and production media libraries at the same directory.
Add your voice