Tag Archives: plugin

Technical

Automation challenges: troubleshooting and fixing my own problems with a paid WP plugin

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.

Technical

WP auto upgrade/plugin updates, file owners and CHOWN

This has been a vexing activity lately: attempting to perform WP auto-updates and plugin updates on multiple WP installations end in failure. I thought the problem simply came down to deleting or chmodding 777 the offending directories (such as upgrades and/or uploads). When that turned out to be an unwieldy and insecure proposition, I turned to what I suspected might be an FTP issue, by switching to ProFTP server. Still unsuccessful, I suspected an SSH issue–no dice. A file system method switch in wp-config for WP? Nope, not that either. Trying to install suExec for PHP? It was already enabled, and forcing a recompile nearly crashed my server.

In the end, what gave me a clue was the section on file permissions in the WP codex and some forum posts suggesting ownership changes. A handy phpinfo-type script such as <--!? php echo(exec("whoami")); --> dropped in the appropriate directories aided in identifying ownership of certain folders.

It turns out that since I’ve been using FileZilla SFTP with root (yes, I know it’s highly insecure) credentials, I’d been carelessly uploading WordPress folders and plugins with root ownership, causing havoc with the auto-update system. Since the affected folders weren’t owned by the user, the user could not use their own ftp credentials to update their WP installations. I would either see error messages such as not being able to download files to the upgrades folder or unable to create plugin directories–all because the user did not own those folders.

Unfortunately, FileZilla doesn’t have a mechanism to check ownership. It only permitted chmodding file permissions, as far as I could tell. This of course created even more of a mess because I was chmodding under root, not user.

I used shell access (e.g. PuTTy) to identify ownership. To list folders and file ownership in a directory:

ls -l folderpath

To change ownership of a folderpath:

chown -R username:usergroup folderpath

where -R applies changes recursively. For my dedicated server setup, username and usergroup happened to be the same (I did not set up user groups in Apache). In this instance, folderpath referred to the root directory where WordPress was installed. Incidentally, changing the ownership of the folders reset all of the directory permissions to 755, and file permissions to 644–exactly how I wanted them.

This may have also corrected my issue with PHP sessions (still testing) with Captcha logins and form submission. I enabled PHP sessions and restored directory permissions on the working Captcha folders to 755. Will continue to test this.

Also, be wary of changing ownership on public_html. One of my sites had user:user ownership on the folder, causing the website to be inaccessible. Chown-ing the public_html back to user:nobody fixed the issue.

Technical

Hair-pulling Chrome bug

I’ve been experiencing a recurring problem with the Chrome browser that has other users pulling their hair out and switching back to Firefox. The issue is apparently an old one, in which the Chrome browser fails to render checkboxes correctly. Other users mention radio boxes are affected too.

In my quest to spin off my garden content into a separate blog, I’ve been dependent on a plugin to also port over the photo links. The Faster Insert plugin requires me to bulk select/deselect photos, and when the checkboxes disappear, that makes the task impossible. I hope that the Google team fixes this issue soon.

Technical

Testing Socialite

Let’s see if the Socialite addon will begin crossposting to MySpace and Facebook…

Edit: Well, apparently it doesn’t. The host has PHP5 and cURL turned on…so I have no clue why it’s not working. Too bad, this plugin showed great promise. But it seems the author hasn’t worked on it in awhile.

Edit 2: Well just now as I look at my FB wall, I see it…curious as to why it’s not showing up when I post originals…this warrants more testing.

Edit 3: FB wall looks like it is receiving the crossposts from Socialite. However MySpace is not working…which is really no big loss.