If you were ever curious about how the encryption part of the ssl protocol worked then you should check out this great tutorial:
http://www.devco.net/archives/2006/02/13/public_-_private_key_encryption_using_openssl.php
It shows you how to create a private and public key using the RSA algorithm and then how to encrypt and decrypt messages, all with the commandline tool openssl. If you have Mac or Linux then chances are openssl has already been installed on your machine.
I’ve been working with the MysqlDB object made for python. I want to make a note that if you make a select statement that returns no records, when you fetch it in python you’ll get an empty list. The way to test for this is be asking if the value is not. If the row returned has null values those can be tested with None.
Today I want to remind myself of what the relationship between Apache and PHP is. Support for PHP can probably be compiled into Apache but it’s more flexible if you simply configure Apache to support loadable modules. PHP can be installed just like any other program, but in order to get Apache to recognize it you have to use the Apache tool apxs (APache eXtenSion tool) which creates a shared library that Apache can use to interface with PHP. When PHP is set up to work with MySQL, Apache doesn’t have to know a thing about it.
With the use of Xdebug and Netbeans I finally found where it all happens. First the posts are retrieved by the WP_Query object using the get_posts() member. Towards the end of the function, around line 2742, a function called update_post_caches is called which then calls update_postmeta_cache which takes an array full of the ids of the retrieved post items and fetches their meta data and saves it in a cache to be used later on by calling get_post_meta(). The get_posts() member of the WP_Query object is 844 lines of code that makes a bunch of calls to other functions defined else where in other files. This makes it a very difficult function to study and I couldn’t have come up with this interpretation of what it does without Xdebug, a really great tool!
Today I’d like to sing the praise for a library extension for php called Xdebug created by Derick Rethans. This allows you to debug a php program. And Netbeans is able to provide an easy interface for traversing the code with this debugging library. With a php software as big and complex as WordPress, if you’re curious about how it actually works Xdebug is absolutely crucial. Otherwise you have to go through the code line by line yourself. And while you may learn something this way, quite often there’s just not enough time for this approach.
I’m using Ubuntu Lucid Linx as my operating system. First I used this tutorial by Jonathan Christopher:
http://mondaybynoon.com/2011/03/28/wordpress-development-xdebug/
I was able to glean some information applicable for my set up but the specifics are geared toward Mac users. I blindly used the Ubuntu repositories to download xdebug and netbeans. It appeared to work initially but then I noticed that Netbeans wasn’t displaying all of the variables. After doing a little searching on Google I found this article:
http://icephoenix.us/php/xdebug-doesnt-show-local-variables-in-komodo-netbeans-or-eclipse-pdt/
Apparently the Xdebug version in the Ubuntu repository doesn’t work with php version 5.3.2. But all you have to do is install it manually following the instructions in that article above.
And now hopefully I can figure out at what point in the retrieval of posts that WordPress gets the metadata attached to it!
So I’ve been looking into how post information is retrieved in WordPress but I can’t seem to pin at what point the post meta data is retrieved. From a high level, the user fetches some posts and loops through its values. Also in the loop you include the get_post_meta function to get the meta values that have keys associated with the id of the post. But when you call this function you’re actually accessing a cache in memory where the retrieved values have already been stored. This leads me to believe that the metadata is actually retrieved somewhere in the get_posts() member of the WP_Query object. I scoured the code looking for a line that might support this theory. I used grep searching lines that would indicate the selecting of all values with a particular id from the postmeta table but couldn’t find anything. 
I just thought of a basic debugger plugin. And the code goes like this:
<?php
/**
Plugin Name: Test Zone
*/
function testZone(){
}
add_shortcode('testZone','testZone');
?>
}
And it’s just that simple. Now you can place whatever code you want in the testZone function and it will output on the page where you put the short code.
The WP_Query object contains the query() member that feeds the parameters given it to get_posts() member which does a whole bunch of stuff including making a call to parse_query(). Perhaps knowing this will make it easier to understand the full potential and limits of accessing the wordpress database through this object. It’s my understanding that in order for this to work there has to be a lot of structural givens.
If you go to the query.php file in wp-includes and go to line 2603 you’ll see a curious piece of code:
$this->request = " SELECT $found_rows $distinct $fields FROM $wpdb->posts $join WHERE 1=1 $where $groupby $orderby $limits";
Up till this line the get_post function populates the variables above based on a number of criteria. If you really want to see what’s going on then put this line of code directly after the one above:
echo $this->request;
Hi World!
I want to start my blog by talking about jQuery. I like jQuery but I’m not satisfied with the whole ‘black box’ notion that one doesn’t have to know how it works to use it. Because of that most of the information available on jQuery only explains the interface. I want to dissect it fully to see what makes it tick. If you look at the source file there’s about 1000 lines of confusing code. So to start learning I striped it down to what I feel is a good basic structure.
Here it is:
//this jQuery gets returned a jquery object,
//this jQuery will get exposed as a global
var jQuery = (function() {
// Define a local copy of jQuery
var jQuery = function( selector, context ) {
// The jQuery object is actually just the init
//constructor 'enhanced'
return new jQuery.fn.init(selector, context, rootjQuery);
},
rootjQuery;
//Next comes adding a whole bunch of functions to
//the fn prototype
jQuery.fn = jQuery.prototype = {
constructor: jQuery,
init: function( selector, context, rootjQuery ) {
if ( !selector ) {
return this;
}
},
//I screwed with the core!
yo:function(){alert("yo")},
};
// Give the init function the jQuery prototype for
//later instantiation this is the piece of code that
//makes it all possible. you have init's prototype
//point to jQuery's prototype, so that init can
//access the functions attached to it!
jQuery.fn.init.prototype = jQuery.fn;
// Expose jQuery to the global object
return jQuery;
})();
//this is the end of the very first immediate function
So here's a run-down of what's going on. First, a variable named 'jQuery' is created in the global space. And it's assigned the return value of an immediate function. The return value will be a complex object that can be used to create other objects. What follows is a more detailed explanation.
Inside the immediate function there's a local variable also called 'jQuery,' of course different from the one in the global space. This variable points to a function that takes a selector and a context as parameters. If you've used the jQuery object before, then you know that you pass it this information in order to select a set of html elements. While this function is local to the immediate function it's contained in, eventually it will get returned to the jQuery variable in the global space. And this is how you will get to access it.
This function returns an object. But the curious thing is that the object jQuery returns is attached to itself:
return new jQuery.fn.init(selector, context, rootjQuery)
Further down the code we see that jQuery.fn points to the prototype of jQuery. Then an object literal is assigned to jQuery.fn with one of it's members being the init method used above.
I simplified the inside of the 'init' function quite a bit. In fact I made it so it only works if there is no selector. The reason I did this is because I'm not interested in how a set of html elements gets selected right now. Here I just want to understand how by simply using the code "jQuery()" in my own script I get returned an object with a whole bunch of functions attached to it. In addition to the 'init' method normally you'd see a whole bunch of other methods here like 'ready', 'eq', 'first', 'last' and so on. But for simplicity sake I replaced them all with my 'yo' method. So the object returned to you when you use jQuery really is it's 'init' member. But if that's true then how come the 'init' object has access to all of the functions attached to the jQuery object, like 'yo' for instance. The answer to that is in this line:
jQuery.fn.init.prototype = jQuery.fn;
The 'init' object's prototype actually points to the 'jQuery' object's prototype.
And that's it for now. I understand this probably isn't the best explanation but I'd be happy to answer any questions to help clear it up. In my next post perhaps I'll take a closer look at how the 'init' method works.
Thank you for reading.