php

I’ve just released a minor update to Yak, fixing a problem found with the products page.

Download it here.

I’ve just released YAK version 1.1.1 (although it won’t show up on the WordPress site for a while).

This release includes the following changes:

• “Hard-code” the PayPal IPN page. This means you don’t need to create it manually. Instead just specify: http://yourdomain.com/wordpress/wp-content/plugins/yak-for-wordpress/yak-paypal-ipn.php
• Add Italian translation, provided by Roberto Mogliotti.
• Change the download message to use the tag [downloads] rather than a code.
• Change the email confirmation message to use tags rather than codes.
• Fix a nasty problem zeroing price and alternate title when commenting on a product.
• Fix a problem with the random order number.

I’ve also removed support for the old tags (the html comment form such as <!−−yak_buy−−>), so you’ll need to change your posts to use square brackets if you upgrade (e.g.

As usual, this release has only been fully tested by… well, me… so there may be some bugs I’ve missed — if you find something, please post on the Bugs page or email me directly.

I’m experiencing a rather annoying technical problem, which is holding up the YAK release — and consequently the release of the YAK Handbook.

Google Checkout integration requires https, but when testing I’m currently getting the dreaded error:

Protocol https not supported or disabled in libcurl

This despite the fact that curl -V gives:

curl 7.18.2 (i386-apple-darwin9.4.0) libcurl/7.18.2 OpenSSL/0.9.8h zlib/1.2.3
Protocols: tftp ftp telnet dict http file https ftps
Features: Largefile NTLM SSL libz

And port installed gives the following output (excerpted):

curl @7.18.2_0+ssl (active)
curl-ca-bundle @7.18.2_0 (active)
lighttpd @1.4.19_0 (active)
mysql5 @5.0.51a_0+server (active)
php5 @5.2.6_1+fastcgi+macosx+mysql5 (active)

I’m obviously missing something, but no idea what. Hoping that any Mac gurus who happen to come across this might have a suggestion or two…?

I’ve just released a bug fix (version 1.0.3e) for the stable version of YAK. This fixes the bug where prices are cleared if a customer submits a review (by commenting on a product).

If you’re using 1.0.3d, I recommend you upgrade immediately.

The experimental release (1.1.0-exp) is still unpatched, and will be replaced by version 1.1.1 in a few days.

There’s a nasty bug in the latest version(s) of YAK. It’s definitely present in 1.1.0-experimental and probably in 1.0.3d as well. Basically if you have comments enabled on products, and someone adds a comment, it can wipe the prices.

It’s fixed in trunk (in source control), and I’ll be releasing an updated 1.1.1 version shortly which includes the fix. I’ll also be releasing a patched version of 1.0.3d just in case people don’t want to upgrade to the latest and greatest.

In the meantime, if you’re running either of those versions, I recommend you disable comments on those products for the moment.

I’ve decided to release 1.1.0 of YAK for Wordpress as an “experimental” version. It hasn’t been fully tested yet, but enough people are hanging out for some of the features that I hope a few early adopters might kindly help out with the process.

1.1.0-exp includes features from the not (publically) released 1.0.4:

1. Add new non-unique order id
2. Move javascript on cart off page and into separate script. split javascript into generic and admin specific files — to stop problems with (missing) jquery on the wp pages.
3. Add warning message for people with session.auto_start turned on.
4. Integrate YAK back into the WordPress menu structure. The top-level menu was a nice idea, but it’s inconsistent with all other plugins (plus isn’t recommended, according to the WP devs). You can now get to YAK’s options through Settings->Yak, and to Orders/Products/Sales Reports from the Manage menu.
5. Fix PHP4 problem with the view products screen

Along with a few additional features:

1. Add https support
2. Add first cut of Google Checkout integration.
3. Tidy up setting payment types (drop downs now rather than input boxes). Add setting of a credit card landing page.
4. Add support for tags with square brackets [ ]. The html-comment version of tags will be removed in an upcoming release

Google support is minimal so far. It’s one-way integration at the moment (allowing customers to submit an order through Google Checkout) — with no automated return path for handling purchase. That will come with a later release.

These updates hopefully make configuration a lot more user-friendly — particularly the changes to the Payment Types. Note that if you decide to upgrade, please make sure you backup your installation, and you double-check all your configuration options after upgrading.

YAK version 1.1.0-experimental can be downloaded from the WordPress Extend site.

YAK 1.0.3d has been released (the WordPress plugin page hasn’t updated yet, but the files are currently available from Sourceforge).

Please backup your existing installation before upgrading. Deactivate, remove the current yak-for-wordpress directory, then copy the new version into the plugins dir and re-activate. You’ll need to double-check the configuration settings, because many input boxes have changed to drop-down selects (for category and page selection for example… see below). This upgrade will also require you to go through your products and set the price in the “YAK Product Details” tab (see point 5 in the changes below) — the custom fields are no longer required.

This release includes the following bug fixes:

1. Problem with table creation.
2. Country options not saving properly.
3. Fix an odd problem with globals.
4. The return URL appears to be broken with PayPal IPN. PDT works fine, but IPN seems to wind up back at the home page of the blog. Added a fix to cleanup the order from the shopping cart when this happens.

And the following changes:

1. Frank Malina’s new look-and-feel.
2. French translation (provided by Charles Dixon-Spain).
3. Change money format and currency format to be simpler drop down boxes.
4. Change the download url from the settings screen so it is now an override (i.e. optional).
5. Add new data input on the post/page edit screen for yak price and title (replacing the old method of using custom fields).
6. Remove the “Auto Set Price” option (doesn’t make a huge amount of sense now).
7. Fix the Auto Set Quantity so it works with selected categories.
8. Tidy up the stylesheet.
9. Add a hidden link to the checkout and to the buy button form — vain hope that this might drive more search engine traffic to the YAK plugin page — if you don’t want the link included, it can be switched off on the Basic settings page.
10. Change the product category (settings page) from an input box to a dropdown.
11. Change the redirect on buy (setting page) from an input box to a dropdown.
12. Change the return and cancel urls on the PayPal settings page to a dropdown so you can select a page rather than having to type a url.

The latest YAK release is slightly delayed because I’ve, thus far, been completely unable to test PayPal integration.

First problem: The return URL doesn’t appear to work (cancel return URL works fine). PayPal keeps sending me back to the index page of my test site.

Second problem: When trying to save the Website Payment Preferences (in PayPal Profile) I get a “Page Not Found” error. So there’s no way to change between IPN and PDT. This has been broken now for at least 5 days.

If anyone is using YAK and PayPal and is willing (and able) to test both IPN and PDT integration, please let me know. Worst case scenario, I’ll release this version as unstable, and wait for PayPal to fix their problems…

UPDATE: Problem solved. PayPal have updated their site, but this has somehow corrupted old test accounts. Deleting the old account and creating a new one fixes the problem.

Interestingly, there doesn’t seem to be a WordPress Community group on LinkedIn.

Or, possibly, there are dozens. There’s no way to tell since LinkedIn’s Group directory isn’t open and also isn’t searchable. Unless you’re lucky enough to find the relevant group on someone’s profile, you’re stuck with creating your own.

So that’s what I’ve done. If anyone is interested in joining, the invitation link is in the groups section of my profile.

And let’s hope LinkedIn develops a really good ratification process for merging millions of one-member groups…

It’s been over 2 years since I released YAK for WordPress (6th of March, 2006 according to Sourceforge), and the forthcoming release finally starts to tidy up a few loose ends. It was always a bit hacky — from a user interface perspective, that is — and 1.0.3 sorts out a few of the most obvious problems (this is not to say it’ll be perfect, of course).

YAK has always represented a reasonably significant investment in time. I don’t put a huge amount of effort into development now that it’s hit the 1.0 release, but popularity brings an inevitable increase in the number of calls for support.
Family commitments mean that I have less time available — or at the very least, it’s harder to justify spending the time. The obvious answer, suggested by a couple of people, is to commercialise (at least in part) the plugin.

There are plenty of open source projects which have at least a small commercial component. And plenty more which are mainly commercial, but release unsupported open source versions. An example of the former are projects which have paid-for documentation. An example of the latter would be something like JBoss or MySQL, which release community and enterprise versions of their apps — the enterprise version, rather obviously, providing commercial support.

So this brings me to a question: where to, with a semi-commercial version of YAK?

There are a few options on the table:

1. Reduce the detail of the online documentation and release a paid-for installation manual.
2. Release a supported, commercial version of the plugin with the latest features, and the open source version (with those features) would follow a few months later (only the commercial version would be supported).
3. Per-request charge for support, perhaps based upon the time taken.

What do you think? Any better ideas?

If anyone is interested in previewing YAK 1.0.3, please get in contact. This release adds a new (admin) UI design (provided by Frank Malina), and fixes a couple of nasty bugs that emerged with the latest version of WP (tables not being created, globals not working as they used to, etc).

Apart from the new UI, there are no major feature improvements in this release, however there are a couple of “big ticket items” I’m thinking about adding in version 1.0.4.

Yet another release of YAK — this one fixes a problem with activation. Basically the db tables weren’t being created on a new activation (i.e. the first time it’s installed). This wouldn’t have affected upgraders.

Apologies to anyone who had problems, and hopefully this release will work better.

Version 1.0.2 of YAK has been released.

This version is a slightly more involved upgrade than previous editions. Because WordPress’s automated build system creates a distribution from the subversion repository, the directory in the filename isn’t just “yak” — it’s “yak-for-wordpress”. This appears to cause problems when I’ve named my main plugin file: “yak.php”. As a consequence, the new name is “yak-for-wordpress.php”.

Thus, before upgrading, you should backup your wordpress installation, then deactivate and remove the old yak directory. Extract the contents of the new distribution and re-activate.

Changes in this release are included in the release notes here, but to summarise:

1. order status is automatically set to STOCK SENT when all funds have been received for a PayPal order, if the order contains only downloadable items
2. the ‘default’ category has been removed from the products drop down. This means you can still turn the drop-down on by default for products with more than one option, and the products that are tagged as ‘default’, won’t include the dropdown.
3. fixed a problem with apostrophes in yak title, download and confirmation email
4. fixed a problem with PayPal shipping with multiple items
5. fixed a problem with PayPal verification (item names need to be properly encoded)
6. tidied up the confirmation email and code

Any problems with this release, please let me know.

YAK version 1.0.1 has now been released. Downloadable from either the WordPress plugins page, or from Sourceforge. This updates YAK to be compatible with WordPress 2.3, but unfortunately breaks backwards compatibility with prior versions of WP. If you’re using an older WordPress, I’m afraid you’ll have to stick with 1.0.

As well as WP2.3 compatibility, 1.0.1 adds paging to the “products” page, adds a facility to select the countries you support (see the options page), and adds a new quantity tag () to display product availability to your customers.

Seen a few complaints about the replacement of Technorati incoming links by Google’s blogsearch. I can sympathize, since my list of external incoming links has been replaced by a bunch of links from my own site. Useless.

Anyway, as seen here, you can set it back… although I’m not sure his her instructions were clear enough. Either that or there’s a slight difference between the release candidate and the final release.

So for those who don’t have php coding skills, but still want the return of their Technorati links, download this zip file, unzip index-extra.php inside and copy to the wp-admin directory of your WP install. Probably best to take a copy of the current one, just in case. I’ve only tested with the just-released WP2.3, so use at your own risk, etc, etc, etc.

YAK, for Wordpress 2.3, is on its way.

There are structural database changes required for WP2.3, and while I don’t necessarily need to change the YAK tables as a consequence, I do need to change a few (relatively complicated) SQL statements. So if anyone has a test environment and would like to help, it would be great if someone (other than me) can check whether or not the changes have been completely successful.
I can package up the current tip of the repository and email out to those interested.

Please note that I’ve made the decision not to support older versions of WP (i.e. versions less than 2.3) from this point on, as supporting different versions of a database makes development inordinately complicated. That said, if you won’t (or can’t) upgrade to the latest version of Wordpress, and have some essential feature that you want in YAK, feel free to cross my palms with (quantities of) silver and I’d be happy to help.

The only other change that goes into this release is the support for paging in the YAK products page. This is the product list page (using the tag <!–yak_product_page–> tag) where your users can see all your current products (in order of newest to oldest). I’m only aware of one person actually using this feature, so for most, the only thing of interest in this coming release is the 2.3 support. More to come when I have the time.

I’ve just had another contribution to the version of php_spread I used for my article about LAMP and Spread usage.

Thanks to Christoph Dorn for the contribution of a package that works on Mac OS X. Check the phpspread page here for a link to the zip file.

I’m just in the process of releasing an experimental version (0.9) of YAK which showcases the latest features, such as product options, removing the need for exec-php, a credit card payment form, and a few other requested changes.

This release should be viewed as -highly- experimental. If you release it into a production system, you are, quite frankly, raving bonkers and should be committed to the nearest psychiatric institution.

That said, hopefully someone will have a test system that they don’t mind trashing, and get back to me with some feedback. Check the main YAK page and you’ll note that the way you use the plugin has changed (using html comment placeholders instead of php function calls using exec-php), so upgrading will unfortunately be a time-consuming process. WARNING: documentation may not be quite as comprehensive as I’d like.

The next stable release of YAK to include this functionality will be the 1.0 release, but is unlikely to be out before Christmas, because I need more time to fully test the new features.

I’ve been doing a bit of work on YAK recently. A couple of bug fixes — one major fix to support people who don’t have curl installed (uses fsockopen instead). The major changes on their way are:

• order cancellation — reversing the quantity decrement that takes place during ordering
• new order page with summary info and then a detail button to display more data
• credit card payment page — for shops who are processing their own credit card payments (this also blanks out the credit card number when an order is cancelled or stock is sent, reducing the security risk)
• product options — in other words, styles/colours and/or sizes. I’m currently investigating this and haven’t quite come up with a way that keeps things simple enough. Obviously quantities for the options will have to be kept in sync which makes the products page more complicated, not to mention the ordering process.

Everything except for product options is currently in subversion (use the repository version at your own risk since I haven’t done enough testing yet).

One of the more useful aspects of WordPress is its extensibility. It makes WP a powerful container for all sorts of applications.

I’m currently working on a WP-based project that requires access control of pages based upon a user’s roles, so I’ve come up with a simple plugin for providing this functionality (download here).

To use, install and activate the plugin. To secure a page, add a custom field “acl”, with the value set to a comma-separated list of roles (for example, “administrator,subscriber”). If the user is not logged in, or does not have one of those roles, they’ll see an access-denied message. The plugin will probably be more useful if coupled with Redalt’s RoleManager.

NOTE: considering this is in the very early stages of development, use at your own risk.

Rather painful bug in my wordpress plugin, YAK:

Allowed memory size of 8388608 bytes exhausted (tried to allocate 21 bytes

I understand what it means, but I don’t understand why it’s happening. As far as I can tell, I’m not allocating any large datasets — and the error only appears when I click the WP dashboard. I went through and commented out the entire core script, then uncommented bit by bit until it fell over. Then commented that function again, and uncommented the functions following it and the problem reappeared — which implies it’s something to do with the amount of functions/code I’m creating rather than what I’m doing in those functions (I think).

The short term fix is the following line in the beginning of the script yak.php:

ini_set("memory_limit", "10M");

Which unfortunately is treating the symptoms, and not the cause…

A couple of evenings hacking around with PHP extensions has reminded me exactly why I stopped doing C programming.

I’m trying to get an extension (which I’m interested in using), to compile and then to actually work — which is proving a challenge. In an attempt to figure out exactly where I’m going wrong, I’ve simplified the build process I documented here.

The following is based on a Codewalkers tutorial — modified to run in my environment (thus your mileage may vary).

The module source is:

#include "php.h"
#include "php_globals.h"
#include "ext/standard/php_string.h"

PHP_FUNCTION(mytest1);

static function_entry firstmod_functions[] = {
    PHP_FE(mytest1, NULL)
{NULL, NULL, NULL}
};

/* compiled module information */
zend_module_entry firstmod_module_entry = {
    #if ZEND_MODULE_API_NO >= 20010901
    STANDARD_MODULE_HEADER,
    #endif
    "First Module",
    firstmod_functions,
    NULL,
    NULL,
    NULL,
    NULL,
    NULL,
    #if ZEND_MODULE_API_NO >= 20010901
    "0.1",
    #endif
    STANDARD_MODULE_PROPERTIES
};

ZEND_GET_MODULE(firstmod)

PHP_FUNCTION(mytest1) {
    RETURN_STRING("Hello World version 2", 1);
}

To build, issue the following commands (you may need to change the include paths to point to your php installation):

cc -fPIC -DPIC -DCOMPILE_DL=1 -I/usr/local/include -I.  -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/Zend -I/usr/include/php5/TSRM -I/usr/include/php5/ext -c -o first_module.o first_module.c

cc -shared -L/usr/local/lib -export-dynamic -avoid-version -rdynamic -o first_module.so first_module.o

Copy first_module.so to your php extensions lib dir, add to the ini file, and hopefully it should work.

Zend has a darn useful tutorial on creating php extensions. After a few false starts, I’ve managed to get something working, so I’m documenting my steps here for my own future reference.

Note 1: this is specific to my Kubuntu installation.
Note 2: I’m basically refactoring Zend’s hello world example to “mytest”… just because I can.

1. create a directory for the extension. In my case I’m creating a dir “mytest” in my homedir.

2. create a phpize configuration file (config.m4) in the mytest dir:

PHP_ARG_ENABLE(mytest, whether to enable mytest support,
[ --enable-mytest   Enable mytest support])

if test "$PHP_MYTEST" = "yes"; then
  AC_DEFINE(HAVE_MYTEST, 1, [Whether you have mytest])
  PHP_NEW_EXTENSION(mytest, mytest.c, $ext_shared)
fi

3. create the header file (php_mytest.h):

#ifndef PHP_MYTEST_H
#define PHP_MYTEST_H 1

#define PHP_MYTEST_VERSION "1.0"
#define PHP_MYTEST_EXTNAME "mytest"

PHP_FUNCTION(mytest);

extern zend_module_entry mytest_module_entry;
#define phpext_mytest_ptr &mytest_module_entry

#endif

4. Create the C file (mytest.c):

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include "php.h"
#include "php_mytest.h"

static function_entry mytest_functions[] = {
PHP_FE(mytest, NULL) {
NULL, NULL, NULL}
};

zend_module_entry mytest_module_entry = {
#if ZEND_MODULE_API_NO >= 20010901
STANDARD_MODULE_HEADER,
#endif
PHP_MYTEST_EXTNAME,
mytest_functions,
NULL,
NULL,
NULL,
NULL,
NULL,
#if ZEND_MODULE_API_NO >= 20010901
PHP_MYTEST_VERSION,
#endif
STANDARD_MODULE_PROPERTIES
};

#ifdef COMPILE_DL_MYTEST
ZEND_GET_MODULE(mytest)
#endif
PHP_FUNCTION(mytest) {
RETURN_STRING("Hello World", 1);
}

5. run the command phpize to create the configure and make scripts (and associated gumpf) — you’ll have to install php5-dev if you haven’t already:

apt-get install php5-dev

6. configure, then make the module:

 ./configure --enable-mytest
make

7. copy the extension to your extensions dir (which is defined in /etc/php5/apache/php.ini — or in my case it doesn’t seem to be, but nonetheless appears to be the directory: /usr/lib/php5/20051025)

8. add a directive for the shared object to the php.ini file. In this case:

extension=mytest.so

9. restart apache

10. create a php script:

<?php
echo mytest();
?>

11. Point your browser at it, and hopefully you should see “Hello World”.

Which is nowhere near as painful as I thought it was going to be. Result!

I’ve just released v0.7 of my shopping cart plugin for WordPress. Notable inclusions in this release are automatic setup of product info (such as quantity and price), and the ability to have downloadable products — which is in the ‘experimental stage’ (see here for more information).

Currently in source control for YAK (but not released yet), is the ability to automatically set price and quantity for all new posts — meaning one has to explicity remove the custom fields to stop a post being considered as a product. This is optional behaviour, of course.

Also added is default titles for products (picking up the post title, rather than having to explicity enter it). Which is one less custom field to enter.

I’ve had a couple of requests to support downloadable content. There are a few ways I could go about adding this feature — none of which are particularly straightforward. I don’t want to overly complicate the shopping cart, and a couple of methods would definitely result in overcomplication. At the moment my favoured approach would be when a user purchases downloadable content, an email is sent out with links for the downloads once payment is confirmed (either thru PayPal, or manually in the manage-orders screen). The link for the download would (potentially) be created using a combination of the product id, a uniquely generated id, and a passcode created specifically for the product… with the number of downloads allowed configurable from within YAK. This is perhaps not as user-friendly as providing download access from within the cart itself (i.e. payment confirmation redirects to a page which contains your download links) — but has the least (developmental) impact on the plugin.
I’d also like to add the ability to upload the content from within the plugin as well — but I think the initial version will just be via an .htpasswd/.htaccess secured directory.

So, comments welcome. Should this facility go into YAK now, or are there other features which you’d like to give a higher priority…?

With a considerable number of minor annoyances, I’ve managed to get PayPal integrated into YAK. Or at least I think I have.

Problems included the fact that credit cards just stopped working at one point (in order to get a credit card number to test with, you just “add” one from within the sandbox and it autogenerates a credit card number which you can use while pretending to be an ‘unregistered’ user). Another irritation was that I was forced to re-authenticate every time I ‘added’ a credit card; and when those credit card numbers stopped working altogether — major aggravation.

Instant Payment Notification also seemed flaky. For a while it was my own fault (dodgy code) — but after I’d resolved my problems, I’m sure I still lost IPNs.

In any case, at least I have an experimental version working. Time (i.e. testing) will tell if it’s actually doing what it’s supposed to — and whether it works for anyone else. The code needs a serious tidy-up… but then, it’s PHP. When does PHP code ever look tidy…?

There are a number of online payment providers offering alternatives to PayPal, but superficial examination highlights issues with most of them:

WorldPay — it seems like integration with WorldPay’s backend would be more straightforward than PayPal, since they use a simple form+token approach. But their pricing (at least what I’ve been able to find out about it) perhaps puts it out of the target market for my little shopping cart.

BidPay — (was) apparently the closest competitor to PayPal, but was apparently purchased by CyberSource and has been shutdown temporarily.

BitPass — again possibly a simpler task of integration (of course, only based on superficial investigation), but appears to be targeted toward digital content, rather than products so I think not generic enough for a… generic… shopping cart.

Of the others I’ve found, they all present significant barriers to adoption (lack of documentation, requiring customer account registration, etc).

Back to the drawing board…

UPDATE:
PayPal also offer an HTML form-based ordering system with their “standard checkout” — I did read that before, but somehow managed to miss it this time around (so much for only one stupid moment per day). Hopefully it may provide an alternative to their ghastly SOAP interfacing.

I was about to post a scathing critique of PayPal’s API services (and documentation), but at the last minute discovered I was being a major dumbass, and deleted the post about 2 minutes after publishing… phew. I’d missed a couple of obvious points — which I shouldn’t have. I plead end-of-day tiredness as an excuse.

However, a day later, I’ve swung back to thinking critical thoughts once again. Like the fact that the documentation was either written by a numpty or, was otherwise written in plain english, then obfuscated into incomprehensibility, for some bizarre reason beyond my ability to grasp.

I mean, apart from yesterday’s abrupt onset of presenile dementia, I’m usually not this stupid (okay, that’s a lie — but my stupid moments are usually restricted to one per day, and I think I’ve already used my daily allowance). Pot calling kettle black, since I’m not exactly the poster boy for brilliant project documentation, but this stuff is hardly what one might call “comprehensive”. I keep thinking, “there must be an end-to-end tutorial (including examples) somewhere”… and I keep not finding it…

UPDATE #1:
It’s good to know I’m -not- the only one beating my head against the PayPal wall…

UPDATE #2:
And also evidence here.

My php shopping cart for WordPress has (almost) been released. I had a sudden change of heart over the name, and decided on YAK instead — bbshop being far to pedestrian (in case anyone is wondering, YAK stands for Yet Another Kart, obviously modifying the English language to suit my own purposes… |-). So I’m currently copying over bits and pieces from the original sourceforge project (not a huge effort, but complicated by interruptions from 3-year old), and trying to get it into some sort of state where it makes sense if anyone tries to -actually- use it.

At the moment there is only one user, and even they aren’t using it in production yet, so mileage may vary. So should anyone try it out and manage to get it going, I’d be keen to hear…..

….and I suppose I would also been keen to hear if anyone tries it out and doesn’t manage to get it going…

Speaking of PHP, I wrote my first ‘proper’ (well sort of) PHP application only a month or so ago. I’ve had to modify (i.e. hack) a few applications in the past, but this was the first time I’d sat down with a blank slate, so to speak.

And, of course, what I wound up writing was the ubiquitous shopping cart — a function sure to elicit little excitement and a large number of yawns.

In this case, my app is a plugin for Wordpress — allowing a WP post to be associated with a product (i.e. product per post), assigning values such as price, quantity and product title to that post, and then using sessions to store the information in the cart (actual orders are, of course, stored in the database). It seems that while the number of examples of shopping carts in various languages is approaching infinite, there are only a few related plugins available for Wordpress (a google search for “wordpress shopping cart” comes up with a measly 520,000 items ;-). Interestingly, one of the few I came across was created by an NZ company (or person) — however, none of the plugins I found really satisfied my needs. Hence the creation of yet another shopping cart.

I’ve been twiddling my thumbs for the last week or 2 waiting for sourceforge to approve the project, only to discover it’s been created, but my notification has gone astray.

(Note: Nothing there yet, but there will be)

Good follow-up coverage by Tim on his PHP post (seriously impressed by the way he gathers together a snapshot of some of the general discussion — and surprised/pleased to be included…

Just to clarify my own thinking somewhat; coming from a pro-Java camp, I was originally anti PHP. But then, admittedly, I had a chip on my shoulder about languages other than Java anyway. That chip still manifests on occasion, but I’d like to think/hope I’m becoming more language agnostic — taking a leaf from the Pragmatic Programmers and choosing the right tool for the job, with a variety of tools in my toolbox. Which is why I now see a lot of value in languages like Python (in particular), Jython, and PHP (on occasion); got over my dislike of Javascript, and even scraped off enough dust to do (very infrequently) a bit of C coding (extra emphasis on infrequent).

Zealous adherence to a single paradigm seems very last century…… Which would, of course, be the right time to point out my zealous adherence to a single platform….

In a recent post about PHP, Tim Bray mentions PHP’s upsides:

…it’s written for the web, it’s easy to deploy and get running, and it’s pretty fast.

“Pretty fast”, in my opinion, is an understatement. I was working on a (Java-based) messaging gateway a few years ago — not massive loads like you’d get in the US, Europe or Asia, but pretty impressive for this neck of the woods. My app was intended for messages with more complicated & dynamic workflow, while a colleague was working on a simpler PHP system, for raw throughput, where the logic was fixed, and less complicated. My recollection was that even for simple processing, I was never able to push the throughput higher than about 180 messages per second on the (single) target server. That was with the best examples I was able to find on java nio, a lot of profiling, load testing, optimisation (where it made sense), and comparison of different approaches (nio, standard sockets, alternate libraries, etc). On the other hand, my colleague’s application was about 10-20% faster almost without him trying and I recall the final result being close to 40% faster once he’d figured out the best way to do it.

Okay the goals were different, my app inherited a lot of overhead by providing more functionality, but it was still an eye opener at the time. Under the right conditions (and for certain purposes) PHP is more than just “pretty fast”. A better adjective is “blistering”…

(Small print: I still prefer Python…