Jonathan

Full disclosure Bryan, I’m the lead dev on Shopp, so I am biased ??

Shopp (shopplugin.net) can handle as many products as WordPress can posts, though I think the same could be said of the other solutions as well (WP e-commerce, Jigoshop, WooCommerce). They all also have support for handling shipping and taxes.

Your mileage will likely vary greatly in terms of how well any one of them will fit your exact workflow and needs. Shopp has integration with TaxCloud (taxcloud.net) so you can outsource your tax collection problems for all 17K+ tax jurisdictions in the US. Shopp also has complete integration for ShipWire (shipwire.com) to outsource order fulfillment and warehousing/inventory. If you want to take care of fulfillment and inventory in-house, you can still do that as well. Most of the stuff to do that comes with the plugin. Hope it gives you at least some good guidance.

jbx, although Shopp is a designed as a “full blown” shopping cart, all that stuff can be disabled so you can use it just as a catalog. To be precise, there are settings that you can simply set as disabled for: the shopping cart (disabled checkout as well), calculating shipping, and calculating taxes.

A lot of them are good or at least good enough. If you have specific requirements I’m sure a better shopping cart can be recommended.

(Full disclosure: I’m the lead developer of the Shopp e-commerce plugin)

There is a forum that is only accessible to those that are verified customers: https://forums.shopplugin.net/

There is also a Help Desk that allows those that are not customers to contact us with pre-sales inquiries or customers that can’t access the forum because of an account issue: https://forums.shopplugin.net/forums/help-desk

Regarding robindillard’s assertions that there is a XSS vulnerability on the account page, I replied to the concerns on our blog.

We’ve come across this a few times where some PCI scanners report vulnerabilities that are in fact not vulnerabilities. In one case we saw a PCI scan of a Shopp site that reported an XSS vulnerability in the Cart via the promo code input. However, we do proper escaping by encoding entities from the input. The re-encoded input is output back to the browser in a “safe” form that prevents it from creating a real problem. However, because the scanner detects parts of the output in the value of the field, it flags a problem despite there being zero chance of an XSS attack being successful.

On issues like that we’re at a bit of a cross roads as we know we are properly filtering input and escaping output despite these scanners saying there is a problem. We could fix it for that specific scanner, but then there could be problems in other scanners as each scanner may have slightly different assertions about the proper handling of the test case exploits. We have a lot more research to do before we can resolve this issue universally.

@pnaw10 it should work since the password hashing class was introduced into WordPress 2.5. It should work with any version of WordPress 2.5+

Ok, the script I modified is available for download off my blog. I wasn’t aware that hery took his original down.

Here’s a link to the blog posting with a download available of the modified AuthWordpress.php and full installation instructions:

WordPress, bbPress & MediaWiki

I’d appreciate postings of others who get it to work. Feel free to let me know if you run into problems so I can improve the instructions.

Ok, one follow-up. When logging in to MediaWiki from an account that exists in WordPress, but does not (yet) exist in MediaWiki there is a problem creating/copying the account into MediaWiki with AuthWordpress.php

Find the setPassword() function (around line 272) and change:
return false;

to:
return true;

I think hery was thought that it would set the password in WordPress, when it is actually setting the password in the MediaWiki authentication database. Admittedly, I can’t blame hery, the comments in the code are a bit ambiguous when it just says to “the authentication database”.

So 4 lines of changes. Still not bad, thanks hery!

I was just able to get hery’s to work. Looking over the code, it all looks safe enough to use with PHP5. A vanilla setup of the AuthWordpress.php file results in logins always failing. The problem is in authenticating the password. That’s relatively easy to fix by importing some of WordPress’s new hashing functionality in class-phpass.php. I literally made 3-line changes to AuthWordpress.php and got it working with WordPress 2.6 and MediaWiki 1.12 (as of this writing the latest version).

After line 58 add the require line for class-phpass.php so it looks like this:

require_once('AuthPlugin.php');
require_once('../wp-includes/class-phpass.php');

You may need to adjust your path to class-phpass.php depending on your file layout. In my setup, MediaWiki is in a sub-directory of the WordPress install (e.g. /wordpress/wiki, so the path to the class would be /wordpress/wp-includes/class-phpass.php)

Next you need to alter the authenticate() function in AuthWordpress.php to use the new password hasher.

Around line 175 (176 if you added the line above), find the line that looks like this:
if( $res && ( $res->user_pass == MD5( $password ))) {

Add the following code as a new line BEFORE the if statement to create the PasswordHash object:
$wp_hasher = new PasswordHash(8, TRUE);

Now replace the if line:
if( $res && ( $res->user_pass == MD5( $password ))) {

with the following:
if( $res && $wp_hasher->CheckPassword($password, $res->user_pass)) {

Boom, login works. Now if only I could figure out how to share the session. Hope this helps someone else.