--- easypaypal.php 2008-02-11 21:24:24.000000000 -0500
+++ easypaypal.php 2008-02-11 21:23:39.000000000 -0500
@@ -211,6 +211,7 @@

if(!EasyPayPal_BypassCheck())
{
+ $cats = array();
$post_ID = $post->ID;

$temp = get_option("easypaypal_categories");

Just copy this in to a file and use patch -p0 < file to apply the patch – or just find line 211 and add in the line indicated with the + symbol.

Well, after several hours of tinkering and encountering PHP source code “bugs”, I finally got it to compile. I had to do a few fixes too apparently – I was missing some TSRM junk to the parse_tag() function (and I believe that’s because it passes a zval around, so it needs the thread-safe stuff with it), and I had some calls to strlen() which needed to be explicitly cast to avoid warnings. This got rid of some of the compile-time warnings (there are still warnings about strcat() and cousins being used, but I’m smart and know how to use them properly) generated by VC++ 2005 and popped out a tasty php_template.dll for PHP 5.2.1.

The VC++ project files are now included in the official releases of php_template (along with a pre-compiled version of php_template.dll) so that all of you lovely folks out there can compile your own versions too. Compiling it isn’t too tough – grab the free version of VC++ 2005 (Express), the Microsoft Platform SDK which has the headers and such required to compile, PHP source code and a package from PHP as well called “bindlib_w32″ which contains some additional header files. Throw the bindlib_w32 directory in to the root of the PHP directory, and the php_template directory in to the ext directory in PHP. Load up the VC++ solution file (.sln) and build it – that’s it!

I’ve also finally put the code in to an SVN repository on my local home server so I can keep track of the working trunk code, and some branched code which was supposed to be better but suffers from memory leaks – I may not end up using it, but kept it for the ideas it involved. I think I might instead look towards using a lexer as the parser engine as it should provide much more flexibility in the language structure, however I’d really have to pay attention to potential speed losses due to lexers being naturally slow parsers in some cases.

You can get your shiny new copy from the downloads section – more specifically, right here.

define('__PATH__', dirname(__FILE__));

This gives you a new constant, __PATH__, which will be the full directory part of __FILE__. This saves you writing dirname(__FILE__) all over the place since you will no doubt end up using that if you use any sort of relative path include system. Oh and yes I know it’s “bad practice” to define something like __PATH__, but the nice part is that if PHP ever does implement that constant – it should be what we have it as right now, so you just remove the define() statement and be on your merry way.

The second useful thing to add is a function which helps you in crafting relative URLs (though I’m sure it can be used elsewhere too):

function basepath($source, $search = '') {
$source = strtr($source, DIRECTORY_SEPARATOR, '/');
return substr($source, strpos($source, $search) + strlen($search));
}

You pass the function a path to a file and a string to search for in that path. If it finds the search string, it removes it and everything before it in the path and returns what’s left. So, say you called it as basepath(__FILE__, ‘/public_html/’) and __FILE__ was something like ‘/home/username/public_html/website/includes/file.php’, it would return ‘website/includes/file.php’. Since you will no doubt know the name of a parent path somewhere a long the lines, you can use that to strip out what you already know (so in this case, the non-url portion of a URL for your site) and end up with a path a client browser can access.

I’ll leave it up to you to see how useful these may be and how you want to use them – but the purpose is to remind you to never hard code paths if you can avoid it – especially if it’s a 3rd party addon (like themes and plugins for WordPress, for example).

Anyways, right now I’m trying out this flickrRSS plugin which isn’t bad, but honestly doesn’t do anything spectacular, and it’s not as feature rich as using a flickr badge (though it doesn’t put a requirement of JavaScript on the client which is nice). I would prefer to use the flickr badge for now, but the default WordPress theme I’m using is horribly written (though I will say it looks rather nice – but the HTML/CSS coding causes all sorts of problems when you try to add to it) to be honest and was pissing me off as I was trying to display images as floated block elements, though this caused the rest of the sidenav to flow as if the entire image div was a floated inline block. Of course clearing all floats doesn’t work since the entire sidenav is floated itself (argh!).

So, I figure I might have my way with flickr and WordPress on my own and write my own (and first!) plugin. First I’ll see what code gets spat out from the flickr badge, and see if perhaps I can code something in PHP to emulate it so that I can in the end have a configurable module that allows all the flickr badge features, but no JavaScript or other client-side driven scripts required. We’ll see what I end up with.