Comments on: How to Remove the WordPress Version Number (The Right Way)

By: Jeff Starr

Jeff Starr — Mon, 27 Jul 2009 17:42:00 +0000

I don’t think there’s any one thing that is going to keep your public site totally secure. It’s more like a culmination of various layers of protection. Hiding the version number is merely one of those (hopefully) many layers.

By: Jose

Jose — Mon, 27 Jul 2009 11:49:02 +0000

When it comes to security, isn’t keeping wp up to date better than hidding the version number?

Nice and clean fix as always though.

By: iceflatline

iceflatline — Fri, 24 Jul 2009 00:20:15 +0000

Jeff,

Update. After giving this some more thought I think your approach is indeed more effective. As you suggest, it does make upgrades easier ;-)

Thanks for the terrific article.

By: iceflatline

iceflatline — Wed, 22 Jul 2009 21:18:55 +0000

Jeff, thank you. I simply make a backups of the files I have made edits to in /wp-includes. So when I upgrade, which I typically do manually, I can reapply the necessary changes where necessary. Not the most elegant I’ll admit…

By: Lalor McMahon

Lalor McMahon — Wed, 22 Jul 2009 06:41:35 +0000

Thanks Jeff – just what I was after!

By: Davezilla

Davezilla — Wed, 22 Jul 2009 02:21:27 +0000

Sp@mmers and Script Kiddies frequently target blogs and look for version numbers to determine which insidious script to run. Some don’t bother with version numbers, but if a sp@mmer or SK knows of a security exploit on a certain version number, then they will have their tool spider for blogs with a certain version number to hit.

By: Jeff Starr

Jeff Starr — Tue, 21 Jul 2009 00:49:21 +0000

Insightful as always, Vladimir. I will be checking into these files and examining their default availability and accessibility. Hopefully preventing access is possible, as I am not seeing any way of renaming these files via functions.php. There are many scans for WordPress generator version, but I have never seen any for these specific files, not that it isn’t happening, but probably to a much lesser extent. Still a bit disconcerting though. Thanks for the heads up.

By: Jeff Starr

Jeff Starr — Tue, 21 Jul 2009 00:43:48 +0000

The main argument against hacking the WP core is of course that it complicates the upgrade process. For production sites, I might agree with this, but for learning and development purposes, there is no better way to learn WordPress than to “dig in” and start hacking around in the core. I owe most of what I know about WordPress to breaking (and fixing) things in the core. So the question goes back to you: how do you go about upgrading? Do you have multiple sites?

By: Vladimir

Vladimir — Mon, 20 Jul 2009 21:01:19 +0000

Jeff,

I must say there are many ways to find out the version of WordPress you are using.

Just view the source of your login page and you will see the things like:

.../wp-admin/css/login.css?ver=20090514
.../wp-admin/css/colors-fresh.css?ver=20090625

By examining the versions of the CSS files, TinyMCE and other JavaScripts it is possible to find out what version of WordPress is actually used.

An example: you have “/wp-includes/js/autosave.dev.js” in your server. Dev-versions (not minified) of JS appears as of WP 2.8.

Version of 20090625 of colors*.css is likely to indicate WP 2.8.1 (although I am too lazy to check which numbers WP 2.8 used).

By: iceflatline

iceflatline — Mon, 20 Jul 2009 20:13:09 +0000

Jeff,

Personal preference I guess. It made sense to me to stamp out the function where it was being triggered. The other wp-head hooks are there as well. I’d welcome your thoughts on the pros and cons of each approach though.