Covert all tables from MyISAM to InnoDB

Here’s a quick one liner to convert all tables on in a specified database from MyISAM to InnoDB:

mysql -Bse "SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' engine=InnoDB;') FROM information_schema.tables WHERE engine = 'MyISAM' and table_schema = 'your_database_name';" | xargs -I {} mysql -e {}

Boom! You’re welcome.

The Simplest WordPress User Access Log Ever

Those of use who develop using pods often find we use it for everything. So here’s a quick tip on using PodsCMS to create a custom user access log.

Step 1: Set up the Pod

I’m assuming you’ve already installed/activate both the PodsCMS and Pods UI plugins. If not, please do so before starting.

Create a new Pod called “logins”.

By default each pod is created with a name and slug field. We’re going to use the name field but you can delete the slug field.

Then you’ll need to create a field for “date”. Of course, Pods stores the date any entry is created in a field called “created” which you can access from within Pods Templates. But it still makes sense to have a date field in the Pod itself, if nothing else for the sake of a clear data model.

So once you have added the date field your Pod will look like this:

Step 2: Add function

Now just add the following code to your functions.php file.

function mpv_add_access_log_entry($user) {
$user = explode('|',$user);
$log = new PodAPI(); 
$params = array('datatype'=>'logins');
$params['columns'] = array('name'=>$user[0],'date'=>date('Y-m-d H:i:s'));

This function uses the Pod API to insert a row in the logins table. Alternatively you can use the $wpdb class and do something like this:

global $wpdb;
$wpdb->insert($wpdb->prefix.'pod_tbl_logins',array('name'=> $user[0],'date'=> date('Y-m-d H:i:s')));

The only trouble with going this route is that in order to use the pods admin interface to manage the data, you’ll also need to add a row to the wp_pod table. This will change with Pods 2.0 so there’s no need to demonstrate. But I strongly recommend using the PodsAPI class as it will make sure to implement best practices and in 2.0 it will use the $wpdb class anyway.

So that’s it. To create an exportable report of the logins just install the “Exports and Reports” plugin. Or you can use PodsUI to create a custom interface.

Have fun.

The Conflicted Developer

As a developer I’m always struggling to balance the urge to learn new stuff and the need to be the best at the stuff I already know. I’m not sure you can be both, right? You’re either the guy (or gal) who knows everything about WordPress or Drupal or Ruby or whatever. Or you’re the guy who is flexible enough to work with all of them. So how do you know which one you are? And which one should you want to be?

I oscillate between the extremes daily. I’m starting to learn Kohana (the “swift” PHP framework). Of course, by the time I learn it there will be something else out there that needs to be learned. Chasing the dragon.

On the other hand I’m pretty comfortable working with Codeigniter for Custom PHP and WordPres for the quick stuff. Maybe I should just focus on being good at those before trying to learn new stuff.

What’s a developer to do?


WordPress Hack #3

Here’s a function that really should be in WordPress core by now. And maybe it is and I just can’t find it. But to get the source url for a post thumbnail you have to hack. Here it is:

** Parameters: 
** Size (optional): The width/height of the source image. Accepts either a string designating the WordPress image size, ( i.e. "thumbnail", "full","medium") or an array containing a custom size, i.e.  array(250,250) . Defaults to full size
function get_post_thumbnail_url($size = 'full') {
global $post;
$src = wp_get_attachment_image_src( get_post_thumbnail_id($post->ID), $size, false, '' );
echo $src[0];

Why WordPress?

I assume other developers often ponder this question. In a practical sense, the answer is “because it’s what you know”. But I’m pondering a bigger question. As a developer with a keen interest in PHP should I waste my time with WordPress? Can you ever get “respect” as a PHP developer when your tool of choice is WordPress?

WordPress is a dinosaur compared to most of the popular custom PHP frameworks. Frameworks like Codeigniter,Kohana and others are very light weight and scalable. They generally focus on concepts like OOP (object-oriented programming) and MVC (model-view-controller). Code reusability and encapsulation are priorities not luxuries.

WordPress is a vestige of  PHP before PHP had a robust object-oriented structure. As such it is mostly a collection of libraries of functions. Of course, with every new release these function are streamlined and improved. But ultimately WordPress is always going to be a procedural framework.

So if you’re interested in PHP why waste your time with a code base that will never be the vangard of PHP development?

Well, for one, just because WordPress core is less than impressive from a PHP point of view, does not mean that cutting edge approaches to coding are not implemented via plugins. Plugins are essentially little custom apps that tie into the WordPress API. But as such there are lots of plugins that exemplify flexible and cutting edge approaches to code development.

For instance, there’s a plugin out there the integrates Doctrine ORM with WordPress. Doctrine is a “Object-Relational-Mapping” interface that aims to cleanup how PHP interacts with Databases. Sure WordPress core doesn’t have a Database Abstraction layer, but if your interested you can use Doctrine in your plugins!

PodsCMS, one of my favorite plugins, is another one that pushes better code into WordPress. Pods is capable of managing massive complexity in WordPress content, but itself is a very light-weight, Object-Oriented framework. Moreover, PodsCMS, while not entirely MVC, at least separates code from markup which is a feature sorely lacking in WordPress core.

Other plugins, among them Shopp (an e-commerce plugin) and GravityForms, take very Object-Oriented approaches to coding. So just because there are limitations to WordPress core, does not mean developers passionate about PHP cannot excel and flourish. If anything, the lack of cutting edge PHP in WordPress creates a tremendous opportunity for hard core PHP developers.

But why? Why drive a station wagon when you could be driving a sport car? Well, because you have places to go and things to do … and people to take with you. The simple reality is that there’s a huge market for WordPress development. A bigger market than just about any other out-of-the-box CMS. And that means an opportunity develop good code for good projects.

So if you’re a WordPress developer and want to branch out into custom PHP, my advice is first, learn the WordPress way of doing things. Then forget the WordPress way of doing things. Experiment with custom frameworks and try to find ways to incorporate the innovations into the WordPress projects you’re working on.

And most importantly, don’t be afraid to NOT use WordPress for a project or two. Getting outside your comfort zone is what gets your  creative juices flowing.

WordPress Hack #1: Global Meta Variable for Custom Fields

This is the first in what I hope will be a series of posts on “WordPress Hacks”, simple code you can add to functions.php to make your life as a developer a little easier.

Ever get tired of typing get_post_meta($post->ID, $meta_key, $true); to fetch even the simplest of WordPress custom field values. Try this.

function setup_meta_var() {
global $wp_query,$meta;
$vals = get_post_custom($data->ID);
foreach($vals as $k => $v) 
if(count($v) > 1):
$meta[$k] = $v;
$meta[$k] = $v[0];

What this dandy little function does is automatically assign a post or page’s custom values to a global variable call $meta.

To use your custom field values now, you simply have the do echo the meta_key like so:

global $meta;
echo $meta['meta_key'];

If there is more than one value for that custom field, you will simply need to do a standard foreach loop.

global $meta;
foreach($meta['meta_key'] as $m) {
echo $m;

Update: Hey, I realized that in the code snippet I pasted here I was setting a $type variable. That was a relic of the custom script this code was taken from … so please ignore.