blog.arithm

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), as well as the wp-content directory itself. The “upgrade automatically” links should now work without kicking you to the “Connection Information” screen.

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.

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.

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')))
                mb_internal_encoding('UTF-8');
}

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

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]
apc
ctype
...
wbxml
xdebug
xml


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

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);
$log->addChild($logFile);
$log->addChild($logFire);


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
  Weird.
• 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.

It’s an Emacs weekend here at blog.arithm.

I was recently asked if it was possible to do remote PHP debugging with Emacs. We’re talking about Emacs, so the answer is:  Of course!  How to do it:

1. Grab Tohru Fujinaka’s GEBEN library.  It’s an aging alpha release, but works fairly well.
2. Make sure you also have CEDET installed.  I’m using the 1.0 pre4 release.
3. Drop debugclient somewhere in your path.  (Here Emacs is running on Windows, so I just threw it into the C:\WINDOWS\ directory.)  Make sure the executable is named “debugclient” and not “debugclient-0.9.0″ or whatever.
4. If you’re using the standard xdebug port 9,000 (recommended), make sure that port is open on your firewall.  For most folks these days that means opening up the default OS firewall as well as forwarding a port from the router.  See the exceptional portforward.com for more information on router port forwarding specifics.

Now, assuming you already have xdebug plugged into PHP, modify php.ini or an .htaccess file with the following settings:


• xdebug.remote_enable = true
• xdebug.remote_handler = dbgp
• xdebug.remote_host = your_client_ip

For security reasons it’s wiser to do this via .htaccess on directories that permit only authenticated access.

To debug, ask Emacs to listen for connections by going into GEBEN Mode with Meta-x geben. You should see “xdebug started.” in the status row at the bottom of the Emacs window.

Run your PHP script with the xdebug switch on, eg.

http://www.example.com/script.php?XDEBUG_SESSION_START

If everything is setup correctly, Emacs will load the source of script.php (be wary of security!) and allow you to step through the code.

Available commands are:

spc step into/step over
i   step into
o   step over
r   step out
b   set a breakpoint at a line
u   unset a breakpoint at a line
g   run
q   stop

Some gotchas: I’ve noticed the GEBEN expects the first keystroke to be “space”; often it will freeze otherwise.  GEBEN may also run into problems on certain session-related PHP commands.

Happy debugging!

In order to run Windows commands via PHP functions such as open_proc(), apparently one has to grant read/execute permissions to the account under which IIS is running (usually IUSR_<servername>) on C:\WINDOWS\System32\cmd.exe. Be sure to do this for web apps that rely on external commands.

This of course took me an eternity to figure out. I was only able to piece together WebSVN’s bizarre Windows mis-behavior after scouring through the remnants of forum posts limboed in Google cache. PHP.net of course has no proper details on this, though I do now better understand what proc_open’s obscure and undocumented bypass_shell parameter might be about.

Ah yes, PHP on Windows. Obscure and irritating.

Kind of like me. Not that that makes it any better.

Ugh. As usual, more weird problems while trying to upgrade PHP on a Windows box. Are we having fun yet?

If you find that the MySQL extension won’t load, then probably a previous PHP installer has placed a version of libmysql.dll somewhere else in your path. Look in c:\WINDOWS\system32\

The problem is almost certainly the reason for the following obscure comment

Although copying libmysql.dll to the Windows system directory also works (because the system directory is by default in the system’s PATH), it’s not recommended.

in the PHP MySQL documentation.

Make sure your home PHP directory is in your path, and that its finding libmysql.dll there and only there.