PHP Magazine

Recently, I become involved in Zend Framework even more – this time not only developing using it (which I am doing for some 3 years now), but actually contributing back whenever I can. And I plan to dedicate even more hrs/week to work on this undoubtedly nice, yet complex piece of software.

So, lyrics aside – today I had to learn new Subversion trick (the hard way), so I am writing it down here, in hope that it saves some other hacker time to play PacMan.

Problem:
I needed to checkout into single working copy all relevant (to me) parts of ZF repository. Not doing separate checkouts for the trunk, then branches, then incubator, but having single checkout of repo which I can keep up to date by simple

svn up

directly from the root of working copy.

Now the problematic part: you never ever want to checkout whole ZF repository – need I mention that it is HUGE? So, what I actually wanted is to checkout the whole repo excluding some paths – such as lots of previous releases in tags/branches folders.

Read the rest of this entry

Sometimes I get annoying ^M chars when opening files using Vim – obviously it’s a DOS EOL which mixes the picture.

The good place to seek for fixes and workarounds is Vim Wikia, which not only shows you what to do, but also gives you a brief background on what is going on (if you are unaware).

I am generally happy with dos2unix utility to convert files, but sometimes it seems to be unable to fix the issue. In such situations I do a simple search/replace, right inside of Vim (in ex mode):

Read the rest of this entry

Usage of Zend_Http_Client is pretty straight-forward:

$client = new Zend_Http_Client($uri);
$client->request(Zend_Http_Client::HEAD); // HTTP HEAD request

However, today, on my Ubuntu box I had real problems as HTTP client constantly ended in segmentation fault (SIGTERM in apache logs). When debugging, I noticed that it does so only if $uri contains so called “unwise” characters, such as spaces, “{“, “}”, “^” etc.

Going deeper, I reviewed the source code of Zend_Http_Client::setUri($uri) method, only to discover that it relies on Zend_Uri::factory($uri), to initialize the URLs. From there it was pretty simple. Zend_Uri is aware of “unwise” chars problem and disallows them by default (why exception thrown by Zend_Uri ended in SIGTERM is yet to discover, however). In order to allow such a characters:

Zend_Uri::setConfig(array('allow_unwise' => true));
$client = new Zend_Http_Client($uri); // $uri may contain unwise chars now

After issuing above instruction Zend_Uri accepts those unwisely formed URIs. Plus, you have to URL-encode white-spaces (i.e. make sure that white-spaces in query string, or actually in URI part after the host name are replaced with “%20″ char) to make them acceptable.

Further info available in offical documentation.

Please note, that I still think that having unreliable chars in URI is really bad practice. If you work with some system that already gone far on this path, it’s nice to have a method to actually consume such a wildly formed URIs. Kudos to Zend_Uri maintainers!

I have used ZF in several projects, and think is is quite safe to use svn:externals to attach Zend and ZendX as external dependency. It might not be the good idea for other projects, but when it comes to ZF – what is in trunk is pretty stable.

So, go into folder which stores ZF, and safely remove the library. Then just add ZF as external dependency (which would be updated every time you update the working copy):

svn pe svn:externals .

in and editor opened, enter the dependencies:

Zend http://framework.zend.com/svn/framework/standard/trunk/library/Zend
ZendX http://framework.zend.com/svn/framework/extras/trunk/library/ZendX

finally commit everything and obtain.

svn ci -m 'ZF set as external dep'
svn up

The beauty of this approach – you always have up to date version of ZF.
The danger of this approach – you always have up to date version of ZF!

Word of caution:
Sometimes this may break things (when backward-compatibility is broken in ZF trunk), but actually if you have unit tests which check your build before deploying, you are pretty safe – you spot the problem, you resolve it.

NB: This approach supposes that you tag your releases, so that when new release is coming out, you create a tag, export everything into newly created tag (thus freezing the code), and checkout from tag on production server.

It all started when I decided to optimize image slicing algorithm for a new feature on UMapper – and since GD is quite RAM-intensive, I needed to check actual memory consumption, and the obvious choice to do so was PHP’s memory_get_usage() function. However, it failed to produce accurate results – it seemed like images loaded into memory weren’t accounted by the function (RAM was still used ).
As it turned out, whoever prepared official php5-gd package, compiles against original GD, and not using PHP5 bundled version of the library. I actually wasn’t aware about the fork, but here is explanation from GD Official Site:

The PHP version of gd offers features similar to and sometimes in addition to those included in the latest version of gd found here as well as many bug fixes not present in the latest GD release. If you are working with PHP, using the built-in gd of PHP 4.3.0 or better is recommended.

We are working to merge the changes done in the PHP GD in the normal GD library.

Well, I was pretty sure that unexpected behavior was caused by using original GD library instead of bundled one. So I decided to remove php5-gd package, recompile php5 from sources, and install updated GD package – which is exactly what gets bundled with PHP5 on other distributions.

Google is my friend, so here is a walkthrough:

# Install build tools, debian helpers and fakeroot
apt-get install build-essential debhelper fakeroot
# Get PHP source (it should go into /usr/src)
cd /usr/src
apt-get source php5
# Install all packages required to build PHP5
apt-get build-dep php5

#Now what we need is to update compile options,
# so we need to edit debian/rules file:
cd php5-5.2.6.dfsg.1
vim debian/rules
# locate the line having "--with-gd=shared,/usr --enable-gd-native-ttf \"
# replace with "--with-gd=shared --enable-gd-native-ttf \"
# that's remove reference to /usr so that bundled library is used

# compile (drink some coffee, walk you dog, see the latest House episode)
dpkg-buildpackage -rfakeroot

# install the new php5-gd package
cd ..
dpkg -i php5-gd_5.2.6.dfsg.1-3ubuntu4.2_i386.deb

# finally restart apache
/etc/init.d/apache2 restart

That’s it – you should be able to see “bundled” near the GD version in the phpinfo() output. Well, that’s not the only gain – it solves problem with memory_get_usage() as well

Now, once I had memory_get_usage() working correctly, back to optimization..

Note: this is really a how-to, w/o any in-depth explanation, just a note to myself.

Today, I needed to add SSL support to UMapper.com application running on my Slackware localhost. We use CA-signed certificates on our server, but for local box self-signed was quite enough (all I need is to be able to view development version of site via https). Here what I did:

1. Create private key:

$ openssl genrsa -out localhost.key 1024

2. Generate CSR (Certificate Signing Request):

$ openssl req -new -key localhost.key -out localhost.csr

3. Generate certificate:

$ openssl x509 -req -days 365 -in localhost.csr \
        -signkey localhost.key -out localhost.crt

4. Make sure SSL is enabled in httpd.conf:

# Following two should be uncommented
LoadModule ssl_module lib/httpd/modules/mod_ssl.so
Include /etc/httpd/extra/httpd-ssl.conf

5. Edit httpd-ssl.conf so that virtual host users your created certificate:

# locate and edit cert.details. Make sure localhost.crt and localhost.key
# are present (you either created them there or copied)
SSLCertificateFile "/etc/httpd/certs/localhost.crt"
SSLCertificateKeyFile "/etc/httpd/certs/localhost.key"

6. Restart apache:

$ apachectl restart

That’s it. Please note that browser would still generate exception (and it is a good thing, as otherwise certificates wouldn’t be that useful). All you need is to add your localhost as exception – since we really trust that details we provided during certificate creation are our own

P.S. If you are getting “[warn] _default_ VirtualHost overlap on port 443,
the first has precedence”, add NameVirtualHost *:443 into your httpd.conf

I have finally completed proposal for Authorize.net CIM API. Hopefully, this API gets included into ZF (in one form or another), as ANet is one of the best services to work with user payment profiles, let alone CC processing. On proposal page you can review use cases, and if you are interested in internals feel free to download fully-working component’s prototype (it is still a prototype as most probably it would be updated in accordance with peer review on ZF wiki).

Let me know your suggestions on how the component can be improved.

This seems kind of limitation to me, indeed, if you use __toString() magic method for anything other than simple object variables concatenation, your code should be able to throw exceptions. Consider you have an object that generates XML as output, and you decide to provide even nicer interface, so that anyone using it in string context to get access to that XML. XML generation might not go well, and the obvious way to let the client know about this is to throw an exception. However, this is not possible (most probably due to some internal architecture limitations – as I honestly see no reason why this ideologically wrong).

One (not quite pretty) way to still provide some feedback from __toString() is using trigger_error:

public function  __toString()
{
    try {
        $output = $this->generateXml();
        return $output;
    } catch(Exception $e) {
        trigger_error($e->getMessage(), E_USER_ERROR);
        return '';
    }
}

If you know of a better option, let me know!

Starting with PHP5 almost any PHP installation contained SPL (Standard PHP Library) extension – with few exceptions, when hosters intentionally disabled it. With PHP 5.3 out, this extension is considered to be within PHP core, and as such it’s not possible to disable it anymore. This in fact is a good thing, as SPL really deserves to be the core component.

In an attempt to shed some light on and to draw attention to SPL, I plan to post several articles discussing various parts of this extension. I will start with SPL Interfaces so that you can grasp immediately the usefulness of the SPL.

Comprehending SPL interfaces presupposes that you know standard interfaces that come build-in with PHP5. So, I wrote preliminary article discussing them – I consider it to be a prerequisite for good understanding of the current material.

Covered in this article:

• The Countable Interface
• The OuterIterator Interface
• The SeekableIterator Interface
• The RecursiveIterator Interface
• The SplObserver and SplSubject Interfaces

Read the rest of this entry

Today, I wanted to import quite a huge sql-dump, and got this error. What I was using was:

mysql --user=root -p dbName < sqlDumpName.sql

I was pretty sure about dump's integrity, so after receiving "Error 1064" decided to import using source command:

#mysql --user -p
mysql>use dbName;
mysql>source ./sqlDumpName.sql

This time import went through w/o any issues.