Share a database between stores

[Lorissia]

I've spent an obscene amount of time reading all the threads I could find on this and while I believe my scenario is relatively simple, I can't find a straight answer anywhere.

I've read so many posts that state :search for "sharing database" to find the answer. Please, if you know where the answer is, can you help? I've done those searches and found dozens of posts in them telling me to search, but still no answers. I've also seen dozens more posts from people who ask but never get an answer.

Here's the scenario:
I want one admin section for a vast line of products.

I want stores setup on different domain names to use the same product/customer/etc. database so I can admin the products/orders from one place.

They will all use the same merchant processing.

The only thing that will be different for each store will be the theme/colors/logo image.

All domains will be on the same server.

This seems fairy simple but I need to know exactly how to go about it.
I previously used cubeCart and want to move to Zen. I accomplished this fairly easily on cubeCart by changing the config file to the main database name and login.

Please help with specifics?

[Lorissia]

The very first thing I've had that's disappointing to me concerning ZenCart is the lack of response to posts on the support forum. I've searched and searched and see see a considerable number of questions (like mine) go unanswered.

Support is very important to us and though the program seems awesome in itself but support is needed from time to time.

[DrByte]

The very first thing I've had that's disappointing to me concerning ZenCart is the lack of response to posts on the support forum. I've searched and searched and see see a considerable number of questions (like mine) go unanswered.

Support is very important to us and though the program seems awesome in itself but support is needed from time to time.

The very first reason why a given post goes unanswered is that the answer is either not quickly found/known, or is very complex to implement.

Chances are that if you've searched and searched and searched and not found an answer (whether several other requests for same thing have been made or not), then it's not exactly a simple thing to do.

Please forgive the bluntness of this statement: This is an entirely volunteer thing. If you want instant response, hire someone to give you instant response. We have a Commercial Help Wanted area to assist in this process.


So, with that out of the way, here's why this is complex, and may give you an indication of some of the kinds of things that need to be addressed should you decide to proceed in this direction.

1. Yes, you can simply point 2 stores to the same database, using the settings in your /includes/configure.php and /admin/includes/configure.php

That's where simplicity ends.

2. the potential problems are:
-- A. session security. This is a huge kettle of fish, and most likely the reason why nobody wants to get into the hours of custom coding and testing this without compensation.

-- B. distinguishing between templates and layout settings. If they will be identical other than graphics and colors (ie: sideboxes will be in same place on both sites), then things are simpler, but any differences will require custom-coding to pull settings for those from a different database table.

-- C. some potential SSL clashes between domains

-- D. how do you manage the orders from the admin in such a way as to keep things separate? How do you distinguish one purchase from another, so that branding and customer-notification texts, etc are retained based on where the customer ordered from?

-- E. and I'm sure there are additional issues which have been discussed in other posts discussing similar topic as yours

Zen Cart has not been written to be a mall, at least not at the present time. This doesn't mean it can't be adapted. I know there have been a few sites who have done this with some success by hiring a coder to assist. I don't know how much care was given to the issues I mentioned above, nor whether they are happy with the results.


I'm sure you're not excited about what I've shared here, but perhaps I've helped you see some of the larger picture of issues that will need to be faced in order to accomplish your goals...

[hareslade]

This isn't an answer to Lorissia's wish, but the closest I would go..

I'm toying with similar ideas, but as expressed, sharing the complete database is a bit mad, because two separate zencart installs are just not designed to be mated... fools step in where angels....

But tonight I did try two separate installations, into the same database, but with shared customers and address book tables (by altering one cart's table name defines for just those two tables, to point to the other cart's equivalent table) ,

all the rest of the tables are 'as if' the carts are completely separate.

I've not tried it web-live, as I don't have two domains on the server yet.

but certainly the user log-ins are the same user/pw on both carts, and they work after registration on just one cart. But one has to log in on each cart as normal.

- the only missing item is I think the 'account created' date - for that date will go into the cart table belonging to whichever cart the user registers on - but that missing date just appears as a blank in the customer admin section, it still works ok I think functionally except the customer options will inevtably be the same on both carts..

Personally I would keep the carts separate apart from that.. presumably the complete contents of product data tables are easily transferred between cart tables if you are any good at using phpmyadmin or data transfer gizmo's, ..

My application wants two separate carts for different sorts of products, 'one per domain' but with common user/passwords to both.. this seems ok to try.. anyone know any different, let me know..

This simple setup at least means no problems with having common config settings which dictate that both carts must use same named template set or other basic layouts such as sideboxes.

the two carts can be completely different looking, and as long as they are the same zencart version regarding usage of the two shared customer tables, each one can be set up with individual design.

[damonp]

Currently running three sites off of the same database:

www.PimpCostumes.com
www.PlatinumCostumes.com
www.CostumeShoes.com

Not a trivial customization, but doable.

Basically each site uses its own install of ZC directed to the same database. Most tables are shared. Configuration and site specific tables are unique, by adding a _sitename to the table name in tablenames.php with the required tables created. With this method you can share orders and customers or not.

As each of my sites has a different category and product layout, I created a top level category for each site, then modified the the category and product SQL to only look under the current site's top level category.

Products can be easily add to one site in the admin and then copied or referenced to the other sites.

Sites have been up in this way for a couple of years and several ZC upgrades.

[rknepp79]

As each of my sites has a different category and product layout, I created a top level category for each site, then modified the the category and product SQL to only look under the current site's top level category.

This is exactly what I planned on doing with my site. I want one installation with one database. I'm wondering though, how much work this includes.

I have 4 departments to my store. Each department will have it's own template, products, and categories. They will all share the same customer data. Each department will only show featured/all products from the correct department. I want all of these products and categories to be managed from within a single install of the admin tool.

It was suggested to me earlier that I just make 4 top-level categories (and the appropriate products inside them), however I found the visual results to be ugly. I do not want the top-level categories to show up on the page (in the header or in the sidebox) nor do I want the listings/displays to include products from other top-level categories.

So, if a customer goes to the ARTS department, only the second level categories are displayed (as if they were top-level) and only those ARTS products would be displayed in the many pages. When the customer wants to go to the SCIENCE department, they choose that option and are sent to the index.php page that now shows a different set of (second level) categories. All cart data and whatnot is shared since it is the same site.

I will make a custom section (sidebox or header) that sends the customer to the different departments. This could work in several ways. First, I could pass the value via URL to set a global var. I could also store settings in the DB. Either way, the customer is always assigned to a department which should affect the categories and products that get displayed.


Other sections I feel I need to visit (and modify sql, etc):
- breadcrumbs - (might not want to show department level)
- search (and advanced search) feature - (might just combine all departments)
- featured/all product listings and sideboxes - (limit to current department)
- site map - (might just combine all departments)


I have also been looking at the http://www.zen-cart.com/forum/showth...ultiple+stores thread which I suspect it does something similar to what I want to do. The problem with this is that it isn't released as of yet.

[damonp]

If you look at my links to the costume sites above, you'll notice the top level categories do not show on the respective sites, only those second level categories under the site category.

Breadcrumbs have also been customized to remove the unecessary category links.

Sideboxes and special lists (featured, special etc.) were all mod'd to only show the correct sites (via top level category) items.

Its all possible, just takes more time to get the finer details.

[rknepp79]

Damonp, do you have any documentation on the changes you had to make to complete this? I do not need exact changes, just a high-level list of what I should examine I decide to got his route. Depending on response to other threads out there (Multiple Stores with One Database) I may end up having to code this myself.

It sure would be nice if it was deemed useful enough to go into a core Zencart release... wouldn't that be sweet!?!?!?

hehehe

[damonp]

Sorry, no documentation. The best high level description of what I did is above a few posts.

I added a categories_top_parent column to the database. Basically, any file that uses the categories tables (from admin, to templates, to sideboxes, etc) has to be mod'd to be limited to a category below that site's top level category.

I would hope such a mod isn't included in the core. It required extensive modification to a lot of files. Its a very worthwhile mod for the few in 1000 users that need it, but it overly complicates the code for the 995 others that don't. Feature creep and code bloat are already becoming problems in my opinion.

PM me if you have specific questions and I'll see what I can do.

[rknepp79]

Sorry, no documentation. The best high level description of what I did is above a few posts.

I added a categories_top_parent column to the database. Basically, any file that uses the categories tables (from admin, to templates, to sideboxes, etc) has to be mod'd to be limited to a category below that site's top level category.

I would hope such a mod isn't included in the core. It required extensive modification to a lot of files. Its a very worthwhile mod for the few in 1000 users that need it, but it overly complicates the code for the 995 others that don't. Feature creep and code bloat are already becoming problems in my opinion.

PM me if you have specific questions and I'll see what I can do.

Actually everything you described in the above threads is how I've expected this needed to be done (i.e. categories_top_parent field, etc). I was just looking for a jump-start on the files to modify using that field. Anyway, your posts above will be more than sufficient to get me heading in the right direction. I appreciate all of your input on this and will let you know if I have any outstanding problems if I encounter them.

Thanks again,
Bob