WordPress Top Tips

March 2013

Contents

Introduction

My latest endeavor involves hacking WordPress, 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 Developing with WordPress Forum. (where I go by bcworkz) I've also improved and added content to the Codex, 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 wordpress.com and the other is wordpress.org. 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 organization) maintains control of its 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.
to Contents

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 fact, XAMPP 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. All major browsers have one by default. Another useful browser tool is Networking, which captures HTTP requests and responses for later analysis. Very useful for finding out why a site is slow. Be sure to bookmark all the code references for WordPress ( Codex and Code Reference) and its related languages; PHP, JavaScript, jQuery, and mySQL 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. Major browsers have mobile device emulators which can be used to help build responsive sites, but you should verify your site looks right on an actual mobile device to the extent possible.
to Contents

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 poorer performance.

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 requirements 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 deciding factor.

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 Dreamhost. Definitely worth consideration if you are in the market for a hosting service.
to Contents

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 child theme 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 plugins. There are some customizations and hacks that are best done from a plugin. Plugins keep you from being tied to a paarticular theme. When your customizations are contained in a plugin, you are free to change themes as often as you like. 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.
to Contents

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. Quite a few hosts drastically limit user management options for databases. You may be forced to use the user assigned to you.

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' might be 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 wordpress.org repository, because these modules 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!

to Contents

Epilogue

That's enough for now. Check back in once in a while for more WordPress tips and tricks. They will cover the gamut from quick and easy general purpose to involved and detailed specific. We'll be getting pretty specific next time, how to use AJAX techniques in WordPress. Other topics that I have cooking are about blocking comment spam, internationalizing your site, hacking administration panel tables, easy and effective security measures, setting up a local development environment, a detailed explanation of the default .htaccess entry, the PHP $_SERVER array, and more. You will want to check in once in a while.

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 JavaScript needs to be enabled. . 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.
to Contents

«Back