Plug-in proliferation
So, you’ve decided on an off-the-shelf WordPress theme of some sort or are going to roll your own. But you need extra functionality. What about plug-ins? First, here’s a contradiction you run into all the time. Everybody says to use plug-ins for extra functionality so you avoid theme-vendor lock-in. But at the same time, everybody also says don’t use plug-ins if you don’t have to. Why are people talking out of the other side of their mouth here? Three reasons:
- Plug-ins are security risks. Many plug-ins are poorly coded, and most WordPress sites that get hacked are compromised by exploiting plug-in vulnerabilities.
- Too many plug-ins can slow down your site.
- Plug-ins can conflict with each other. (See above: many are poorly coded.) The more plug-ins you’re running, the more potential for conflicts. Even with plug-ins that are well-coded, conflicts might still occur on occasion.
Obviously, you can’t both use and not use plug-ins at the same time, right? What gives? Part of the problem is admittedly the poor quality of so many plug-ins. This is purely my own personal opinion, but based on the reviews I see on WordPress.org, along with my own experience trying out different plug-ins, just as a rough guess I would say at least 50% of the plug-ins out there shouldn’t be listed. At least. As a minimum. They either don’t work as advertised, performance may be slow, they may have poor user interfaces, aren’t kept up to date, aren’t well-supported, or, well, you get the picture.
Keep in mind this rule of thumb: The more something is democratized, the lower the bar is typically set, and the more crap will be let in the back door — heck, the front door. I’m not saying democracy is bad, but it comes at a cost, often a significant cost. The cost is all the rabble that’s enabled. WordPress is an open-source CMS platform, and the most popular, which means anyone can write a plug-in. Caveat emptor.
Two suggestions for winnowing out the crap
First, read reviews, and not just on WordPress.org. Cast your net widely. Look into discussion forums to get a wider range of opinions, and try to find blog posts or reviews from independent WordPress commentators as well. This is an area where the experts can be of immense help. (But when it comes to the latter, try to discover if they may be shilling for certain plug-ins due to affiliate ties.)
Two red flags. If a free plug-in isn’t being regularly updated (at least within the last year, and hopefully at least every few months), and you don’t see evidence that the developer is actively supporting it on their support forum, you should probably go elsewhere unless it’s a very mature or stable plug-in serving a niche where change/obsolescence is infrequent.
Free may be a Faustian bargain. Second, and it may be controversial to say this, avoid free plug-ins unless they meet the following two criteria:
- A worthy free plug-in should have an extremely wide user base so that it approaches being one of the primary “go-to” plug-ins or standards for a particular need. For a WordPress plug-in that serves a fairly common need, and assuming it hasn’t just recently launched, you should see active-install numbers in the tens of thousands or higher (as shown on WordPress.org), or for less-common needs, usually at least a thousand or two or more.
- And preferably, if a plug-in is free, it’s typically a better situation if it’s free because it’s the “gateway” version to a more featured-filled, paid version of the same plug-in. (In which case you should probably consider using the paid version if the plug-in performs a function you depend on heavily.)
Developers who aren’t making money from their plug-ins to support themselves aren’t going to be around for the long-term unless they have another income source, are extremely altruistic, or are in need of an ongoing ego boost, and that doesn’t describe many of them. You don’t want to become dependent on a free plug-in for a critical need, only to have it be abandoned at some date. This is my opinion, of course, but free is often a Faustian bargain. Consider carefully.
Situations where site functions may be better handled at the web-server level
Beyond the above, if there is one general piece of advice I could offer about plug-ins, it would be this: even if you are a do-it-yourselfer and may be inclined to perform everything that you can yourself with plug-ins, there are certain very important site functions it may well be better not to use plug-ins for, and instead handle in other ways. The three most important of these are website security, backups, and site caching (for faster page loads).
As time goes on, more web hosting companies are beginning to offer these as server-level functions that may be incorporated into the specific hosting package you pick or subscribe to, depending on how much you pay. In general they are superior to the functionality you will get with a plug-in, more robust, and will save you time and headaches, and may also save you money. Again, I’ll relate examples from my own learning experience.
Website security
While website security is always mentioned by experts as something important you need to address, based on the various articles I have read on the topic, I don’t think generally they probably emphasize how critically paramount it is. I found out the hard way it should be one of your utmost priorities second to none, but I certainly did not realize just how critical, based on the various articles about it I had read.
When I was building my website here, I did not use a staging domain or server, but instead, to keep things simple, just built it right on WardNicholson.com out in the open. Even though the in-progress, under-construction version of the site with dummy test pages and so on was therefore publicly accessible, to keep things at least semiprivate until it was ready for release, I simply used my robots.txt file to exclude search robots like Google and Bing from indexing the site in the meantime.
As the months passed, I implemented increasing site functionality with plug-ins, and more and more thorough and complete CSS styling of the typography, but certain things I put off till later due to lack of time for research and testing, one of which was security. I certainly planned to eventually get to it, but at that time I didn’t realize how easily WordPress sites could be hacked if not adequately protected, or that plug-ins were such key points of vulnerability. With many other things in various stages of construction, testing, and troubleshooting, I kept pushing it back.
A rude wake-up call. Then, one day, I got a notice from my web host that my site had been hacked. It turned out that 40 backdoors had been planted, and I soon discovered the site had already been blacklisted by McAfee. All in just a two or three-day period. This got my attention immediately while everything else ground to a halt.
One of the things that most website owners probably don’t think of or aren’t aware of — I certainly wasn’t until that point — is if your site gets hacked, it will be blacklisted by Google, McAfee, and other search engines and antivirus or security firms. Then, once you get the site cleaned up, you have to apply to be de-blacklisted, and you have to jump through the right hoops the right way, or you won’t be taken off the firms’ blacklists.
While I am typically inclined to do as much as possible myself, it took me only an afternoon’s research to realize after investigating WordPress website security that while I might possibly be able to set up a security plug-in to protect the site, it was a thorny proposition ensuring the job was done right, and even then, would probably be an ongoing headache. Even worse, I really had no idea how to clean up my hacked site, and could foresee only that it might take days or weeks of research to figure it out. Even then, without absolute confidence that I could do the job right, I didn’t want the responsibility or yet another time sink like that.
Sucuri’s CloudProxy security firewall service. It also didn’t take long to see that most roads lead to the security firm Sucuri as head and shoulders above anyone else out there for cleaning up hacked sites, plus they offered the top-rated turnkey security solution on the market available for a yearly subscription fee, their CloudProxy website application firewall (WAF) for preventing website hacks in the first place. The best thing about which is their guarantee that if by some rare chance you are hacked even with CloudProxy in place, they will both clean up the hack and get your site de-blacklisted as part of the subscription package.
While the $200/year ($17/month) subscription seemed somewhat costly to me, it was also apparent that compared to the damage a hacked site could cause — blacklisting of your site from search listings and damage to your site’s reputation, as well as drive-by malware downloads to visitors’ computers, your site being used for fraudulent phishing pages to steal credit card data, SEO spam, etc. — the alternate tradeoff was worse. Also, while there are free security plug-ins available, the yearly licensing cost of the better for-pay versions typically runs something like $80 to $100 yearly, so the additional $100 paid to Sucuri in comparison to get the best in the business is not hugely more. Not to mention, they do it all with very little extra required on your part or on your site, and the entire responsibility is “all on them” if something goes wrong.
So that is the route I have taken, but there are other non-plug-in avenues as well. For example, SiteGround, the hosting firm I am now with, has its own WAF like Sucuri’s that I would imagine is probably nearly in the same ballpark in terms of robustness, although they do not offer site clean-up or de-blacklisting if you are hacked. For that, like most other web hosts, they will refer you to Sucuri, so it’s evident Sucuri has a leg up on most everyone else in this regard.
Website backup
Back up or be had… eventually. You are backing up your site aren’t you? If you don’t realize the importance of this, I won’t try to convince you. But if you don’t realize it, eventually one day you’ll be shocked out of your complacency when you lose something utterly important with no means of getting it back, or your site is hacked or trashed in some other way, and the panic will start flooding over you at the same time you begin feeling sick to your stomach over the loss. It happens to everyone eventually. Then you’ll believe.
Site backup is another area where I have come to think it is better to perform the task by some other route than using a plug-in. I mentioned above that I have used BackupBuddy, which is one of the top two or three premium backup plug-ins. However, over time, I have found it to be somewhat temperamental in terms of throwing errors and aborting backups. Things will go along fine for a few weeks or a month or two or three, then it starts throwing errors again. You think you have pinpointed the cause and fixed things, then it starts doing it again another month or two down the line.
This caused me to start thinking, gee, what if something happened (something always eventually does, in my experience, sooner or later) and I needed to restore from a backup that happened to fail the night before? Then where would I be? Plug-ins being subject to conflicts and sometimes acting up anyway, should I really be entrusting something as critical as site backup to one?
Backups performed by your hosting service are typically free and can be good, but it may take a customer support request to restore your site from one. As long as your web host behaves honorably and has good tech support, this may be all you need. Do be sure, though, that you make daily backups of the WordPress database (containing your pages, posts, reader comments, media library, and so forth), plus a full backup of the entire site at least weekly (which includes your theme, plug-ins, and everything else from the root httpdocs or public_html folder on down), or more often if things change frequently. Keep in mind, though, that while you might want to take advantage of host-based backups (whether performed by a plug-in or your hosting service), you should also strongly consider off-site backups as well.
Off-site, third-party website backup services are more robust for at least a couple of reasons:
- First, should your hosting service itself ever experience a catastrophic failure or meltdown of some sort (admittedly rare, but not inconceivable) and loses your backups, you’ll have a backup elsewhere to restore from.
- A second advantage to third-party, off-site backups is they can’t be held hostage by your hosting service. Should you get into any kind of a dispute with them, and you decide or realize they aren’t going to do what’s honorable to resolve the dispute, you can simply kiss the suckers goodbye and move to another host if need be. Admittedly their behavior would have to seriously undermine your trust for things to come to that, but it has happened and isn’t unheard of.
How off-site backups work. Backup firms that offer backup service subscriptions utilize FTP to back up your site directly from your web host’s server to the backup firm’s server. The advantage of this is that not only are you not dependent on a perhaps-finicky plug-in for backup, you can also get at your backups even if your WordPress site goes down, or is otherwise acting up and you can’t log in to the WordPress admin panel for some reason to restore the site using a backup plug-in.
With the off-site approach, you can always get into your site and restore it remotely via FTP. Also, in the terror-inducing event your site is hacked, becoming infected and thereby completely untrustworthy, you can easily wipe the slate completely clean and, again, restore remotely from off-site. Problem solved.
Keep a recent fail-safe website backup on your own computer. Your WordPress website “lives” and is functional only on a server in the “cloud,” but that doesn’t mean you can’t store a backup of it locally. So another tip with off-site backups is to periodically download a full website backup to your own hard drive. That gives you even more protection should both your web host’s servers as well as your off-site backup service’s servers fail simultaneously. (Boy, paranoid, ain’t I? Yep.)
On all counts, off-site backups are more robust and foolproof than backups by plug-in. Of course, like an off-site security firm offering a WAF, it isn’t free, but robust off-site backup is relatively more affordable than robust off-site security. (Cost for site backup is covered in Part 4 along with other server-based task costs and plug-in costs.)
Site caching
WordPress sites require caching to load quickly. The third area where non-plug-in solutions are usually going to be better is website caching. And make no mistake, if you have a self-hosted WordPress site, you need caching. There is no other way to say it: without taking special measures, the average WordPress site is slow without caching, due to the database queries otherwise required to dynamically build pages from various components and serve them on the fly. And Google downgrades slow-loading sites these days in its search rankings, which provides another incentive.
I originally tried a caching plug-in myself, but immediately ran into issues with its JavaScript and CSS minification routine clobbering the functioning of the Graceful Pull-Quotes plug-in I use. While it’s very possible that issue may have since been fixed, there turned out to be two other non-plug-in-based caching solutions I was able to make use of instead, and have elected to stick with.
Built-in, no-extra-cost server caching with SiteGround web hosting. Since I have moved my website to SiteGround in more recent months, I have been employing their “SuperCacher” solution which operates at the server level. It includes a three-level cache, with one level for static pages like basic HTML, a second level for dynamically generated pages such as WordPress, Joomla, and Drupal, plus a third level (Memcached) that caches page components in RAM for even faster response.
Content delivery networks (CDNs) as another potential boost. Above, I mentioned Sucuri’s firewall security product, CloudProxy, that I utilize for my website here. What is not as well known or advertised is that within the last few years, Sucuri has also built out their own content delivery network (CDN) in tandem with CloudProxy to serve cached versions of your website’s pages. While Sucuri’s specialty is security and their CDN may not be optimized to the same level as those of CDN networks/vendors for whom that offering is their specialty, it is still a noticeable boost.
Although it is certainly possible and doesn’t hurt to employ both SuperCacher and a CDN simultaneously, currently I have turned off Sucuri’s CDN for my site, because SuperCacher automatically purges the cache when site changes are made (needed when testing or reviewing site design changes), whereas purging the Sucuri CDN cache must be done manually. Since it’s not clear to me how much extra speed benefit Sucuri’s CDN might add to that already provided by SiteGround’s SuperCacher (probably not a whole lot extra), it is easier for my purposes to just use the latter by itself.
Save money with server-based caching, and avoid potential plug-in conflicts. In SiteGround’s case, at least, their server-level caching costs nothing extra and is part of all subscription packages they offer. Also, any server-level caching solution is likely going to perform faster and without the kind of conflicts that plug-ins can cause. So if you can get server-level caching for minimal or no cost, I would say choose that in preference to a caching plug-in.
As a general reminder here, it usually pays off to go ahead and pay a little more for web hosting, because you often find there are “extras” like this bundled into your subscription that save you money in the long run on plug-ins or other services you might otherwise have to buy separately.
Troubleshooting
From plug-in snarls to web-hosting snafus
My main piece of advice here is: get used to it, at least from time to time. By the time you’ve installed a number of plug-ins, your WordPress site will have enough moving parts and potential for conflicts among them that glitches and malfunctions will periodically crop up. Plug-in updates may solve some issues but cause others.
And, plug-ins completely aside, things your web host does behind the scenes, such as introducing or modifying firewall rules, or migrating accounts to new hardware, may introduce issues or suddenly cause things to fail as well. DDoS attacks or onslaughts of spam on the host’s servers may necessitate firefighting measures by the hosting service that gum up the functioning of things that formerly ran hassle-free without incident. Incoming or outgoing email might temporarily stop going through for one reason or another. Almost anything might happen, on occasion.
Following are a just a couple of examples from my experience.
Example #1: Adblock browser extension interfering with image slider display
On occasion, things completely beyond your or your web host’s control may impact the functioning of your site. For instance, one day I began noticing that my photo sliders on the Work > Proofreading page were not working properly — photos were getting cropped (chopped off) improperly — but only when the website was viewed in Safari. In Firefox and Google Chrome the sliders still functioned fine. What the heck?
Eventually I narrowed it down to the Adblock Plus browser extension I had installed. Somehow Adblock was interfering with the photo sliders, apparently erroneously thinking they must be ads. However, I had installed Adblock on both Safari and Firefox, yet only Safari had problems displaying the sliders. (Chrome I like to keep stripped down to the bone with no add-ons as a “clean slate” for testing purposes.)
The issue was quite disconcerting because a huge block of people (40% of all internet users at this time, I believe) run ad blockers, and now I had discovered the most popular one on the market was screwing up the functioning of the sliders I was using to display two of my business’s portfolio collections, on my completely ad-free site.
Fortunately Safari has a smaller market share than the other two browsers, but still… The setup of the sliders was something I had labored long and hard on, both design and functionality-wise, to look as professional as possible in hopes of snagging business from potential clients. Now a needless conflict caused by Adblock was making me look like an amateur, and worse, someone who couldn’t even properly proofread the appearance and functioning of his own “Proofreading for Ad Agencies” page. Maddening — arghghgh!
One afternoon I was finally able to spare some extra time to look further into the issue for a fix. I began trawling through the support forum on the slider developer’s site, and ran across a thread addressing a very similar Adblock issue on another user’s site. While it didn’t contain the exact fix I needed, it did provide enough of a hint that I was eventually able to put together a similar fix of my own (with a few bits of well-targeted CSS code) to override how Adblock was dynamically altering the CSS pertaining to my photo sliders. Sigh of relief — often fixes are not nearly that easy or quick, but in this case I managed to skate out of the problem without much pain.
Example #2: Finicky, error-prone BackupBuddy glitches
Another day, BackupBuddy began timing out and would not complete my weekly full backups. Occasionally a backup would complete, but for the most part, from then on most full backups failed to complete. The error message was cryptic, mentioning only that the WordPress database was becoming clogged with too much clutter or with logs that had grown too large or something to that effect.
I couldn’t figure the problem out, and it wasn’t until I got fed up and began considering whether I should simply abandon BackupBuddy that I decided to look into off-site backup services. I consistently heard good things about one of them — iControlWP’s WorpDrive — and decided to try it out. I mentioned the issue to their tech support department and they were able to pinpoint the problem, which was causing even their FTP-based backup a large amount of extra time and server resources to plow through, even though it didn’t cause things to fail for them. The problem came down to just a single file in the database that had grown very large.
The file turned out to be an automatically generated series of “snapshots” that my theme framework (Headway) had generated over the last year or year and a half, tacking on a new snapshot each time I saved another iteration of either the site design or the main CSS style-sheet file. There were many hundreds if not a few thousand of these snapshots (I don’t recall exactly) that had piled up and bogged things down without my knowledge.
The solution was simple: pare down the snapshots file. However, I discovered that at this juncture it was an all-or-none proposition. Headway had (and still has) no provision for easily deleting “all but the last X number” of snapshots. You can either delete all of them in one fell swoop with the click of single button, or else you can delete each of them manually, one by one, but nothing in between.
Obviously, the only choice I really had with so many snapshots having accumulated was to delete all of them. But the whole purpose of the snapshots is to have a series of recent instances to be able to revert the site design to, if need be, during the development process. But now they were all going to be deleted. So I ended up simply waiting a few days until the off-site backup service had made a few successful full backups, in case I needed to fall back on one of them in lieu of any Headway snapshots to rely on.
From then on, I have made sure to go in and delete a few handfuls of Headway snapshots manually from time to time. There really should be a way to keep snapshot files like this pared down automatically once they exceed a certain threshold. But this just goes to show the types of stupid issues that can unexpectedly reach up and grab you by the ankles.
