I’ve just finished reading WordPress 3 Ultimate Security by Olly Connelly, which aims to help you make sure your WordPress installs are as protected as you can make them. Security is often one of the most intimidating pieces of running your own site, which is one of the major contributors to the popularity of shared hosting since many people are not comfortable managing their own server. Unfortunately though, shared hosting is often a false sense of security and can expose you further than a more segmented environment.

That doesn’t take away from the importance of being a responsible and reliable source of information for your clients. It’s very likely that your clients have no idea how their website works or how it’s even online, they just know who to call when something isn’t working properly. If you’re in charge of that environment, it would be a disservice to your client to cut corners or take a quick way out when it comes to their server setup. WordPress 3 Ultimate Security aims to help you harden your WordPress installs, resulting in a more stable, longer lasting website powered by WordPress.

Content summary

WordPress 3 Ultimate Security is quite a comprehensive guide. I wasn’t sure what to expect when reading the first chapter but it quickly became apparent that the content was going to sprawl the entirety of security as much as it were applicable. The chapter list is as follows:

1. So What’s the Risk?
2. Hack or Be Hacked
3. Securing the Local Box
4. Surf Safe
5. Login Lock-Down
6. 10 Must-Do WordPress Tasks
7. Galvanizing WordPress
8. Containing Content
9. Serving Up Security
10. Solidifying Unmanaged
11. Defense in Depth

Each chapter is further subdivided into a number of dense subsections covering a multitude of topics. The breadth of coverage impressed me from the start. Additionally, the tools and topics covered were modern, up-to-date, tried, and tested. I’ve read a number of security books and it’s rare to find one with comprehensive coverage of tools that will all be useful as you read through the chapters. Chapter 2 is especially interesting in this regard, as you’re guided through the process of analyzing and scanning a possible target as though you yourself were the hacker (or cracker in this case).

Chapter 3 provides extensive coverage on securing your local machine, which is a significant portion of every good security policy. Many times people forget that the biggest security vulnerability could have absolutely nothing to do with your server or the network it’s on, but instead your local computer. The one that insecurely stores you WordPress administrator login information.

WordPress-specific content doesn’t really ramp up until Chapter 5 of the book. SSL and security-oriented Apache modules are the focus of the chapter, leading up to Chapter 6 which outlines a number of smaller tasks that can help with WordPress security through obscurity.

The book moves into the server side of things in Chapter 9. The author gives advice on choosing the right host based on a number of criteria, outlines the pros and cons of popular control panel software solutions, explains how users and permissions work, all the way down to implementing a useful logging system.

The book gets even more detailed from there by discussing lower level server administration steps that can be taken in an effort to minimize the various ways a cracker may be able to obtain unauthorized access to your system. Through Chapter 11 I became increasingly impressed with the level of detail the author went to in discussing the vast number of responsibilities required when it comes to server administration tied into ways they can be exploited and ways you can thwart those attacks.

While I couldn’t consider this title to be the last one you should read on modern server security, I would highly suggest it as a starting point for things to look into as time goes on.

Overall reaction

After making it through the nearly 400 pages of content I was honestly impressed with the amount of content offered in the book. The author does a fantastic job of covering an extremely wide variety of angles which makes complete sense with such a diverse topic as security. If you were to follow the advice offered in the book you’d be left with not only a strong server environment, but a more secure local environment as well.

If you’re the person responsible for your client’s WordPress installs, or responsible for your own, taking a read through WordPress 3 Ultimate Security by Olly Connelly will very likely teach you a few things in a number of areas concerning your install. My take home message is an overall feeling of being impressed with the volume of content covered in under 400 pages. That said, the book may prove to be a bit overwhelming to some people who are less technical, but if that’s the case, unmanaged hosting might not be the place for you.

Advertise here with BSA

I long ago lost count of how many times I’ve visited php.net. It wasn’t the most beautiful thing in the world but you can teach yourself so much from that site alone.

I feel like I’ve seen this design before, long ago, but perhaps not. Either way, I’m really glad that something is in the works. With everything being so glamorous today, it’s important to keep up with the times.

I’m sure the existing php.net design is a big target for many anti-PHP zealots out there. Not that it should be a deterrent, but it’s nice to see this design in motion!

Advertise here with BSA

One of the things I’m going to focus on in 2012 is code quality, top to bottom. I want to sweat the details and learn more about writing better code.

To do that, you need to use tools. Surely you can understand concepts and design patterns from reading, but actually working with your code and seeing how changes effect the big picture is a bit of a different story.

I write PHP, and one of the things I want to dive into is performance. A good way to measure performance is a profiler. There are tons of fancy tools to help with that, but if you’re looking for something bolt-on and lightweight, this php-profiler project looks like a good thing to check out.

Advertise here with BSA

Many of you know that I haven’t had a Facebook account since it was limited to a college email address, but I can’t help to be intrigued on what they’re doing under the hood.

Some time ago, Facebook made waves with what they were doing with PHP, and they may have just done it again. Their latest creation, HHVM, HipHop Virtual Machine, boasts a 60% increase in performance.

There is a ton of detail in the posting, well worth a read!

Advertise here with BSA

Articles like these are great perspective. Many times we read articles about servers with 400GB RAM, seven petabytes of storage, and eleven quad-core processors, but I’m most interested in maximizing performance from just about anything.

Getting 9 million hits per day on a machine with 120 megs of RAM is impressive to me. A few more details include the box being virtual, running PHP with PHP-FPM, powered by an APC cache and last but absolutely not least: nginx.

There are many more details in the article, definitely worth checking out if you’re a server geek.

Advertise here with BSA

If you’re like me, leaning is often a very hands on process that involves comparisons with things you already know. While I’m not sure it’s the best way to learn a new programming language in and of itself, I do think it’s a nice way to learn a new syntax.

Not everything language to language is directly comparable, and I’d always opt to read a book in full when learning a new language, but seeing a reference chart like this can be terribly useful when looking things up quickly, or figuring out something new.

Advertise here with BSA

Enter Xdebug: the demise of print_r()

I first started messing with Xdebug years ago when I first heard it mentioned in passing while reading an article. I was more into front end and JavaScript at the time and wasn’t doing much professional programming. Interest pretty much fizzled at that point, although I thought it was neat at the time, I guess. I’m glad I stumbled upon Xdebug because as I was auditing potential IDEs to check out, I saw it mentioned on many feature lists as being the underlying built-in debugging component of various environments. A bit of research later and I knew Xdebug would likely be a big deal for my workflow.

Xdebug is best summarized as: (more on Wikipedia)

Xdebug is a PHP extension which provides debugging and profiling capabilities. It uses the DBGp debugging protocol.

The debug information that Xdebug can provide includes the following:

• Stack and function traces in error messages with:
  • Full parameter display for user defined functions
  • Function name, file name and line indications
  • Support for member functions
• Memory allocation
• Protection for infinite recursions

Xdebug also provides:

• Profiling information for PHP scripts
• Code coverage analysis
• Capabilities to debug your scripts interactively with a debugger front-end

After reading that, the only question I had for myself was why did I wait so long?

Installing and configuring Xdebug

There are some official docs on installing Xdebug, which is likely the most difficult part of working with it. Depending on your environment, you may have to recompile PHP in your development environment, else you can use PECL or a precompiled version. Lukcily, there seems to be precompiled versions of Xdebug for just about everything, so I’d suggest using that, graciously provided by ActiveState. It’ll make your life much easier.

You’ll need to know which version of PHP you’re using, and the download provided by ActiveState will have either an xdebug.so or php_xdebug.dll (Windows) ready to go for you.

My personal development environment is a MAMP Pro server, so I’ll detail how you integrate Xdebug in MAMP. The process is similar for your environment; Xdebug is a PHP extension, so you’re going to need to edit your php.ini and make the changes outlined here.

Disable Zend Optimizer

Zend Optimizer and PHP caching systems interfere with Xdebug, so your first step will be to disable those.

Edit php.ini

MAMP uses templates for server configuration files, including php.ini — you’ll need to edit that. Ensure you’re editing the php.ini that matches your active version of PHP.

Near the bottom will be a [Zend] flag with some config for Zend, ensure that it’s commented out, if it wasn’t using the GUI for MAMP Pro.

We’ll be adding a new section for Xdebug (Note: Ensure the zend_extension path matches your system path)

[xdebug]
xdebug.default_enable=1
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
zend_extension="/PATH/TO/YOUR/xdebug.so"

Restart Apache

Once you’ve saved your php.ini, restart Apache and view your phpinfo(), there should be an entire section for Xdebug

With Xdebug installed and running, we can get to the fun part.

Working with Xdebug and WordPress

There are a number of articles out there that describe how to get up and running with Xdebug for general PHP development, but I’m using it for WordPress work, and thought it might be better to tailor usage to that. Here goes.

The first thing to work though here is how you’re editing your code. There was a time where I thought debugging was a major reason to go with an IDE. I was wrong. Kind of. While debugging is an ingrained feature of an IDE, there are ways to use your favorite text editor in conjunction with Xdebug. Some text editors have extensions specific to Xdebug, and if you’re on a Mac, you’ll joy in finding out about MacGDBp. MacGDBp is a standalone application you can run for the specific purpose of talking to an Xdebug session. I’d argue to say that it’s even easier to work with than your IDE. All you have to do is run the app and hit the site you’re working on.

Setting things up in your IDE is a bit different, you’ll likely need to edit a preference or two. Debugging is also a bit different in that you’ll need to actively start and stop a debugging session. Your preference will dictate which you like better. NetBeans makes it pretty easy to work with Xdebug by checking out Preferences > PHP > General:

If you used the settings snippet for php.ini from above, your Xdebug sessions will run on port 9000 and you should be good to go. To invoke a debugging session in NetBeans you’ll be using the Debugging Toolbar primarily, and you can begin a debugging session by hitting the appropriate button (or hitting CMD+F5):

Variable tracing

By far the biggest benefit to using Xdebug for me is tracing variables. After all, the major inspiration for exploring the extension was to get away from extraneous echos and print_r()s. Depending on which piece of software you’re using (MacGDBp or IDE) the visuals will be a bit different, but the concept is the same. When you invoke your debugging session, execution will pause at the first line, giving you a few options.

1. Stop the debugging session
2. Continue the session (run the entire page call)
3. Step Over the current line
4. Step Into the current line
5. Step Out from the current line
6. Run to the cursor (not found in MacGDBp)

Note: One of the reasons I really like using an IDE (NetBeans specifically) is that this data is integrated into the environment (redundant to say that, I realize) to the extent of integrating breakpoints and all the way down to current memory usage:

The actions available during each step of execution are what really shows the magic of Xdebug. You can literally watch WordPress build a page, step by step, function call by function call, pausing execution to check out variables at any point.

As you step through, you can watch your variable stack change with every line executed, along with watching each function execute to see what is getting passed where:

In addition to checking out real-time variable values, another huge benefit to using Xdebug is stack tracing; finding out which functions were executed and when.

Breakpoints in Xdebug

While variable and stack tracing are a huge part of debugging, stepping through the entire execution of a WordPress page is extremely time consuming. I’d suggest checking it out to at least see how much work WordPress is doing on every page load. It’ll give you a look at WordPress in a way you likely haven’t seen it before. Breakpoints help alleviate that issue and allow you to debug what you’re actually working on.

You can think of a breakpoint as a stopping or pausing place during the execution of your program. You’ve likely heard of breakpoints in JavaScript development, and the same principle applies here. Working with breakpoints is another reason it helps to be using an IDE. The IDE itself will allow the setup and maintenance of breakpoints and everything is in one place. With a standalone application like MacGDBp you’ll be editing code in one place, and your breakpoints in another. More on that later.

Setting up a breakpoint is as easy as flagging the line of PHP at which you’d like to break as a breakpoint.

Setting up a breakpoint will tell Xdebug to run until it hits said breakpoint, allowing you to avoid having to step into every function call leading up to your custom work. Execution will pause at your breakpoints, allowing you to inspect the environment in real time, specially tailored to the piece you’re currently working on.

Setting up breakpoints in a standalone application such as MacGDBp requires that you manually edit the breakpoint by browsing to the file by hand and setting up breakpoints within MacGDBp itself.

Execution will pause at the breakpoint, and you can inspect things as you normally would.

Breakpoints will likely be a most used feature should you get more into debugging with Xdebug, and I can already tell it’s going to have a huge impact on the way I work. That said, I realize I’ve just scratched the surface with using Xdebug, and I can’t wait to more fully explore the innards of WordPress and learn more about what it’s actually doing under the hood.

Advertise here with BSA

As I became more involved in the front end community though, lots of people would talk about local development and how they wouldn’t trade it for anything in the world. As my process began to form and become more refined with every project, I first began my abstraction of working on the front end start to finish first, followed by ColdFusion development. While the initial inspiration was to see if local development was that much faster, the byproducts of segmentation have carried through to my workflow today. I always build out the front end completely before integration with WordPress.

Unfortunately though, I was stuck working on the in-house dev server due to licensing and frankly a feeling of being too busy to worry about exploring other options that kept us on ColdFusion. Fast forward a few years and we had moved to WordPress. That was the day I began developing locally and it made me love open source that much more.

My local development environment as of today is a 13″ MacBook Air running OS X 10.6.6 with MAMP Pro. I was running XAMPP for a time but since moved to MAMP Pro due to the ease of creating named virtual hosts, switching between recent PHP versions, local Postfix, and easy fine tuning of Apache modules to name a few reasons.

Editor v. IDE

That’s the environment, the other big piece is the editor. I’m a self-proclaimed editor addict; I’m always interested in what’s being released and why it might help me work faster. That said, however, I purchased a license for TextMate the day I moved to OS X in 2006 and to this day it remains the best tool for the job. Sublime Text 2, though, is on it’s way to being the TextMate 2 we’ve all been waiting for.

At the end of the day both TextMate and Sublime Text 2 are just text editors. I don’t profess that I’m the world’s best programmer by any means, but I’ve built a few things over time, and I don’t see that going anywhere soon. I have a heart for design, but practicality keeps me neck deep in markup, style, script, and PHP every day of the week at Iron to Iron and I love it. I’m liking it so much in fact that I’m finding that I want to get more out of my programming workflow, a text editor isn’t really cutting it. Enter IDEs.

I’ve had a nagging interest in IDEs since first hearing about them. While a much more elaborate piece of software, I’m essentially using those pieces in segmented applications already, and the editor itself is much more elaborate. When working with a text editor, it’s likely you’re using that to edit the code, another application for version control, yet another application for working with your databases, your browser for documentation, and the list goes on. That’s what I’m doing anyway. I’ll edit code in TextMate (Sublime Text 2), commit in Versions, Sequel Pro for all things database, and Chrome to review documentation when needed.

I recognize and appreciate that many of you are using command line git, command line vim, and so forth. While the command line is super productive and minimal, sometimes I like eye candy for the sake of eye candy.

IDEs are, by nature, fully featured and very comprehensive. The most attractive feature of an IDE for me is codesense, or smart autocompletion of code. Many times when I’m reviewing documentation, it’s simply an effort to get function parameters right on the first try. Codesense helps do that for me, and even provide more detailed documentation on WordPress-specific functions as many IDEs will pull in PHPDoc which can be really useful on the fly. IDEs aren’t the only kids on the block using codesense, though. Many newer text editor builds are doing the very same thing which is great. So what is it that has me wrapping back to IDEs? Debugging.

Debugging. My final frontier. Until the next one.

Debugging and (unit) testing are two aspects of my workflow that I admittedly have not spent a gigantic amount of time with. To me, that reflects poorly on my professionalism as a programmer and it’s something I want to focus on over the coming years. My workflow is filled with print_r() and echo when needed and it just feels sloppy. Sure, it gets the job done, but it just feels like things can be done better, faster. Debugging solves that feeling for me.

I’m currently integrating Xdebug into my workflow and it just feels right. Not only does it feel more productive, the geek in me goes nuts in the fact that I can step through a call to a WordPress page and watch things execute line by line. Beyond that I can keep an eye on memory usage, call stacks, check out variables at any point in time during execution, and the IDE caters to exactly that. As I build more advanced things for WordPress, this interaction exchange is going to prove extremely valuable.

For the time being, I’ve settled on NetBeans as my IDE of choice. I explored many of the available IDEs and chose NetBeans because of the customizable language patterns (it lets you define, for instance, how your braces are formatted), it’s integration with Xdebug, it’s price tag, and it’s release performance over the past couple of years. I don’t love the fact that it runs on Java, but overall I like the decision. Komodo comes in as a close second, but the price tag is a bit up there for something I’m not sure will remain in my workflow over the next six months. Should the IDE route remain valuable for me over time, I’ll begin to evaluate other IDEs based on features. Suggestions welcome.

All things considered, I’m hoping to go cold turkey with NetBeans for the next week. I’d like to revisit the actual debugging process in the form of a screencast should anyone be interested in checking that out on a more intimate detail. I’m also hoping that the broadcast of my newness to it will help get some targeted feedback on what I can do to take even more advantage of what an IDE and debugging tools have to offer.

Advertise here with BSA

I still use Media Temple’s Grid-Service to host a number of development sites as well as some daily-use applications. I happened to be working on Iron to Iron’s production server, making some optimizations to APC (Alternative PHP Cache) which I use in conjunction with W3 Total Cache.

If you’re not caching your WordPress installs I definitely suggest getting on board with W3 — it’s honestly stellar.

While I was poking around some documentation, I stumbled across a quick how-to on making APC work with (mt)’s (gs). I’m not sure why it never occurred to me that it’d work, but it’s great! If you’re running your WordPress site on Media Temple’s Grid-Service, definitely take a few minutes to get APC up and running with W3 Total Cache.

Advertise here with BSA

It’s a rarity for me to read a post that does anything but assume the fact of OOP being the best way to approach application development and go from there. This was a nice, refreshing look at some of the frustrations I have when I work with objects and what surrounds them.

WordPress is (for now) largely procedural and that helps me and anyone else to become proficient in using everything from A to Z in a realistic timeframe. Sure, there are times when you hit a bit of a rabbit hole in chasing down function calls and tracking how the variables are handled, but for the most part it feels straightforward.

A big part of programming to me is the human factor — is it easy to read someone else’s code, even when you’re already familiar with the language? There are times I’ll be reviewing an application written in PHP, a language I’ve worked primarily in for years, that feel like they take way too long to understand. While that could be due to the author’s implementation, I sympathize with Oscar when he speaks about the issues of understanding someone else’s OOP.

On the complete other hand, there are many aspects of OOP that I’ve come to know, like, and embrace. I think Oscar’s second-to-last paragraph speaks well about The Next New Thing and that’s “all we’ll need” to be happy with OOP. I have a bias against ‘all we need to do’ and much favor just doing it; see where the dust settles. I know that’s super hard to accomplish with a programming language, but who knows.

Advertise here with BSA