Press "Enter" to skip to content

Tag: php

PHP: md5 hashes, base_convert and 32 bit limitations

I’ve had cause to convert an md5 hash from the standard hexadecimal base 16 to base 36 (mainly to make it shorter for presentation purposes). However, using base_convert in PHP proved unreliable as the string wouldn’t always convert back correctly. This is on 64 bit Linux, but I’m not certain PHP has been compiled with 64 bit support (so it is probably defaulting to 32bit).

However, thanks to this post on the PHP documentation, I’ve changed the code to use:

/*use gmp library to convert base. gmp will convert numbers > 32bit*/
if (!function_exists('gmp_strval')) {
    trigger_error('GMP does not appear to be compiled into PHP');
}
function gmp_convert($num, $base_a, $base_b)
{
        return gmp_strval ( gmp_init($num, $base_a), $base_b );
}

To test this, here’s the code I used:
function testconvert() {
    $a=Array(10,23,46,239423, PHP_INT_MAX, 323927832, 174623748237, PHP_INT_MAX.PHP_INT_MAX);
    foreach ($a as $key) {
        $converted=gmp_convert($key,10,36);
        $phpstandard=base_convert($key,10,36);
        print 'key='.$key.'. Convert: '.$phpstandard.','.$converted;
        if (!(base_convert($phpstandard,36,10)==$key)) { print '<strong>Standard PHP Failed</strong>'; }
        if (!(gmp_convert($converted,36,10)==$key)) { print '<strong>GM PHP Failed</strong>'; }
        print '<br>';
    }
    foreach ($a as $skey) {
        $key=md5($skey);
        $converted=gmp_convert($key,16,36);
        $phpstandard=base_convert($key,16,36);
        print 'key='.$key.'. Convert: '.$phpstandard.','.$converted;
        if (!(base_convert($phpstandard,36,16)==$key)) { print '  <strong>Standard PHP Failed</strong>'; }
        if (!(gmp_convert($converted,36,16)==$key)) { print '  <strong>GM PHP Failed</strong>'; }
        print '<br>';
    }
}

PHP: Zend_Dojo_Form SubmitButton not showing

In version 1.7.0 of the Zend Framework, specifically the Zend_Dojo_Form_Element_SubmitButton class (which makes the Zend_Form use the Dojo Javascript library), there is a small bug which prevents the label section of the Submit button being shown.

To work around this, just add something like:
$eElement->setDijitParam(‘label’,’Submit label’);
to work around the issue.

This is a known issue in the Zend Framework and will be fixed in the next release… If, however, like me you have spent a good hour or so trying to find out why your implementation doesn’t work and other demonstrations on the internet do, well now you should be able to find out why!

e-Commerce: Changing the VAT Rate in ClickCartPro (UK Edition)

If you are using the UK edition of Kryptonic’s ClickCartPro ecommerce system (sold by Greenbarn Web) and you still haven’t updated the VAT rates in it to take into account the reduction in UK VAT on the 1st of December from 17.5% to 15%, then here’s how to do it.

To change the VAT rate in ClickCartPro from 17.5% to 15% (or vice versa), just login to the admin panel (normally via http://www.example.com/admin.php ) and select from the left hand menu “Commerce: Orders and Checkout” (it should be the third option down) and then “Manage EU Tax Rates”. You’ll probably see three rates “High Rate”, “Low Rate” and “Zero Rate”. If you select “Update” next to “High Rate”. In the “EU Tax Rate” box, you should see the current rate of VAT being shown and be able to adjust it to 15%. Click “Submit” and it should take immediate effect.

PHP: Difference in Dates Using Zend_Date

I’ve had to write some code recently that handles peoples ages based on their date of births… Something simple you expect, until you realise that PHP can’t really deal with years before 1970 (due to UNIX date time restrictions). Luckily Zend_Date (in the Zend Framework) comes to hand to help!

But how do you actually turn a date in the format YYYY-MM-DD into a difference in years? Well, here’s how! We’re relying on the date to be consistently 10 characters long in the format YYYY-MM-DD with any unused date “zerod” out (for example, if we are using OpenID which allows people to “hide” parts of their DOB):

if (preg_match('/^([1-2][0-9][0-9][0-9])\-([0-1][0-9])\-([0-3][0-9])$/',$sDob,$aMatches)) {
    $iYear=$aMatches[1];
    $iMonth=$aMatches[2];
    if ($iMonth<1 || $iMonth>12) {
        // Set a minimum/standard month for this calculation
        $iMonth=1;
    }//end if ($iMonth<1 || $iMonth>12) {
    $iDay=$aMatches[3];
    if ($iDay<1 || $iDay>31) {
        // Set a minimum/standard day of the month for this calculation
        $iDay=1;
    }//end if ($iDay<1 || $iDay>31) {
    // If anybody was born before 1850 or after 3,000 (say they have a time machine)
    // then, sorry, they'll have to check their date of birth elsewhere!
    if ($iYear>1850 && $iYear<3000) {         if (checkdate($iMonth,$iDay,$iYear)) {             $cNowDate=new Zend_Date();             $cUserDate=new Zend_Date(Array('year'=>$iYear,'month'=>$iMonth,'day'=>$iDay));
            // Sanity check that the date the user entered is actually in the past!
            // No future time travellers welcome here!
            if ($cNowDate->isLater($cUserDate)) {
                $cDifference=$cNowDate->subDate($cUserDate);
                $aDifference=$cDifference->toArray();
                print 'Year difference is:'.$aDifference['year'];
            }//end if ($cNowDate->isLater($cUserDate)) {
        }//end if (checkdate($iMonth,$iDay,$iYear)) {
    }//end if ($iYear>1850 && $iYear<3000) {  }//end if (preg_match

PHP: Zend Framework, MVC, Cookies and 4096 byte oddities

A little word of warning which has puzzled me for over 3 hours in debugging…

If you use Zend_Controller_Front::getInstance()->dispatch(); in your Zend Framework index.php file for firing off the MVC system, and the returned page is over 4096 bytes (4 kilobytes) in size you cannot set a cookie afterwards without causing the “fun” error “Cannot modify header information – headers already sent by (output started at …/library/Zend/Controller/Response/Abstract.php:546) in …”

To work around this, you’ll need to change the code from just:

Zend_Controller_Front::getInstance()->dispatch();
setcookie(. . .);

to:

$front=Zend_Controller_Front::getInstance();
$front->returnResponse(true);
$response=$front->dispatch();
#Zend_Controller_Front::getInstance()->dispatch();
setcookie(. . .);
$response->sendResponse();

I’m sure there is a slightly better way of setting Cookies in the Zend Framework, but that’s a work around for the normal way I’ve found.

If you’ve got any “better idea” suggestions, just let me know.

(I found this “buglet” because a drop down select menu I was making with Zend Form Element was causing the “Cannot modify header information – headers already sent by” error once a number of items were listed: it took 3 hours+ of detection work to narrow it down to a content size issue, then it was a process of elimination ruling out Zend_Form_Element, Zend_Form, Zend_View and Zend_View_Abstract (which helped a bit with the debugging on the issue) and then to Zend_Controller_Front to Zend_Controller_Response_Http and finally to Zend_Controller_Response_Abstract)