Ward Nicholson

Think Outside The Box masthead

Monthly Archives: June 2016

WordPress’s hidden hazards for do-it-yourselfers, Part 4

Okay, troops. The final installment in the series here requires only that you slog through another 4,000 words from the master of verbosity, so buck up. Considering you’ve plowed through almost 12,000 words already (at least if you didn’t skip anything, you dirty rats), this is gonna be a cakewalk.
Go to: Part 1 | Part 2 | Part 3 | Part 4

Examples of plug-ins to remedy core WordPress deficiencies

Below are some plug-ins I’ve been pushed into using simply because something silly is either missing from core WordPress functionality, or is seriously deficient. Things that you would think would be — and should be — built in as standard, but where the developers are just being obstinate or clueless (pardon my presumptuousness). When it comes to the needs of the average user, code geeks truly are a different species often living with their heads up… er, in the clouds ;-).

  • 404page. Wouldn’t you think that the typically clunky, stock 404 (“Page Not Found”) error page would be easily user-modifiable to your own liking? I, for one, thought that. I’ll bet you think that too. Silly you and silly me for thinking something so obvious should be so easy. It ain’t. I kid you not, the WordPress developers apparently think you are just going to jump up and down with glee knowing you’ll need to larn yerself some of that thar PHP coding and go in like a surgeon to modify or code your own 404.php page to get the job done. And that you’re a chump if you can’t or won’t — so there.
  • The 404page plug-in makes it as easy as falling off a log. Just like it should be in the first place. Create your own 404 page the way you would any other WordPress page, use this plug-in to point to it so it’s substituted for the default version of the page, and you’re done. Slam dunk.
  • Broken Link Checker. If like me, you’ve ever used an application like Dreamweaver to create websites, you probably think broken-link checking is an obvious, standard feature that would be available with any capable web publishing software. Wrong-o. Sorry, the core WordPress developers don’t think like you and me.
  • Evidently you’re supposed to be so accurate that you never cut and paste a link erroneously, and links never go bad. Or maybe they think you enjoy blowing an entire weekend from time to time doing nothing but clicking on the links throughout your site to see if they still work or not. Because, well, because gosh, it’s just so cool that you can, like, click on a link on a web page and it might take you to potentially anywhere else in the cyberverse. I mean, wow, just WOW, think of the possibilities!

read more ▸

WordPress’s hidden hazards for do-it-yourselfers, Part 3

What? Didn’t get enough punishment from the first two parts in the series? Good. Let’s continue on, fellow masochists.
Go to: Part 1 | Part 2 | Part 3 | Part 4

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.

read more ▸

WordPress’s hidden hazards for do-it-yourselfers, Part 2

Continuing with round two of the complain-a-thon and avoiding-the-pitfalls advice for WordPress do-it-yourselfers.
Go to: Part 1 | Part 2 | Part 3 | Part 4

The WordPress theme landscape: an unorganized polyglot of a mess

N
ow, what about the design of your site? Another initial hurdle to clear when you’re first beginning on the road to a self-hosted WordPress site is what it’s going to look like. It’s basically a three-fold choice:

  • Use one of the stock WordPress themes (Twenty Ten, Twenty Eleven, Twenty Twelve, etc.).
  • Go with either a free or premium theme from a third-party developer (i.e., Themeforest, Elegant Themes, or any one of a boatload of other developers).
  • Roll your own.

The stock WordPress themes: ah, ugh. I think the first observation to be made about themes for self-hosted sites is that the stock themes offered by the WordPress core developers mostly suck. It’s not just that the themes are minimalist, because minimalism can be good, but that they are minimalist in a clunky way that just isn’t visually very pleasing.

Perhaps one shouldn’t complain too much about this since the core WordPress developers are primarily coders, but this is a recurrent issue you typically see with any kind of open-source software: the user interface and particularly the graphic design of things are often a serious weak spot. Coders’ brains are just wired differently than most people’s, and specifically they are wired differently than people like graphic designers who are strongly visually oriented.

But if that weren’t enough, coders for some reason almost seem to operate under the hubris of “we don’t need no stinkin’ visual design,” which of course is just the opposite of the truth. More than any other group, coders should be seeking help with the visual design of things, and yet they seem to be the last to acknowledge the need. Or if they do acknowledge it, are painfully slow to actually do something about it.

read more ▸

css.php