WordPress troubleshooting

08 Feb, 2017 WordPress Integration 4

The vast majority of our customers don’t experience issues when their content is published from Camayak to their WordPress installation, but since our launch we’ve identified a few ways in which WordPress publishing can be interrupted.

Quick links

Our publishing destination URL isn’t being accepted
Camayak is telling us our publishing destination is returning invalid data
Camayak is telling us it doesn’t have the correct permissions
Our publishing destination sits behind Cloudflare
Our publishing destination uses Varnish
We aren’t able to upload media properly
Camayak is being rate limited by our hosting provider
Camayak is telling us that it can’t find a specific record anymore
Our WordPress database is down

Integration

URLs

When saving a publishing destination in Camayak, it’s imperative that the supplied URL follows the following criteria:

If no “www” has been supplied, and the webserver doesn’t serve without it, we won’t be able to validate the publishing destination and allow you to use it.
If your server has an SSL certificate, ensure that the URL starts with “https://” as Camayak won’t follow redirects.

XML-RPC file and response

Camayak communicates with WordPress using the XML-RPC API. When we create or update content on your behalf, we access a file called xmlrpc.php, and its location and response are crucial to ensuring that publishing isn’t interrupted.

By default the WordPress xmlrpc.php file is found at http://yourdomain.com/xmlrpc.php. If you cannot find it there, then it’s been deleted or moved. You can either move it back to the correct location, or save your publishing destination within Camayak by pointing to the exact location (e.g. http://yourdomain.com/directory/xmlrpc.php).
If you visit your xmlrpc.php page and find that it doesn’t result in a blank page with only “XML-RPC server accepts POST requests only.” (minus the quotes), then a plugin is preventing the file from working properly, and by connection with prevent Camayak from working properly. To see what a healthy xmlrpc.php file looks like, visit this support blog’s xmlrpc.php file.

In the event that the XML-RPC file has been modified, we recommend the following troubleshooting steps:

Deactivate as many plugins as you’re comfortable with, keeping track of any settings which you may have picked for them. Plugins are overwhelming the problem with faulty xmlrpc.php responses, because WordPress is built in such a way that plugins aren’t compartmentalised, so if a plugin is poorly written the rest of the website can be affected.
Verify that you don’t have any custom Apache/Nginx rules in place against the xmlrpc.php file.

Permissions

Camayak interacts with your WordPress website using the XML-RPC API. For publishing to work, a WordPress account needs to be created specifically for Camayak to publish with, this user’s username is often the same name as your publication, e.g. “New York Times”. To ensure that you take full advantage of Camayak’s publishing tools, we highly recommend that this user be made an administrator. If, however, you wish to have more granular control over the capabilities you assign the account, we’ve listed below a breakdown of the capabilities we require.

Please note:

Capabilities ending in an asterisk (*) require that the “New York Times” user be an administrator.
If you make use of a custom role manager plugin, and are experiencing issues publishing to your WordPress site, it may be implementing its own custom capabilities, preventing us from interacting with your website. Please email support@camayak.com if you require assistance.

User capabilities

create_users*
- Allows us to create WordPress accounts for bylines which don’t have one.
edit_users*
- Allows us to read a single WordPress account.
- Allows us to list WordPress accounts.
- Allows us to edit a WordPress account.
list_users*
- Allows us to determine if a byline has a WordPress account or not.
unfiltered_html
- Allows us to create and update posts with HTML in the body.
edit_published_posts
- Allows us to edit a post we’ve published.
edit_posts
- Allows us to edit posts on your behalf.
upload_files
- Allows us to upload a media object to your library.
- Allow us to retrieve metadata about an image we’ve uploaded.
- Allows us to list your media library after an image upload.

Post capabilities

create_posts
- Allows us to create posts on your behalf.
publish_posts
- Allows us to publish a post.
edit_post
- Allows us to edit an existing post.
add_post_meta
- Allow us to add to a post’s custom fields.
edit_post_meta
- Allows us to read and edit a post’s custom fields.
delete_post_meta
- Allows us to remove a custom field from a post.

Taxonomy capabilities

If you have registered a taxonomy, and the capabilities aren’t the default values (the same capabilities as posts), the following capabilities must be accessible to us:

edit_terms
- Allows us to add a term to a taxonomy.
assign_terms
- Allows us to read and list taxonomy terms.
- Allows us to read and list taxonomies.
- Allows us to assign a term to a post.
manage_terms
- Allows us to create terms on your behalf.

Third-party tools

Two third-party tools are known to sometimes be responsible for preventing communication between Camayak and WordPress.

Cloudflare

Cloudflare have a Web Application Firewall (WAF) setting called “Block WordPress XML-RPC”, this must be disabled if you are a Pro, Business, or Enterprise zone.

If you are a “free” tier, we suggest you add a “Page Rule”:

URL Pattern: /xmlrpc.php
Custom caching: Bypass cache
Apps: Off
Performance: Off
Security: Off
Security Level: Essentially Off

Please be aware that in the event that your WordPress website is down, Cloudflare may still serve a cached version of your pages but Camayak will not be able to create and/or update posts because interaction with the database isn’t possible. In these scenarios Camayak will send an email to the approval editor informing them.

Varnish

Varnish caching has been proven to cause publishing issues, as it prevents the xmlrpc.php file from communicating with our servers properly. We highly recommend that the following exception is added to your Varnish configuration file. If you are incapable of doing so, your web host may be able to do it for you.

if (req.url ~ "xmlrpc") {
    return (pipe);
}

This rule ensures that any URL which contains “xmlrpc” is bypassed.

Media

Uploading files

Camayak uploads media to WordPress publishing destinations using the wp.uploadFile XML-RPC method. Due to the way this method was built by the WordPress core team, our customers’ servers must be capable of receiving large HTTP POST requests.

If you or your approval editors receive emails from Camayak regarding media sizes, or that your website responded with invalid data, we suggest performing an audit of the following:

Does your server have enough memory? When an image is upload to us and approved for publishing, we send the same file back to WordPress, and due to the way that their uploadFile method works, the whole image is read into memory before being written to disk. If you don’t have enough memory, your website will either throw HTTP 413s (“Request Entity Too Large”) or HTTP 500s (“Internal Server Error”) depending on your webserver configuration.
If your webserver is Apache, increasing the KeptBodySize directive should alleviate “Request Entity Too Large” errors.

On the PHP side, check these two directives:

upload_max_filesize tells PHP how large an upload file can be.
post_max_size tells PHP how large the POST data can be (important because XML-RPC requests store the data in memory).

Saving files

It’s important that the WordPress uploads directory has the correct permissions. In the event that Camayak sends you or your approval editors an email about the directory not being writable, please verify that:

The parent directory is writable, or on the first publishing day of each month, it won’t be possible to create the month number as a sub-directory.
The month directory is writable, or on the first publishing day of each month, it won’t be possible to save your image in the sub-directory.

Please consult this WordPress post prior to changing file permissions.

Rate limiting

Some web hosts impose rate limiting and/or security restrictions on the WordPress XML-RPC functionality (how Camayak interacts with your publishing destination). If your hosting provider is listed below, or if Camayak emails you about rate limiting, there are solutions to fixing your problem:

Dreamhost and Webfaction

The former quite often impose rate limits on the number of requests Camayak can make with a WordPress installation. Their chosen method of informing services that they must lessen their requests is to return an HTTP 418 status code. The latter impose rate limits, and they do so by altering their Apache Httpd mod_security rules so that their customers’ /xmlrpc.php file can’t be communicated with more than 15 times in 3 minutes. This may sound like a lot, but a single Camayak approval could take upward of 5-10 requests, depending on the number of media assets and bylines.

Solution: both hosts won’t allow per-site customization of their Apache Httpd mod_security rules, so if you encounter publishing restrictions we suggest creating a symbolic link from the /xmlrpc.php file to a new file called /camayak.php. Once complete, in Camayak’s “Publishing destinations” page, navigate to the WordPress platform’s “Edit details” form and update the URL so that it becomes http://yourdomain.com/camayak.php.

Site5 and Web-hosting.com

In both cases these hosts will return sporadic 404s when their Apache Httpd mod_security rules (Site5) or HaProxy config (Web-hosting.com) detect a Camayak assignment being approved.

Solution: both hosts can be contacted so that our XML-RPC requests aren’t interrupted. Site5 can lessen their mod_security rules, and Web-hosting.com can whitelist your XML-RPC endpoint (http://yourdomain.com/xmlrpc.php) in HaProxy.

WP-Engine

WP-Engine are fairly agressive with their rate limiting. In the event that you experience trouble publishing to your WP-Engine hosted publishing destination and Camayak emails you regarding rate limiting, the only way to resolve the issue to have them whitelist our IP addresses, which are available here.

Have a Question?