Tag Archives: wordpress

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

Free hosting: a quick look at x10Hosting

Free webhosting: sounds gimmicky and risky, right? Deliberately concocted to dupe and ensnare the miserly and unwary? Nearly a decade ago while I shopped for hosting companies to serve small business websites, I would have definitely scoffed at the notion of free hosting; I mean it was a scam, am I right? But in today’s ever-changing competitive hosting market, it’s considered savvy marketing and standard practice. For companies offering free hosting (like free domains were a scant few years ago), the service represents the proverbial foot in the door, a chance to pry open the wallets of potential customers.

Because moving out to a rural suburb forced a downgrade in my internet access speeds, self-hosting became problematic. Reliability of my home connection was a constant concern, and the blogging itch became too incessant to put off for much longer while I played in a Linux and Webmin/Virtualmin sandbox.

So as a consumer, I had already ticked off some boxes as to my needs since I already had my website backed up in cPanel, MySQL and WP exports. I was also bringing my own domain (registered at Sitelutions), and I had plenty of experience in web server administration and web design that didn’t require a 1-click solution.

Primary traits to determine my ideal hosting company were: Linux/Apache environment, cPanel administration, storage space and FTP access, PHP/MySQL for WordPress installs, forced ads, server location, and to a lesser degree, CPU/bandwidth limits and support options.

x10hostingEnter x10Hosting. For photo-heavy blogs, storage space is critical. A full backup of epicureasian.com and its garden subdomain weighs in the vicinity of 2GB, a size that most free hosts do not accommodate. Storage space isn’t front page marketing for x10Hosting; I had to sift through their site and community forum for the actual storage limits. Third party reviews of x10Hosting indicated unlimited storage, but x10Hosting restricts individual file sizes and the types of files stored on their servers per their TOS.  Unmetered disk space must also be requested after certain benchmarks have been surpassed.

After hurdling over some of the barriers of accessing the account (namely getting my account suspended after inactivity, initial storage being capped at 512MB), my experience in setting up a website and administering it was relatively painless and trouble-free. A solid and responsive community forum was key to my selecting x10Hosting for my website’s current home. The ability to switch cPanel themes from x10-branded to the original cPanel 11 skin made the migration seamless. English-speaking support, live status reporting, and a server located in the US (apparently in Tilton, NH) also relieved my anxieties over dealing with international hosting.

If I had a few quibbles with x10Hosting, I would have to argue that the 30-day login requirement is my biggest one. But self-hosting always ingrained in me the habit of checking my admin panel regularly. Another complaint would be the stale information about upgrades posted on their site. My positive experience with the free hosting so far encouraged me to commit to and pay for upgraded support, but it seems x10Hosting disabled this portal to reorganize and relaunch their offerings at a later date. PHP and MySQL limits also may put the brakes on any development work I might want to dabble in, since that might exceed x10Hosting’s restrictions. And caps on email, ftp, and domain accounts, though reasonable, seem lower than some of the competition. With no uptime guarantees and no automatic backups, it’s always a risk that I will lose access to my current content if I’m not vigilant with monitoring. But at this price point, my experience with  x10Hosting’s free product trumps my previous relationships with shared hosting services.

After setting up my account in December 2015, I am pleased to report that my site runs has run without disruption or performance issues so far, and therefore I recommend x10Hosting to anybody looking for an entry point into free webhosting.

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

Protecting copyrights

I’ve had a run-in with scrapers and sploggers about a couple of years ago when my main site was exposed to the public. After locking down the info and making the domain private, I’m now thinking of more proactive ways to protect a blog site. Since the garden info is slowing being spun off to its own domain, I’ve taken action to post a Creative Commons license after each section with the help of the Open Attribute plugin. I’ve also bolstered the contact form by going with the Fast Secure Form, related to the SI Captcha anti-spam plugin. I’m wary of opening up comments, pingbacks and trackbacks at the moment until I determine if FriendConnect will allow users to register and follow my blog without a formal WP-based registration.

Meanwhile I have to be vigilant. I have Akismet, and I need to review my Analytics stats to ensure that I’m not being targetted by leeches. Of course, I also can look up who’s been duplicating my content on Copyscape.com. And I should think about watermarking my photographs…amateur as they are.

Technical

Modding WordPress themes

I planned on upgrading the visuals on the spinoff garden site with some fancy new graphics. But I also discovered that I could easily change the headline fonts by using Google web fonts. I also added a custom-colored dragonfly favicon to the site via an online editor.

I also integrated the Google Friend Connect system to the new site, but I’m still having a hard time comprehending all of its functions. It seems much of it is disconnected from Google itself, and I’m not sure how practical an addition it will be. The issue I’m experiencing relates to the commenting system, and so far all I’ve been getting is a message stating: “We’re sorry…We were unable to handle your request. Please try again or return a bit later.”

Last task related to the new site is opening comments/pingbacks/trackbacks. Putting the site up publicly risks spamming, but I think the experience will give me an opportunity to learn how to prevent attacks in the future.

Update: got some help from the GFC wiki installation document. Looks like the GFC comments works and has replaced the native WP commenting system.