It's Been A While

Yup, it's been a while since I posted in this here section. I assure you, it's not dead. I'm just A Busy Guy®.

I've started thinking about the next version of this web site. Currently, it's powered by pMachine. I really like it and find that it's easy to maintain. Basically, it meets my needs. Plus, it's real easy to inject my little PHP hacks into it. But being the person I am, I like to tinker with things and learn new stuff, so lately I've been looking into other things.

First thing I've looked at is another pMachine product called ExpressionEngine. I find myself somewhat loyal to pMachine, since it's what got me started doing things the "dynamic" way. ExpressionEngine (EE from now on) is **not** open source and costs money. However, there is a lot of support that comes with it. And the documentation is top-notch. I refer to it all the time! EE is quite a different animal from pMachine and will take some time to learn. Especially if I want it to do some of the new stuff I wanna do...

And then there's Geeklog. My friend Don mentioned it in my comments from a few posts back. I checked into it and really liked what I saw. It's open-source so it has the best price of all -FREE- and it seems that it has some pretty active development at this time (It's what MacOSXHints runs on.) I've been playing with it for a few days now and find that it's coded really well. It's theme driven, so some aspects of the site are tightly integrated and controlled. I haven't tried to customize it yet, so I don't know exactly how much trouble it's gonna give me.

Currently, I have both EE and Geeklog installed in a testing environment. I'll post more when I find out more.

Till next time...

</marcus>

PHP and register_globals

Good thing I have a lot of hair, because I was pulling a lot of it out today. Last year I threw together a small web based software inventory script using PHP and MySQL. When I upgraded my system to OS X Panther (which uses PHP v4.3.x), the script suddenly broke, making the web interface unusable. I offloaded the database and script to a Linux box (running PHP version 4.2.x), where it has happily been running ever since.

Today I decided it was time to fix the problem so that I could put the database back on it's rightful home, my Mac box. After some rather frustrating time spent troubleshooting, I discovered that forms were no longer passing variables to other pages.

I have a script that follows this logic:



The form calls a file called result.php, which merely contains:



Normally, the result.php page would print whatever was entered into the textbox of the first page. Not the case with PHP 4.3+ (which ships with OS X Panther), with which you get bubcus, nada, nothing. After fiddeling around for a while, I ended up digging into my php configuration file (php.ini), in which I found this most helpful statement:

"; Whether or not to register the EGPCS variables as global variables. You may
; want to turn this off if you don't want to clutter your scripts' global scope
; with user data. This makes most sense when coupled with track_vars - in which
; case you can access all of the GPC variables through the $HTTP_*_VARS[],
; variables.
;
; You should do your best to write your scripts so that they do not require
; register_globals to be on; Using form variables as globals can easily lead
; to possible security problems, if the code is not very well thought of.
register_globals = Off"

This explained why my pages are no longer passing variables. With register_globals being Off, variables are only valid on the page that defines them. Something else that caught my eye though, was the line "you can access all of the GPC variables through the $HTTP_*_VARS[] variables".

Wanting to know more about the $HTTP variables led me on what would become another long, but most informative learning journey. I headed to the definitive source on PHP, PHP.net, where I found a plethora of additional HTTP variables available, including the variables I was after. PHP's web site also produced another gem, which explained why I had my variable-passing problem in the first place:

"...before PHP 4.2.0 the default value for register_globals was on. And, in PHP 3 it was always on. The PHP community is encouraging all to not rely on this directive as it's preferred to assume it's off and code accordingly."

Sure enough, everything worked as expected if I replaced:



with



Now knowing my problem but being too lazy to change my script right this moment, disregarding the warning and throwing caution to the wind, I set the register_globals value to On for the time being. Restarted Apache to make PHP reparse the php.ini file and my little inventory script was all happy again.

Well, if I can save even one person just one strand of hair, this post was all worth it. All's well that ends well.

(I make extensive use of the PHP manual at the PHP.net website. So extensively, that I decided to download their HTML version of the manual and put it on my site (here). Usually, when I mention a function, I will link it to the PHP.net web site, however, occasionally I may link it to the manual I have here locally (Why?...because I CAN). If I link to my local pages, I will denote the link with an ML in superscript, like this: date function^ML.)

Britney Calendar Image

On my other blog, I implemented a super-quick script to display the current image that coincides with my Britney Spears calendar right above the update calendar.

First things first, I had to scan all 12 images from the calendar. I saved each image with it's corresponding three letter month name (i.e., Jan, Feb, etc) and the extension .jpg.

Then, at the top of the page, I assign the current three letter month name to a variable called $calmonth, by including this line:



Using the PHP date function^ML with M produces the three letter month name.

Wherever I want my Britney image to appear, I put the following:



Whola! Britney all year-round!

Resources:
PHP Date Function