Multistore in OpenCart

OpenCart is designed as a single-user shopping cart either, running as a single-store setup or, as a multi-store setup.

The existing multi-store works fine on the front-end where there are multiple stores For example, $this->config->get('config_name') will return the name of the store being viewed, however, $this->config->get('usps_status') will only return the value for the default store, since that is the only store any extension is configured for.

This can be a problem if different extension settings on different stores, for example: different shipping methods, or only allow certain payment gateways, etc.

Example 1
You want to use different shipping methods for different stores, but don't want the others showing up as options in the checkout. Or, you want to use the same shipping method in different geographical zones (or the same zone) at different rates on different stores.

Example 2
You want one store to use PayPal Standard as its only payment gateway, another store to use Google Checkout.

Example 3
One store uses gift vouchers, coupons and reward points, another store doesn't.

None of these are possible the way that multistore is currently implemented in OpenCart.

In the Administration
Extension settings are added to the "setting" table (using PayPal Standard as an example) by way of: The editSetting() function in the model is defined to take three values:

editSetting($group, $data, $store_id = 0)

$group -- the configuration group that is being edited. In the case of a store, this is 'config'. For an extension, it is the name of the extension, eg. 'pp_standard'.
$data -- the data array being posted through to the function. For a store, these are things like: 'config_name', 'config_url', 'config_currency', etc. For an extension, these would the things like the extension's staus, sort order, geographical zone, fee, tax class, etc.
$store_id -- the store ID that the setting is applied to. A default of "0" is used if no store ID is passed through. This is only implemented for store settings.

Since no store ID is passed through when editing extension settings, these settings are only ever configured for the default store ($store_id = 0), and are treated as "universal".

These "universal" settings are then retrieved from the settings table with $this->config->get(), for example:

$this->config->get('pp_standard_status');
or
$this->config->get('fedex_geo_zone_id');

both in the back-end and in the front-end.

This works fine in the front-end, with $this->config->get('config_name') returning the name of the store being viewed, but in the back-end, $this->config->get('config_name') will only ever return the name of the default store.

While $this->config->get('some_setting') works fine on the front-end where there are multiple stores, the back-end is a different matter, simply because there is only one back-end. Subsequently, $this->config->get('some_setting') will always return the setting for the default store.

The Concept
When a new store is added, a call is made to the addStore() function in the model from the controller (admin/controller/setting/store.php): The addStore() function returns the ID of the newly created store, which is then used to edit the configuration settings in the "setting" table in the database, by way of: When editing a store, the store ID is retrieved with a GET request and used to update the store settings, as in the following: When a store is edited, the settings are retrieved from the "setting" table with: In the controller we have: When editing extensions, no store ID is passed through, so they are all configured for the default store ($store_id = 0).

For true multistore, we need to GET the store ID and pass it through to the editSetting() function when the extension settings are edited, by way of:

$this->model_setting_setting->editSetting($extension, $this->request->post, $this->request->get['store_id']);

Where $extension is then name of the extension.

This can be done by redirecting to a "select store" routine where the store can be selected and a GET value containing the store ID can be added to the URL. Of course, this process would be invisible in a single store operation.

This principle can be applied to all extensions: shipping, payment, order totals and product feeds (even modules - although not necessary for these).

Once we have the store ID, this can be passed on as a GET value when editing individual extensions (shipping methods, payment gateways, etc.). Subsequently, when saving the settings, we can then use (using PayPal Standard as an example): This way all extensions (shipping methods, payment gateways, product feeds and order totals) can be configured independently on a store-by-store basis.

Extension settings can then be retrieved with something like: In the extension controller, instead of using: to retrieve the extension settings, we could use something like: Proof of Concept
See Demos @ Fido-X. This is a multi-store demo.

On the front-end, you will find an extensions list displaying all the extensions, their status, geo zone and cost or rate (if any) for each store.

You can view the back-end by logging in to the admin with username/password pair of demo/demo. Once logged in, you can view the shipping, payment, order totals and feeds extensions. Most of those installed have modify permissions allowed so that you can change the settings and see the change reflected in the front-end in the extension list on the home page of each store.

I agree there are some improvements that should be done to multistore, your concepts included. Though personally I use the same payment and shipping options on all my stores so this hasn't been an issue for me, I can see where others may want to use different ones per store.

The other area I think that needs improvement is in allowing unique content per store - in terms of separate category descriptions, product descriptions, manufacturer descriptions (which oc needs in general and not just thru an add on). different images, etc. Basically anywhere you can add text or images, you should be able to vary it per store. This aids with both avoiding duplicate content and in letting us tailor the same product for different target markets or different applications which would help boost sales. Being able to write very specific benefits and descriptions for each stores target market would be a huge advantage.

labeshops wrote:The other area I think that needs improvement is in allowing unique content per store - in terms of separate category descriptions, product descriptions, manufacturer descriptions (which oc needs in general and not just thru an add on). different images, etc. Basically anywhere you can add text or images, you should be able to vary it per store. This aids with both avoiding duplicate content and in letting us tailor the same product for different target markets or different applications which would help boost sales. Being able to write very specific benefits and descriptions for each stores target market would be a huge advantage.

If you were to have a different description for each product depending on the store(s) the product is linked to, you also need to take into account the multi-language issues that would come into play, as you would have to enter a different description in each language for each store.

Frankly, I don't see how you can avoid duplicate content if you want to have a different description for a product, category or manufacturer if you wish to have a different description on each different store. It's the same product, so the description of it would be the same, regardless of store. And then, you have the multi-language support to consider. The same would apply to categories and manufacturers. And, when it comes to a manufacturer description, there would need to be a manufacturer_description table in the database to handle the description, and only the description, since the name of the manufacturer would be the same in any language. For example, "Apple", as a computer manufacturer, is spelt the same in EVERY language.

I actually already have a mod that lets me have a different product description per store, but mentioned this as it should be in the core imo.

No, the product description isn't necessarily the same just because the product is the same. Lingerie I have on sensualelegance for example is targeted for the general consumer, so basically just describes the item. But the same item might have certain features I want to highlight on stripperplus for example - like quick release clasps, etc, and I might use more suggestive/adult language on that site than others. And the same item may come in plus sizes so I want to highlight the plus size version (with a different main image) on curvyelegance and feature how it flatters the curvy figure, larger breasts, etc. And the same item again might be wearable by crossdressers so I might want to add that to the description for crossdressfashions. If it could be used as a costume or part of a costume, I would highlight that for cosplaycostumecloset. If it is slightly gothic in appearance, I would describe the same item differently on gothicplus.

There are really infinite ways to describe the exact same product pointing out the benefits and features my specific target audience for that store is most interested in. Not to mention idioms or other ways of speaking more suited for my target audience on a particular store (younger audiences say things differently than older customers, etc.) and more adult oriented descriptions for some of my sites versus kid friendly cosplaycostumecloset etc.

In the same way, the manufacturer's description I have on gothicplus (via a mod of course since this isn't part of opencart but should be) would obviously highlight them as an alternative/gothic manufacturer, where that same manufacturer may make more mainstream styles and I might want to describe them that way on my other stores. Many of my manufacturers make items for different niches.

And of course the category description I would highlight different things yet again per store. You probably have the idea by now

Not to mention being able to target different keywords differently for each store since all of the above are really our main sales text on the stores. These are things that really need to be added from a marketing aspect not just an seo one.

I only speak English so don't use multilanguage at all, but yes, I guess it would need to be different per language too. I know the mod I have for product descriptions supports languages too, but never used it so no clue how it works.