Have a Question?

If you have a question, start typing or search for it below.

WordPress integration troubleshooting.

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.

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). Depending on the host, there are solutions to fixing your problem:

  • Dreamhost and Webfaction customers: 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 customers: 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.

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

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.