Setting PHP.INI path (or file) for PHP CLI shell scripts

Running a PHP script from the command-line, or CLI, is quite useful at times and is often used to perform some automated task, like a CRON cleanup script, to send out reminders, etc.

It’s common that these CLI scripts need some, but possibly not all, settings that are similar to the main application’s. I may, for example want to include the database configuration settings shared with the main application. So I often create a separate php.ini file for this purpose.

Running /usr/bin/php -c /my/very/special/path cronScript.php is simple enough, but what if I want to be able to create an “executable” PHP shell script? The obvious answer would be something like:

#!/usr/bin/php -c /my/very/special/path

at the top of the .php file, followed by my PHP code, right? Except that may not do what you want. I could not get the PHP interpreter to load anything in /my/very/special/path by using the above construct, even if it works from the actual command-line. After banging my head against the wall for a while, this turns out to work for these “shell scripts”:

#!/usr/bin/php -c=/my/very/special/path

Note the use of the = (equal) sign between the -c and the path (or file).

Carry on.

PHP is_numeric () fails WordPress version string check

This is, perhaps, obvious to most PHP developers. But it came somewhat as a surprise to me.

Using is_numeric () for validating a WordPress version string, such as ‘4.7’, does not seem to work very well when WordPress introduces minor releases such as ‘4.7.1’.

Since I cannot be bothered to figure out why it behaves in this (erratic, IMHO) way, I have since replaced the call to is_numeric () with a small function using a simple regular expression (regexp):

    function wpVersionStringCheck ($vs)                                                                                                 
    {                                                                                                                                   
        return (preg_match ('/^(\d+\.)+\d+$/', $vs));                                                                                   
    }

I’m sure there is a hole in there somewhere, but on the following strings at least, it gives me the desired result:

1.0 is valid
1.0. is invalid
1.0.1 is valid
1.banana.0 is invalid

jQueryMobile or “Mobile site” selection sets

Using jQueryMobile for a fairly lightweight “mobile site”, I wonder what all you experts say about selection sets. A (long) list of countries for example. To prevent excessive delays, I now split country selection in two screens. The first one shows A-Ö (A-Z for you English-speaking people), if I tap on B, the next screen shows a list of countries starting with B. Hitting the back button brings me back to A-Ö (A-Z), selecting a country takes me to.

It feels right, and it doesn’t transfer massive amounts of data that a) isn’t used half of the time, and b) doesn’t take time to render on slower mobile devices.

I’m not too concerned with database performance on the server for this particular selection set since the SQL query is static and resides in the cache 99.5% of the time.

Application event tracker (or really simple debugging) for PHP

DISCLAIMER: There’s nothing revolutionary with what you are about to read, should you continue 🙂 This is simply something I did to avoid having to use a debugger where using a debugger wasn’t practical; and also to avoid having to emit “debug output” throughout the application. There are a number of ways to accomplish this, and many people have done it before me. What I describe here works for me. If you break it, you own all the pieces, be it thirteen or four.

The problem, that I had, was to track the progress of an application that did some heavy data processing. During the processing, a number of things could go wrong. It didn’t necessarily have to terminate the application (I don’t like the good old tits up-method of ending a PHP-script, i.e. “die (‘Error’);”), but I needed to track a number of variables and states throughout the execution of the script.

Using “echo ‘The value of x=’.$x” constructs works for really small implementations. It’s a proven “debugging” method and has been used for a long time in the history of computer programming (well, something similar to that construct anyway, considering PHP hasn’t been along for that long).

I have a base class, upon which I base all other classes. If you don’t have one, simply derive the class you want to debug from the code that follows. Also, please note, this method can be extended in a zillion (possibly more) ways. My example doesn’t quite reflect my actual implementation, but it should give you an idea of where this is going.

The class (tested with PHP 5):

[php]
class ezPHPdebug {
protected //We do this to avoid non-derived external modification
$__rBuf;//Recording buffer

function __construct ()
{
$this->rBufReset ();//Clear recording buffer
}

function __destruct ()
{ }

function rBufRecord ($s)
{
$this->__rBuf .= $s . “\n”;
}

function rBufReset ()
{
$this->__rBuf = ”;
}

function rBufRead ($forHtml)
{
if ($forHtml)
return (nl2br ($this->__rBuf));
else
return ($this->__rBuf);
}

}//ezPHPdebug
[/php]

Nothing to it, right? Alright, let’s say we create an example class that uses this “debugger”.

[php]
class myClass extends ezPHPdebug {
function __construct ()
{
parent::__construct ();
}

function __destruct ()
{
parent::__destruct ();
}

function doSomethingImportant ($x)
{
$this->rBufRecord (‘{doSomethingImportant}’);
$this->rBufRecord (‘x=’.$x);
echo ‘Hello, this is a cool function, it does nothing.’;
echo ‘Oh yes, I forgot, $x is ‘.$x.’
‘;
$this->rBufRecord (‘{/doSomethingImportant}’);
}

function doSomethingElseImportant ($x)
{
$this->rBufRecord (‘{doSomethingElseImportant}’);
$this->rBufRecord (‘x=’.$x);
echo ‘Hello, this is an uncool function, it does something.’;
echo ‘Oh yes, I forgot, $x is ‘.$x.’
‘;
$this->rBufRecord (‘{/doSomethingElseImportant}’);
}

}//myClass
[/php]

This is (obviously) a very simplified way of using the “debugger” class, but it’ll do the job for now.

Now, in the “application” or “main” script, we do something like:

[php]
$r = new myClass ();
$r->doSomethingImportant (‘This is a string’);
$r->doSomethingElseImportant (1024);
[/php]

What does this do? Nothing much .. it’ll call the two methods (in myClass), which outputs some data and that’s it. But, what if we wanted to know what happened inside the class (myClass).. well, do this:

[php]
$r = new myClass ();
$r->doSomethingImportant (‘This is a string’);
$r->doSomethingElseImportant (1024);
echo ‘TRACKER: ‘.$r->rBufRead (true);
[/php]

This will output the same thing as the first example, plus an additional debug output.

By “recording” entry and exit names, we clearly show that we’re in a function (and that we’re not).

One could add automated timestamping to this, by forcing a timestamp to be inserted each time a line is “recorded”.
Another possible extension is of course to do logging directly to a file or a database; but part of the beauty (IMHO) of the in-memory tracker is that I can output the debug output in one go, and determine when I want to see it.