zend_mm_heap corrupted

Has Apache suddenly started telling you that the “zend_mm_heap” is corrupted? Rather than mucking around with output_buffering or other php.ini values as recommend in a couple of places, first check that, if you have a custom session manager (typically memcached), it is started and you are able to connect.

For example, if your session handling is setup as follows:

; Handler used to store/retrieve data.
; http://php.net/session.save-handler
;session.save_handler = files
session.save_handler = memcache
;session.save_path = "/tmp"
session.save_path = "tcp://localhost:11211?persistent=1&weight=1&timeout=1&retry_interval=15"

check to make sure that you can actually connect to localhost on port 11211:

$ telnet localhost 11211
Connected to localhost.localdomain.
Escape character is '^]'.
STAT pid 24041
STAT uptime 257289
STAT time 1321027200
STAT version 1.4.2

If you can’t connect, or the memcached server is not responding as above, then you’ve found the source of the “heap corruption”.

Fixing the Dubious Symfony Test Harness

Although Symfony’s original baked-in test framework, Lime, is being replaced by PHPUnit in Symfony 2, I figure I should post a fix for those, like me, who will be stuck for the foreseeable future in Symfony 1.x with an older suite of tests.

In general, Lime works pretty well except when running multiple tests in the harness. For example, when you run a specific test or tests:

$ ./symfony test-unit util
# isEmailValid()
ok 1 - returns an integer
ok 2 - test@test.com is a valid email address
ok 3 - test@test is not a valid email address

Lime plays along nicely. But when you run all of your tests via the test harness like so:

$ ./symfony test-unit
Test returned status 1
Test returned status 1

the results can be dubious.

“Dubious” here means that the test crashed somehow during execution and so Lime doesn’t know if it would have passed or failed. To see what’s going on, pop open symfony/vendor/lime/lime.php. Depending on your version, you should see a block like the following inside lime_harness->run():

ob_start(array($this, 'process_test_output'));
passthru(sprintf('%s -d html_errors=off -d open_basedir= -q "%s" 2>&1', $this->php_cli, $file), $return);

Never mind that the above passthu may not work on Windows (see ticket #5437), if you comment-out the output buffering and run your tests again, you’re likely to discover that Symfony can’t autoload Symfony libraries, base classes, or what-have-you; for example:

$ ./symfony test-unit
Fatal error: Class 'sfCore' not found in D:\app\test\unit\happyTest.php on line 8
Call Stack:
0.0004 70248 1. {main}() D:\app\test\unit\happyTest.php:0

The easiest fix is to work around this whole executing tests via passthru nonsense. A good old “include”, like Pake does when you run one test at-a-time, will do just fine. Patch lime.php:

ob_start(array($this, 'process_test_output'));
$return = include($file);

Then add a “return 0;” to the end of each of your tests. (Yes, the Lime harness expects zero to indicate success..)

Now the harness should run just fine:

$ ./symfony test-unit
All tests successful.
Files=2, Tests=10

Of course, this will break the harness for the functional tests, but that’s a fix for another post.

Defeating weird “No database selected [Native Error: MySQL server has gone away]” error when moving code into a partial in Symfony

So you’re working in an older version of Symfony (or maybe even a newer one..), trying to refactor some common code into a partial. Maybe something simple like this from within a global partial?:


And suddenly connections to the database start falling down with errors along the lines of:

SQLException: No database selected [Native Error: MySQL server has gone away]

In reality this is a problem with Symfony’s error reporting from within global partials. Do you actually mean?:


Remember that even if you’re in a global partial, Symfony doesn’t really know that’s where you are.

Get WordPress to stop asking for “Connection Information” when upgrading plugins

Recent versions of WordPress have taken a queue from Janis Elsts’ One Click Plugin Updater and made it *much* easier to keep plugins up-to-date without having to fire up FTP. The problem is that WP seems to use permissions of it’s script files to determine whether or not plugins and themes can be uploaded to the server or not. Really WP should be looking at the target directory rather than the executing script; consequently I assume most folks just assign web server ownership to the entire WP source tree. Which, frankly, kind of freaks me out security-wise.

If you’d also rather avoid recursively chown’ing the WordPress tree to your web server, then simply give web server ownership to three files in the wp-admin directory: plugin-install.php, plugins.php, and update.php. Of course the web server will also need to own the plugins directory (and everything therein), the upgrade directory, as well as the wp-content directory itself. The “upgrade automatically” links should now work without kicking you to the “Connection Information” screen.

Getting Flymake to work with Emacs nXhtml

If you develop in PHP on Emacs, then you’ve probably got a hook setup to run flymake-mode on PHP files. And if so, then you’ve also probably noticed that this doesn’t work with nXhtml, which will often return an error like “mumamo can’t find the file” (or some such), causing flymake-mode to disable itself.

The culprit is likely to be a bind like this:

(add-hook 'php-mode-hook (lambda () (flymake-mode t)))

which says, “turn on flymake-mode when php-mode is started”. (Sacha Chua has a post that recommends using this from couple of years back.) The problem, as far as I can tell, is that nXhtml tries to process the fleetingly available _flymake file rather than the original PHP script whenever it toggles into php-mode.

A better hook to use is the find-file-hook, like this:

(add-hook 'find-file-hook 'flymake-mode)

With this, Flymake will properly validate PHP chunks in nXhtml mode, as well as any other files that Flymake is smart enough to process.

Defeating the flymake configuration error in Emacs php-mode

Getting the following message when trying to use Flymake with PHP?:

“Flymake: Configuration error occurred while running. Flymake will be switch OFF”

This threw me, though it probably shouldn’t have. If you’re seeing it as well, double check two settings in your php.ini file:

1. The error_reporting setting needs to include E_PARSE. I personally like to use error_reporting = E_ALL | E_STRICT. This shows everything that the PHP compiler thinks you are doing wrong.

2. Also double check your php.ini file for display_errors = On. I almost always forget about this when setting up on a new box because I tend to override php.ini with .htaccess values.

Finally, triple check your command line php settings with a quick $ php -i, which dumps the content of phpinfo() to the command line.

Character encoding translation breaks when upgrading WordPress

Recent versions of WordPress like to second-guess the internal and external encodings used by mbstring when assembling data from the database and spitting it out to blog pages.  Probably this works fine for most, but if you have an older database storing text as something other then UTF-8, probably you have a custom chunk of mbstring configuration in an .htaccess file or similar; perhaps like this:

php_value output_buffering 1
php_value output_handler mb_output_handler
php_value mbstring.language Japanese
php_value mbstring.internal_encoding EUC-JP
php_value mbstring.http_input auto
php_value mbstring.http_output SJIS
php_value mbstring.encoding_translation 1

WordPress’s second-guessing will break this, resulting in a bunch of garbled posts. To fix, comment out this chunk of code in wp-settings.php:

 * In most cases the default internal encoding is latin1, which is of no use,
 * since we want to use the mb_ functions for utf-8 strings
if (function_exists('mb_internal_encoding')) {
        if (!@mb_internal_encoding(get_option('blog_charset')))

With this gone, WordPress will stop second-guessing and custom encoding translations should flow through just fine.

PHP Extension Trouble

Just seen in the wild on an old-ish Fedora distro.

This works:

extension_dir  = /usr/.../php/extensions/no-debug-non-zts-20060613
extension = apc.so
extension = wbxml.so

Quick check shows good…

$ php -m
[PHP Modules]

But this does not:

extension = /usr/.../php/extensions/no-debug-non-zts-20060613/apc.so
extension = /usr/.../php/extensions/no-debug-non-zts-20060613/wbxml.so

And yet Zend modules seem to always require a complete path; eg:

zend_extension = /usr/.../php/extensions/no-debug-non-zts-20060613/xdebug.so

Elegant PHP error logging in Firefox

Mika Tuupola has come up with an elegant logging mechanism that has already found its way into the official PEAR::Log package.

It’s a snap to use.  Simply instantiate a “Firebug” log as such:

$log = &Log::singleton('firebug', '', 'PHP', array('buffering' => true), PEAR_LOG_DEBUG);

Output will then go to your Firebug console window:

$log->log('Debug lorem ipsum.', PEAR_LOG_DEBUG);
$log->log('Info wisi enim ad minim veniam', PEAR_LOG_INFO);
$log->log('Warning est usus legentis in', PEAR_LOG_WARNING);
$log->log('Error est notare quam', PEAR_LOG_ERR);

To split output to both the default error log as well as the Firebug console, build a “composite” log:

$log = &Log::singleton('composite');
$logFile =& parent::singleton('error_log', PEAR_LOG_TYPE_SYSTEM, 'to error log', array(), PEAR_LOG_DEBUG);
$logFire =& parent::singleton('firebug', '', 'to firebug', array('buffering'=>true), PEAR_LOG_DEBUG);

Unscientific reviews of various (mostly PHP) web shopping carts

Some time back I did a review of various web shopping carts.  In particular I needed a cart into which we could integrate a minor, third-party payment processing system.  We also wanted something that had the following functionality:

  1. multi-currency
  2. multi-lingual
  3. registration management
  4. mailing list management

These are the carts that I found in the order they were discovered and reviewed.

APIs and Frameworks

Started on the assumption that we would want to build and manage our own shopping cart.  It quickly become apparent that a customizable stand-alone application would get us more functionality with less mucking around.

  • Webforce Cart
    Very simple shopping cart class.  After a quick review, decided that it would be better to use something inside a framework like Cake or Symfony.
  • sfShoppingCart
    Shopping cart module for Symfony.  Played around with this but quickly realized that, even in a framework, maintaining a custom cart would fairly troublesome for my simple needs.
  • phpShop
    Another simple, rails-esque cart.  Seems to be a framework built specifically for the shopping cart.  Would still probably use sfShoppingCart over this.
  • Quick.Cart
    Very nicely done, simple cart.  Installed and played around with it a bit.  Difficult to modify the layout; template updating problems.

Stand-Alone Applications
Lots and lots of apps out there.  I was surprised, however, to discover that many of them are branches of earlier code bases.

  • Nexternal Solutions “Ecommerce Shopping Cart”
    Aggressive Google advertising.  Ugly.  ASP-based.  No way.
  • osCommerce
    This has been around a long time; looked at this originally five years ago for another project.  Lots of web shops out there using osCommerce, but developers complain that it is difficult to integrate and maintain.   Admin interface looks like it needs work.
  • Zen Cart
    Fork of osCommerce and, now, possibly the most famous open source shopping cart solution.  Installed and mucked around with it.  Confusing, clumsy interface, though better than the osCommerce original.  Lots of complaints from developers.  Many recommend switching to CubeCart.
  • CRE Loaded
    Another Fork of osCommerce with a corporation behind it.   Nice marketing website.  Same poor admin interface.
  • osCMax
    Yet another fork of osCommerce with (maybe) Drupal integration.
  • xt:Commerce
    And yet another fork of osCommerce.  Corporate backing like CRE Loaded.  Seem to be pursuing global distribution; based out of Germany.  Spanish version on the way.
  • Miva Merchant
    Looks as though this might be the most “enterprise” of the shopping carts.  Starting price:  $995.00.  Pricey.
  • X-Cart
    Comparable to CubeCart but no free version.  Lots of complaints that cost of additional modules rapidly builds up.
  • AgoraCart
    Nasty green interface.
  • Squirrelcart
  • phpCart
    Looked great, but seems to have been replaced by PHP Super Cart which appears to be… even yet another fork of osCommerce.  Ugh.
  • CubeCart
    Good reviews.  Open source and very reasonable commercial models (one-time payment as opposed to recurring  licensing fees).   Easy to localize.  Good currency manager.  Stylesheet-based templates are a little awkward.  Very active development and fairly strong community support including skins and modules.

In the end we went with CubeCart.  So far it’s been “okay”.  Template organization is indeed haphazard; it can be difficult to figure out which templates apply to which step in the purchasing process.  Documentation is also fairly thin on the ground.  And though we paid for support, the replies that come back are fairly unsupportive.

Nevertheless, integrating the third party payment system was not too difficult.  I can recommend CubeCart.. with reservations.  Look around for your own alternatives and settle on this if it seems suitable.