Published content has been sparse lately due to an issue I faced with a premium plugin that assisted automating feeds to multiple social networking platforms, aka NextScripts Social Network Auto Poster. The issue came to my attention in late October, early November, when I resumed tinkering around with my main (source) site. WordPress, of course, had released upgrades since I last posted in September, which also prompted a slew of plugin updates. Bizarrely, only self-hosted WP cross-posting was affected; other networks such as Instagram, Blogger/Google, and WordPress.com were not experiencing the issue. Thinking the plugin might be at fault (specifically the WP code/api), I opened a ticket at NextScripts for support on November 1.

Well, it’s 6 weeks later and NOT A SINGLE RESPONSE FROM DEV about my still-open ticket. The only feedback I had was from a forum participant who suggested my SNAP woes (parse error not well formed) were due to an encoding issue. A few Google searches seemed to agree with this diagnosis.

So I checked and cleaned up databases at my source and target self-hosted WP sites–it was remotely possible that interim WP updates might have “corrupted” my databases. But quick peeks under the db hoods seem to suggest nothing fishy with the collation or character sets–and I had seen no evidence of junk characters appearing in my blog. Just to be certain, I exported all my data, recreated databases and users anew, deleted stale data leftover from bygone plugins and past WP iterations, and uploaded data into the new tables. To no avail!

I implemented WP hardening, thanks to a bit of paranoia that suggested a compromised install. To make sure that my WP install wasn’t corrupted, hacked or even hijacked, I checked file permissions on the source host, downloaded fresh copies of WordPress core, and uploaded them to the host. I ran Wordfence security scans to ensure I wasn’t missing an errant bit of code or a hole I missed. I looked over every line in wp_config.php to make sure the options were correct and even enabled/disabled WP debugging to see if I could find the issue. I changed my WP passwords to ensure that non-alphanumerics weren’t the cause of the problem. And just to test my PHP coding knowledge, I started looking over the WP code for XMLRPC until I went bleary eyed with all lines I had to sift through. I went so far as to sign up for WordPress beta testing in case some outdated WP code might not be passing muster with the host configs. No dice!

At this point, I concluded that it wasn’t the things I had complete control over that were the source of the problems. With plugin help visibly MIA/unavailable, it was time to investigate the hosted environments. What was so different with my self-hosted servers from the WordPress.com sites? Shared web hosting plans can be notoriously unreliable depending on the nature of your website, even if they aggressively advertise how “WordPress-friendly” they are. Usage limits, content restrictions, and hosting configurations can confound even the most basic vanilla WP installs.

While Google-shooting my plugin issue, I found similar complaints with the Jetpack plugin and other remote publishing apps, so I followed the technical support proffered for the competing product. Varnish Cache issues? Varnish validation seem to suggest otherwise. Problem .htaccess permission issues? Generated a new file, remarked out unneeded lines. PHP versions and missing libraries? Tried all the different flavors and checked configuration pages to make sure the appropriate extensions were loaded. Ran some cURL tests to validate this as well.

A noticeable difference among the hosts I worked on to serve my sites were in the database and web hosting software used. Some deployed Apache/MySQL in a traditional LAMP (Linux-Apache-MySQL-PHP) stack. Some hosts used Nginx, some used MariaDB. After researching MariaDB and confirming that hosts were using the latest stable build, I decided that the Apache/Nginx difference was key in trying to work around the issue. This explained why some .htaccess rules were being honored like the snippets below.

# Disable modsecurity filter for xmlrpc
<Files xmlrpc.php>
SecFilterInheritance Off
</Files>

<FilesMatch "xmlrpc\.php$">
Satisfy Any
#Allow from yourdomain.com
#Allow from yourdomainip
Require host yourdomain.com
Require ip yourdomainip
#Deny from all
</FilesMatch>

Nginx doesn’t allow user-level control in an .htaccess file; server blocks are implemented in server-level configs. It seemed likely that the Nginx environment was set up to block XMLRPC calls, and if Varnish/Nginx were conspiring in tandem, then there was no way I could implement a fix myself. My only recourse to solve the issue was to move my sites off the Nginx hosts. Once that happened, automation started working again.

What was most frustrating about all this is the utter lack of feedback from the plugin developer. There was nothing in the online FAQs that helped me research this problem, no activity on the ticket I raised, and zero leads in the plugin community. Even a reply as simple as “check your host” or “will get back to you” would have been appreciated, though not necessarily the premium support one would expect after weeks of no comment. A premium plugin would not be a good investment if my site had more than one user or more bandwidth to support (but silly me, I paid for the thing anyway). I wouldn’t recommend business-critical or high-traffic sites subscribing to this plugin unless it’s tested to work in their hosted environment. Of course, you get what you pay for in some hosting environments, particularly shared or free ones.