Tag Archives: mysql

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

Import into WordPress 2.7.1

I’m in awe of the newly redesigned WordPress 2.7.1. The import of old posts went smoothly. Installing plugins is now such a breeze! The mass ‘port of the old blog into the new site is largely complete. Thanks to the following MySQL snippet that I used quite heavily, I’ve cleaned up most of the links referring back to the old host and old domain. Gotta love MySQL.

UPDATE table_name SET column_name = REPLACE(column_name,"original_text","replace_text")

Next on the to-do list: galleries!