WordPress is a free open source content management system. Reich Web Consulting specializes in building custom WordPress websites, themes, and and plugins.

Be a Web Developer Not a Plugin Installer Masthead

Be a Web Developer. Not a Plugin Installer

WordPress is my CMS of choice based on it’s simplicity, extensibility and the variety of plugins and extensions. Given it’ popularity, I’m not the only one.

But I’ve been stepping out on my lady. I’m working on a project in which the client chose the platform before I joined the team because it provided key features and it’s stock theme roughly matched their mock-ups. The choice to use third-party code led to missed deadlines, scope creep, and scrapping features because the platform isn’t easily extended. (For the record, WordPress would have been a terrible choice too.)

We’ll never know if it was the right decision, because the project will launch duct-taped together. This project wasn’t built on WordPress. So why am I talking about it? If we abstract away the technology there is an important lesson to be learned about what it means to be a web developer.

Hold Yourself Accountable

Developers are responsible for the code they sell to clients, not just the code they write. Our clients trust us to make good decisions on their behalf, and we often take that trust for granted.

We shouldn’t expect a client to understand the difference between our code and third-party code. If we choose to use plugins to build a solution we take credit when that choice results in success. Yet when the extensions we install (plugins and themes) lead to failures like hacks or broken updates, we’re perfectly willing to absolve ourselves of responsibility. It’s not our fault! It’s the plugin!

Who made the decision to install that plugin? Are you a web developer? Or are you just a Plugin Installer?

Be a Web Developer. Not a Plugin Installer

Choosing to install a theme or a plugin should not be a careless act. Perhaps we’ve stopped thinking about it because WordPress has made installing them so easy. Many developers approach plugins with a cavalier attitude and don’t consider the consequences of blindly installing third-party code that could do just about anything intentionally, accidentally, or through a hacker’s exploitation.

Plugins: WordPress’ Double-Edged Sword

Plug-ins made WordPress successful. So how can we leverage the massive library of free and paid extensions while minimizing our exposure to the problems they can produce? Here are a few questions to ask yourself to avoid installing bad plugins.

1. Did you pirate the plugin?

If you pirate a WordPress plugin, shame on you. People who make things for a living shouldn’t be comfortable stealing other people’s creative works. It’s really that simple. Besides: installing plugins from pirated sources is a recipe for disaster.  Pirated plugins often come with exploit code baked right into them. Their backdoor isn’t technical: it’s exploiting your cheapskate nature. Just. Don’t.

2. Does the plugin come from a trustworthy source?

There are a ton of sources for WordPress plugins on the Internet. The official WordPress Directory for example. It should go without saying that you shouldn’t install plugins and themes from disreputable sources. Don’t shy away from premium plugins from foundries like WooThemes and developers that sell their work via CodeCanyon, but research them before you install them.

  • Consider plugin and theme ratings.
  • Read user reviews
  • Check the plugin’s update history to make sure the developer is dedicated to maintaining it
  • Look for third-party information on whether or not the plugin has been hacked in the past

3. Do You Really Need a Plugin?

We’re web developers, right?

So why do we feel like we need to introduce other people’s  code into our sites just to add social sharing buttons, insert a tracking code, or add an image slider? If you can’t do these things for yourself, you’re not a developer. You’re a plugin installer.

Plugins make some tasks so easy we take them for granted.   But it’s important to remember that every time you install a plugin you introduce another potential vector of attack and another thing  that needs maintained forever.

Sliders are a great example.  Everybody wants a slider (though their value is dubious). Most of us simply install one of the many popular slider plugins and get on with our day. But slider plugins have been particularly vulnerable to attack. The incredibly popular Slider Revolution plug-in has been a very popular hacking target in the past.

So ask your self: do you need that slider?  Does the client really need to maintain it from the WordPress Dashboard? If not, it’s a prime candidate for skipping a plugin, and writing a few lines of JavaScript that won’t get your site hacked.


These lessons aren’t specific to plug-ins. They’re not specific to WordPress. Heck, I’m not even sure they’re specific to web development. As professional problem solvers we need remain conscious of the individual parts we use to build our solutions. Don’t Repeat Yourself, and Don’t Reinvent the Wheel. These philosophies remain true.  But don’t be afraid to build better mousetraps, particularly when the current design has a history of failure.

How to Create a WordPress Theme Thumbnail Image

How to Create a WordPress Theme Thumbnail Image

When you’re building a new WordPress theme, it’s always helpful to create a custom theme thumbnail image (or theme screenshot, if you prefer).  A theme’s thumbnail image is used to display a tiny screenshot of the theme in the WordPress Dashboard so a user can see what the theme looks like before they activate it.

How to Create a WordPress Theme Thumbnail Image

Creating the thumbnail is easy: create a PNG image that’s 880 pixels wide x 660 pixels tall that shows a screenshot of your theme in action. Save that image as screenshot.png in your theme’s directory, and it will show up in the WordPress Dashboard.

I’ve taken the guesswork out of the process by providing a template you can start from. Just open the PSD or PNG image provided and paste in  your screen shot.  Resize and position the screenshot within the template, and save as screenshot.png.

[button link=”https://www.reich-consulting.net/wp-content/uploads/2015/11/wordpress_theme_thumbnail_template.zip” color=”blue” align=”center” target=”_self” size=”large”]Download WordPress Theme Thumbnail Template[/button]

WordPress Limits The Number of Items on a Menu

I just ran into a problem on a client site: I went to add two new items to their primary navigation. The first was was successful.  And even though clicking save said it was successful, when the Menu tool refreshed and I refreshed the live page, the second item was missing.

WordPress doesn’t actually set a limit on the number of menu items you can have. It seems like it does though, since an never never actually occurs when it stops adding them.

Some Googling turned up this issue in the WordPress Bug Tracker. Apparently when you click Save WordPress returns every menu item as a separate request variable.  When you get to 89 menu items, the number of variables being sent passes the default limit set by PHP, and menu items 90 and beyond get ignored. While the fix suggested by the bugtracker didn’t help me, the solution was easy. I just added the following line to my site’s .htaccess:

php_value max_input_vars 2000

Adding that PHP configuration variable will override the default max_input_vars limit, which causes WordPress not to receive and therefore save menu items beyond 89.

.htaccess rewrite rules that impacted the search feature on my WordPress site.

IThemes Security Plugin and Dangerous Search Queries

I’m a huge fan of iThemes Security (formerly Better WP Security).  I’m such a fan, in fact, that I use it on many of my own sites as well as the WordPress sites that I manage for my current employer.  But anyone that’s used iThemes Security knows that sometimes it’s does a little too good a job and you eventually run into false positives and unintended consequences.

Today I ran into such a situation.  I manage 4 separate WordPress sites for distributor of industrial plumbing and HVAC components.  A client who was looking for a very specific part let them know that their site was crashing when he entered it into the search bar.

That part they needed was an insert.

What do we know about the word “insert” that might explain why only that search term was causing a problem?

We know that WordPress uses a MySQL database, and we know that an insert is a type of SQL query that writes to the database.

Could it be that iThemes is being helpful, and blocking requests to the site that look like they might be trying to write to our database?

The fact that I was seeing an Apache generated error page and WordPress wasn’t even trying to handle the request suggested that the problem happened before the request was ever passed off to the CMS. So I opened the .htaccess file for one of their sites, searched for the word insert, and found the offending lines.

Update: I’ve moved the code over to GitHub.

Basically these rules cause Apache to drop requests with suspicious data in the query string. If you look closely, one of those rules includes words like request, contact, union, declare, and insert. Deleting the offending line from the .htaccess solved the problem.  I like the added protection these rules provide, so I only recommend removing them if they cause a problem.  These rules try to prevent hackers from sending malicious code to your website in the first place, so if some code in your WordPress install forgets to sanitize user data, you’re still somewhat protected.

I had to remove this rule because insert is actually the name of a product the client was selling through their site and blocking this search term could affect sales.  Before you remove these rules, weigh the pros and cons of your own situation.

On the Recent WordPress Security Updates

In the last two months we’ve seen a number of WordPress security updates.  April 21 brought us WordPress 4.1.2 which fixed 4 security issues. A wide-spread vulnerability in numerous WordPress plugins was simultaneously announced and was followed by a rash of plug-in updates by vendors including Yoast. A week later WordPress 4.2.1  was released with a patch to a cross-site scripting vulnerability found in the comments feature. Then just a few days ago WordPress 4.2.2 patched a vulnerability in the bundled Genericons font package.  The WordPress naysayers have been saying nay for weeks now. Is their negativity justified?
The WordProcalypse ended not with a bang, but with a “meh.” WordPress updates itself automatically now. And if you’re in the practice of only installing reputable plug-ins and themes, updating your plug-ins is pretty painless.
Consider this: all of the vulnerabilities fixed by these updates were detected either by the core WordPress team or community members who develop extensions.  None of them were the results of a zero-day exploit.
I think the recent rash of WordPress Core and plug-in security updates is a Good Thing.  It’s proof-in-the-pudding that the WordPress community has matured. It’s a sign that everyone involved in WordPress’s success from parent company Automaticc to lone plug-in authors are taking it seriously.