
October 2008
September 2008
August 2008
July 2008
June 2008
Or “How I finished my first Wordpress plugin without being a total n00b”
One common issue when you are working with a new technology or api for the first time is figuring out the best practices and snags. Sure, once you have been writing code for over 10 years, you can pretty much hang in any language. However, it doesn’t mean what you are going to write is any good. The biggest problem is that engineers tend to re-invent the wheel. My friend Tobias and I were having a conversation about this when he mentioned this book “Dreaming in Code” which illustrates this issue very well.
I recently wrote my first Wordpress plugin for Me.dium. It’s not released in the wild yet, but I have it here on my blog (on the right, under the MyBlogLog widget). I pull in an RSS feed of Me.dium’s hot search terms. The feed is cached in order to reduce load on Me.dium’s servers. You can also configure the number of terms to show as well as whether or not to show the descriptions. The plugin itself is very simple, but the value I got was in the process of writing it.
So, how did I write a solid PHP plugin in a room full of Java Engineers who may not even know what Wordpress is? I decided to work as collaboratively as possible, even in isolation. I tried to keep to my motto–If you have to force it or it’s too hard, you are doing something wrong.
First I set out to ask some experts. I sent an email out to some Wordpress hot shots asking how to approach certain problems from a strategic perspective. How is it best to store settings? What level of configuration is too much to ask for users?
Not everyone answered my email, but Alex King did. He saved me hours of research work by letting me know about the settings table (duh!).
I went on a hike with some buddies, including Alex from Gnip who helped me consider the best time to parse and store my xml. My tunnel vision was so focused on storing the data that I couldn’t see that there was a better way to store it. My original plan for storage seems completely absurd now–what was I thinking? More hours of work saved with a simple conversation.
I also posed my question on seesmic:
Anyway, the point is I had a ton of fun and the process ended up being quite collaborative, even though I was working somewhat in isolation. I am happy to write a more technical blog post as per my usual, but wanted to share this higher level thought process.
ps. Special thanks to Jud for pointing out that there was NOT a for loop bug in my Windows PHP install, but that I was missing a $ in the middle comparator. SRSLY!
Tags: me.dium, php, ponderings, wordpress plugin development
I’ve been using CodeIgniter now for a new project I’m working on called Giftola. CodeIgniter is an MVC framework for PHP. I like CodeIgniter because it’s very lightweight, yet it offers some pre-built functionality to deal with some of the tedium (like form validation) of web development.
I’ve used other PHP frameworks in the past, and I find the way CI organizes files to be very intuitive and things are easy to find.
One problem with using frameworks is that often developers don’t actually utilize all of the features of the framework, often reinventing the wheel. In this post, I’m going to go over a very simple, but useful feature of CI, helpers.
Helpers are functions that are stored in a central location in the CI framework, and then utilized anywhere in the application. I’m going to demonstrate a simple helper I wrote called timestamp. Timestamp formats a date time string for SQL insertion. This helper allows me to ensure consistency across my entire application.
Here’s how they work.
CI has its own helper functions, which are located in:
You can add your own helper functions to the following location:
Your file must be named in the form: helpername_helper.php. In my case, I’m going to create a file called:
where I’ll write a very simple function:
function timestamp(){
return date(”Y-m-d H:i:s”);
}
?>
I use this function most often in my Models, so I’ll load it up here. In this case, I have an event model, where I’ll use the helper quite a bit. So, I’ll load it in the constructor.
function Event_model()
{
parent::Model();
$this->load->helper(’timestamp’);
}
}
?>
Finally, when I want to grab a timestamp, I simply call the function:
A pretty simple example, but hopefully it will get you thinking on how to consolidate functionality that you use often into the helpers structure.
Tags: CodeIgniter, frameworks, php, reference