My latest endeavor involves hacking
the popular blogging platform. No, not black hat hacking
WordPress sites to inject link spam for counterfeit Louis Vuitton handbags. I mean white hat hacking
to customize it's function and appearance to meet specific needs of site owners. I'm active on the
WordPress Hacking Sub-Forum.
(where I go by
I've also improved and added content to the
the WordPress documentation
resource. For various reasons, some of what I'd like to share is not appropriate for the Codex, so I'm
sharing it here.
The first thing I want to share is my Top Tips for someone just starting out with WordPress who thinks they
will likely do some hacking themselves. Some of this I learned the hard way, with much wasted time. No need
for you to repeat the process. Except for tips "Sandbox" and
"Child", this article would be useful even if you don't
plan on hacking Wordpress.
There's Two Kinds of WordPress
Many people are surprised to learn that there are two very different versions of WordPress.
The versions are distinguished by their top level domain name. One is
and the other is
The fundamental difference is with the .com version, your content is stored
on servers provided by wordpress.com. With the .org version, WordPress (the application) and your
content are stored on a server you provide. Because WordPress (the company) maintains control of
it's servers, the appearance of your .com blog is mostly limited by the available templates and
WordPress (the application) only functions one way. Because you have control of your server, the
appearance and function of your .org blog is virtually unlimited.
This extensible nature means there are plugins available to make WordPress into various other
types of Content Management Systems (CMS) such as forums, wikis, and e-commerce. This is a testament
to Wordpress' extensibility, but you would be well served to remember this is a blogging platform,
not CMS. Trying to make it into something it's not is misguided in my opinion. This series of articles
focuses strictly on the wordpress.org self hosted version and it's ability to be modified in seemingly
endless ways, but for me, always as a blogging platform.
Build a Sandbox
The first thing you will want to do is build a sandbox so you can play and hack with WordPress without
risk of crashing your live production site. This will be your development environment. You do not want
to move your custom code to your production server until it has been thoroughly debugged and tested.
Of course, you can simply build your sandbox in a non-public folder of your hosted server. But you will
be much better off building your sandbox on your local computer.
A local WordPress development environment has several significant advantages. Development inevitably
means hundreds of iterations of editing a file, saving it to the server, testing the code, then back
to editing. WordPress has built in theme and plugin editing features which make this easy... until
you make a mistake and crash the site. Now your editor is inaccessible and there is no incremental
back up to revert to to undo your mistake. Face it, everyone makes mistakes when coding. So to be safe,
you edit your files locally and FTP everything to the server. Now you've added one more thing to do in
the edit cycle. Not a big thing, but multiply it hundreds of times and it's not so little.
How much easier would it be for everything to be local. The edit - test cycle then consists of two
clicks— save and reload. And you can use your favorite syntax highlighting editor, which probably
makes incremental backups automatically. It may not sound like much, but if you've done it both
ways, you will never go back to remote development at any cost. Local Rules!
All you need to get a local development environment is the free WordPress download and a Web Server.
While installing a web server on your local computer sounds ominous and dangerous, it's not. In
makes it super easy and safe. And there's a version for almost any operating system
you're likely to use, including Linux and Solaris. I'll have more detail on this in the future,
but for now check out
Install WordPress Locally on Windows with Xampp.
While it's specific for Windows, the only difference with other platforms is the specifics of
installing XAMPP. The remainder should still apply.
Every sandbox needs tools right? This one is no different. You obviously have a browser. You probably
have a syntax highlighting editor. If not, get one. It'll help keep you from making stupid mistakes
like forgetting to close a set of parenthesis. It also makes structuring your code with tab indents easy.
Just be sure it saves files in UTF-8 format WITHOUT a byte order mark (BOM). The BOM is a UTF-8 file
convention that is incompatible with WordPress. Unfortunately, it's use or lack of such is not
always explicitly stated. Sometimes all you can do is save a UTF-8 (not the same as "Unicode" format)
file and examine it in a hex editor. The BOM will be the first 3 bytes of a file and is always
0xEF,0xBB,0xBF for UTF-8 files. As plain text, it appears as ï»¿. It does not appear at all in
UTF-8 text display, it only resides as data in the file. If your editor inserts this and there's no
way to turn it off, you'll need a
different editor. Another important editor feature is the ability to either identify or remove
trailing spaces at the end of lines. PHP can behave strangely when such extra spaces get inserted.
Another essential tool is a CSS explorer tool for your browser.
Many browsers have one by default. For Firefox, install the
plugin. Another useful tool
for Firefox is the
plugin, which captures HTTP requests and responses for later analysis.
Be sure to bookmark all the code references for WordPress (
and it's related languages,
for easy access. And as for any web development work, a wide array of web access devices and all
the browsers available for each is useful for ensuring your work displays correctly in any device.
Find Quality Hosting
The most affordable hosting is shared hosting, where hundreds, or even thousands of websites share
a single server and a small block of IP addresses. Unfortunately, dedicated hosting is expensive,
so you will likely need to use shared hosting for financial reasons. The WordPress core code base
is HUGE! For reasonable page load times, you need good server performance. When sharing the server
with thousands of others, extremely fast server performance is paramount. So to some extent, you get
what you pay for. The cheapest hosting probably has many more sites on each server, with correspondingly
Shared hosting is an inherently risky environment. Once a bad actor has hacked into one site,
hacking other sites on the same server can be trivial. You want a host that takes security seriously
and has no issue with denying service to nefarious operators. Your site's reputation is partly
determined by the company you keep. You don't want to be on a server that serves a pile of porn
and shits link spam all over other sites. You also want a host with good customer service that reacts
quickly to security issues.
If you don't have a domain name yet, registering your domain with your host has some minor advantages
when setting things up, but after that, there is no advantage at all except the billing is all from the
same place, but you'll probably be billed separately for each anyway. Even though cheaper, avoid
initially signing up for long commitments. Choose a shorter commitment and see how things go before
committing for longer. It's hard to choose a good host. Ask everyone you know about their experiences.
Ask on forums you frequent, even if off topic. Most forums have an off topic area. The one thing you'll
want to look for to host WordPress is a Linux based server. WordPress will run on other servers, but it's
designed for Linux. Why tempt fate? Apache is the most common Linux server software, so there is some
advantage to having the same when seeking support online. It is also what is supplied with XAMPP in the
sandbox section. But any Linux server will do.
Also check the minimum WordPress
for PHP and mySQL versions. If the host cannot provide
these, they are way out of date and you should look elsewhere. Some hosts offer one-click WordPress
installation. While this is handy and should obviate any confusion in setting up the database connection,
manually installing WordPress is usually ridiculously easy. Don't let one-click installation be a
Another important feature needed from a host is the ability to use .htaccess files to manage rewrites. While
not an absolute requirement, without rewrites, permalinks will not work. A permalink looks like
yourdomain.com/2013/interesting-blog-title/ , without .htaccess rewrites, all your links can only
look like yourdomain.com/index.php?p=215 . In addition, .htaccess files allow you to implement
many useful custom security measures. Your ability to manage your site is severely hamstrung without
.htaccess files. .htaccess file use is fairly commonplace, but there is the occasional host that does not
allow it. Apparently Yahoo Small Business Hosting is one such host at this time (March 2013).
I have no personal experience with this particular hosting service, but several people I know that
really know about these things all have high praise for
Definitely worth consideration if
you are in the market for a hosting service.
Every Hacker Needs a Child Theme
(and a plugin)
The WordPress core and most themes and plugins are updated on a somewhat regular basis. The process
in part involves overwriting files. If you happened to modify one of those files, your modifications
would be lost. So when hacking WordPress, it is essential to do so in a way that your hacks are
protected from loss during updates. One way to do this is create a
to whatever theme
you end up using. No child theme code is ever overwritten during your main theme's update.
The other vehicle for modifying WordPress functionality is
There are some customizations
and hacks that need to be done from a plugin. The way child themes are loaded prevent them from
doing certain things. So you will at some point end up creating a plugin to implement some
functionality. Your custom plugin is also protected from being overwritten by other plugin
updates or core updates.
Because of the danger of loss due to updates, all responsible WordPress developers consider
it extremely bad form to directly edit core files. All changes should be done from child themes
or plugins. Except for the few things that require a plugin, most hacks will work equally well
from a child theme or plugin, so where your code resides is completely up to you. Much as good web
developers segregate content and appearance so that all appearance is managed by CSS and all
content is in HTML, I prefer all appearance hacks to be part of my child theme and all functionality
hacks that do not affect appearance to be part of my private plugin.
WordPress Makes You a Target
WordPress' tremendous popularity makes it a target for spammers and hackers. Don't
let this discourage you. The WordPress core is extremely secure. All recent WordPress hacks
have been from flawed or dangerous themes and plugins. As long as you use strong passwords and
good security hygiene, and you are thoughtful about which themes and plugins you install, there
is really nothing to worry about. If you're still worried, there are even more measures you
can take to put your mind at ease. I'll get into some of these in the future, but for now,
here's a few quick and easy things to do.
One the most important things you do in preparation for installing WordPress is setting up
a mySQL database for it's use. All of this is usually done in the myPhpAdmin database
control panel, though your host may provide a similar interface called something else. You
may not be able to do any of these measures, depending on your host. The first thing to do
is add yourself personally as an admin user (you are likely currently 'root'), with all privileges
and grant powers. Then add a wordpress user (name it something else besides 'wordpress'
even though the Codex suggests 'wordpress').
Only give it
privileges that it needs to manipulate tables. It does not need any other user privileges.
When in doubt, don't grant it, you can always add it later. Be sure both yourself and the
wordpress user have very strong passwords. Log out as root and back in as yourself. Delete all
accounts except for yourself, the wordpress user, pma, and "any". This includes deleting root. Now
no one but you will know any useful user names.
You will then create the actaul database for WordPress to use. The one important thing to do
related to this is set it up as an utf8 character set database.
The utf8 character set is compatible with all languages. Neglecting to specify utf8 and needing
to change it when there is already a bunch of data is a huge nightmare. This has nothing to do with
security, but this seems like the right time to bring it up anyway.
When you install WordPress, you will want to do something similar with WordPress users. When you
are prompted for an initial Administrator user name, 'admin' is suggested. Do not use 'admin', select
something else, along with a very strong password. Once installation is complete login and go to
the Users admin panel. Add yourself again with a different username as an Author. Use a good
strong password, and a different password than used for the Administrator account. Now, once again,
no one but you knows any of the user names. Not accepting the default 'admin' user name is an important security
measure. Every brute force hack attempt I've ever seen tried to login as the user 'admin'.
For common blog posting, use your Author user. If this password should get stolen, the damage that can
be done is very limited. There will be a future article on adding privileges (capabilities in WordPress
parlance) to the Author user so you almost never need to use the all powerful administrator account. No
one can steal Administrator credentials if they are not used.
As much as possible, only use themes and plugins found in the
because these features from other sources have often been the cause of security breaches. Themes and plugins
in the repository at least have been through a vetting process. If you can avoid having the type of
site in which the general public can upload files to your server, you will be much better off security
wise. Be sure to update the WordPress core, as well as your installed themes and any installed plugins
(activated or not) as soon as you find out one is available. Look for settings that notify you by email
when updates are available. Alternately, subscribe to your plugin author's feed so you get the
latest news about your plugins. Updates are frequently released to patch newly discovered security flaws.
You want to update before black hat hackers figure out how to exploit the now public security hole.
Otherwise, just use good security hygiene. Keep your local computer free of malware. Do not access
your WordPress site from insecure networks like coffee houses, libraries, or hotel Wi-Fi connections.
Consider the posting by email option when that's all that's available. If you must access
insecurely, change your password every time you logout until you can change it again from a secure
network. This would mean keeping your password secure in some sort of password manager on your device.
Or possibly a different device such as your phone, assuming you are using a laptop. If you must
physically write it down, don't write it directly, write a reminder of how to enter it, or at
least write each key to the right or left of the actual key or some other sort of offset cypher. Or
write a phrase where the third character of each word is the password, except all 'A's are
actually '4's. Or... you get the picture. And keep it in a safe place!
Update. 27 Apr 13 - I've been informed the user name assignment in recent WordPress
versions is different than I had described.
I've since revised my recommendations accordingly. My apologies if this caused anyone any confusion.
Post Script. Curious seasoned WordPress hackers will be able to figure out that
my posts about hacking WordPress are not posted using WordPress. Why? No particular reason. Because
I can. I've been hand coding static web sites for years. I don't find using WordPress a big
advantage. I've learned about WordPress because other people want to be able to manage their own
content on their sites without having to hire a coder for every change. That works for me. Preparing
regular content besides my own is boring tedium. I'm not that keen on generating my content with
WordPress because it presumes I want my HTML a certain way. I hate things that presume to know what
I want. That's why I hand code my own content.
You can see I have not implemented a comment system. I probably wouldn't have even if I did use WordPress,
as I don't wish to deal with comment spam. Even so, comments, feedback, and questions are always welcome.
You can email me at
. Granted, this is more cumbersome and less public than WordPress comments.
My email system has a good spam filter, so this is what works for me.
Disclaimer. While I do volunteer work for wordpress.org, I am otherwise in no way affiliated
with that organization. The information I have offered here either represent facts to the best of my
knowledge, or are opinions held solely by myself. The facts may not be 100% accurate and my opinions
do not represent the position of anyone else. You assume all risk if you chose to act on any information
or opinion provided here. I cannot control how you chose to interpret and apply this information, so I
can take no responsibility in your use of it.