Multiple Storefronts with a Common Administation Backend

[JeffPyeBrook]

Been thinking about how to setup WP-E-Commerce so that multiple storefronts to use a common backend.The common backend is important for fulfillment customer interaction, workflow, and reporting when someone is running multiple stores. Having to log in to 4 or 5 ( or more) web sites to check what orders are in what status is a little inconvenient.

It seems that as a first step to adding this capability is a pretty easy one. It would get us a back-end that would see the common data.

If we had a wpec-config.php that allowed us to define the 'post-type' that a specific store would use for products, then one could create 5 web sites, all in the same database, all sharing the same tables.

WPeC would have to create the post type and category taxonomy to match.

The default value for a constant WPEC_PRODUCT_PREFIX would be "product", that would create the wpsc-product, wpsc-product-file post types, and the wpsc-product-category taxonomy.

In wpec-config.php we would also need to define the WPDB prefix that would be used to be sure the store data resides in the correct db. It's default would be the value of WPDB_PREFIX from the wp-config.php

So a multi-store config file for a hat store might look like

in the hat store wp-config.db: $table_prefix = 'wpstoredb';

in our first store, a hat store, wpec-config.php: define( 'WPEC_PRODUCT_PREFIX', 'product'); define ('WPEC_DB_PREFIX', $wpdb->prefix );

in a second store we added, a shoe store, wp-config.db $table_prefix = 'wpshoestoredb';

in the shoe store wpec-config.php: define( 'WPEC_PRODUCT_PREFIX', 'shoe'); define ('WPEC_DB_PREFIX', 'wpstoredb' );

In WPEC code when we setup the tables in the $wpdb object and the global table defines we would user $wpdb->wpec_prefix instead of $wpdb->prefix.

Any one else think the multi-store (mall) feature is a good one? Shall we try to migrate it in at version 3.9 and see if it catches on?

[JeffPyeBrook]

and two questions... will the above approach work? Would anything above break something in WPEC in either store described in the scenario?

[JeffPyeBrook]

just thought of the additional thing we should do...

When a purchase from a store is made a purchase meta should be added identifying the store the purchase came from. Use for report filtering and other stuff.

Easier that going backwards though the product ids to find the store.

[instinct]

This is a worthy talk but it feels more like a Plugin. If you can nail it as a Plugin we consider it for core - that is what WordPress do now and I think its really good practice - AND it helps us make sure WPEC is crazy extendable.

In the past I've thought about multiple stores (mall) and shared checkout. Jen Mylo and I were looking at it / thinking about it for wordcamp.orgbefore they created camptix.

We put significant brain time into this - not so much the technical programming side but around the customer flow, the potential problems etc... for instance the biggest problem from memory was probably around shipping tangible goods, what if one site used Fedex and another wanted to use USPS... not really a problem if you run all the shops but could be a problem if you're trying to create a mall.

This could be really cool and somewhat innovative :)

On Thu, Apr 3, 2014 at 1:50 AM, Jeff @ Pye Brook notifications@github.comwrote:

just thought of the additional thing we should do...

When a purchase from a store is made a purchase meta should be added identifying the store the purchase came from. Use for report filtering and other stuff.

Easier that going backwards though the product ids to find the store.

Reply to this email directly or view it on GitHubhttps://github.com/wp-e-commerce/WP-e-Commerce/issues/1022#issuecomment-39325701 .

Dan Milward

M +64 21 449 901

178 Willis Street - Wellington CBD - Wellington 6011 - New Zealand www.getshopped.org - www.gamefroot.com

[JeffPyeBrook]

I definitely agree with the plugin first approach, it just doesn't fit here because what I suggested is creating the configuration option that would enable the core functionality. Not sure this can be done in a plugin since the post and taxonomy values are hardcoded. No easy way to hook every one of the thousands of possible queries that look for post type or product category.

But it's easy enough to clean up the code so instead of hardcoding 'wpsc-product' into a WP_Query statement, is WPSC_PRODUCT_POST_TYPE. Easy change, and very low risk. Might even make the code a little easier to read.

As far as the shipping example you noted, the purpose of doing this would be to allow multiple front ends be serviced by one backend configuration. If a dev wanted to have completely different store configurations why not run completely different stores? However, the shipping example could be done very easily with a plugin that looked at the defined store name and conditionally loaded the appropriate shipping components

[JustinSainton]

I need to think through your proposal a bit more, but here are some very initial thoughts -

• bbPress and BuddyPress have their taxonomies and custom post types set up via filterable functions. We could (and arguably should) do the same.
• With that low-touch change to core, you'd likely then be able to build this out as a plugin. I agree with @instinct, this makes more sense as a plugin first. If it's something that proved itself to be useful enough, we could essentially bake it into core in the same way that Multisite is baked into WordPress. It's in core, but off by default unless you've set define( 'MULTISITE', true ) in the wp-config.php file. We could have a similar constant for this.

Worth noting, the thoughts outlined here are along similar lines to what @ipstenu has mentioned and opined on for years. (ref). Not the same thing, but definitely in the same ball-park.

[JeffPyeBrook]

I will try this on a dev system once we get 3.8.14 out. It might be as simple as create DEFINE statements for our post types and taxonomies.

I'll see what unexpected happens after the experiment.

It would be great if we can get the basic feature without even a plugin.