Test a Composer package from a local version / copy

Problem: I need to test a small change to a Composer package that’s on GitHub / Packagist, but I don’t want (yet) to request the change from the maintainer or fork my own version on Packagist or whatever… I literally just want to change one digit in a version number requirement.

Not that it’s particularly relevant, but the Package in question is a Volume storage driver for Craft CMS that makes use of Fortrabbit’s Object Storage.

Solution: Composer has a repositories feature which allows us to add Repositories other than the default Packagist.org one by adding a new block to the project’s composer.json. There are quite a lot of different sorts of repositories that can be setup, but I’m interested in the path one. This option will allow me to stick a package’s contents almost anywhere on my local machine, and path to it. Example: Continue reading “Test a Composer package from a local version / copy”

What is Notice: unserialize() [function.unserialize]: Error at offset then?

Problem: While doing some Shopp Plugin support work earlier, one customer was getting this error…

Notice: unserialize() [function.unserialize]: Error at offset 111 of 118 bytes in /home/maxwell4/public_html/main/wp-content/plugins/shopp/core/model/Settings.php on line 228

Continue reading “What is Notice: unserialize() [function.unserialize]: Error at offset then?”

Set date.timezone in PHP without using php.ini

Problem: I needed to set default timezone for a site to get Zen Cart installed. The usual way would be to call date_default_timezone_set from a globally included script, or to use the date.timezone option in a php.ini file. The problem is that I don’t have access to the php.ini file and there is no script that will be called across the board. Continue reading “Set date.timezone in PHP without using php.ini”

Convert eregi_replace to preg_replace in old class.phpmailer.php scripts

Problem: I have lots of legacy php code on old sites that uses eregi_replace to format up an HTML email body. As eregi_replace is now depreciated it can be replaced with preg_replace. This is tricky sometimes because the formatting is quite different.

Fix: Here’s a common line from class.phpmailer.php scripts:

$emailBody = eregi_replace("[]",'',$emailBody);

To convert that you’ll need to do this:

$emailBody = preg_replace("/\\/", '', $emailBody);

Wondering why there are so MANY escaping backslashes there? I asked that question and got this answer:

“..the backslash needs to be escaped once for the php string’s benefit, then again for the interpretation of the regular expression engine, as escaped characters like d indicate a digit in regular expressions. So a pattern of \d would match a digit, but \\d would match a backslash then a d character. PHP strings are lenient on backslashing when it isn’t necessary, so:
– setting a string to “d” will give it a value of d (the same as setting it to “\d”).
– but setting it to “”” will give a value of “.
– and setting it to “” will return a syntax error.

– PHP double quoted strings will consume the (first) backslash for \ n t r and “.
– PHP single quoted strings will only consume the first backslash for \ and ‘ “

There.. clear as mud!

Swap days and months in PHP – quick and dirty MM/DD/YY to DD/MM/YY

Problem

I have a ton of date strings in the stupid US style dd/mm/yy format. i.e. 12/24/09 being 24th September 2009. I need to convert them to the UK style dd/mm/yy.

Solution 1

As a string in PHP is really just an array of characters, the simplest fix was to address the individual number characters by their positions within the sting, and rearrange them into the format I wanted:

$d = "12/24/09";
$d = $d[3].$d[4]."/".$d[0].$d[1]."/".$d[6].$d[7];
echo $d; // displays "24/12/19".

Solution 2

I posted my solution on twitter (@hutchings) and asked for comments and @londonhackspace organiser Jonty came back with the following elegant (and much cleverer) suggestion:

$d = "12/24/09";
$d = preg_replace('|(d+)/(d+)/(d+)|', '$2/$1/$3', $d);
echo $d; // displays "24/12/19".

So provided you know that your original string is in US format, both these solutions can be used. In my testing I found solution 1 executed more quickly, but isn’t as pleasing to look at 🙂 Cheers Jonty.