Multiple nopCommerce sites on 1 database

Yes I did... these steps are the actuall work that I did

hello bklooste

i would love to have this feature. in fact i am in the same situation where i need to deploy multiple sites but ran into the support and maintenance issue. this would solve it.

can you please share the code ?

thanks a lot in advance.

here is my msn id : csouheil [at] msn dot com

I think in this discssion a potential error has been made....... the concept of client / merchant.

Those people/organisations using nop are probably hosting companies.

Hosting companies, with multiple clients / merchants.

Each client / merchant has 1:m stores/sites

Each client can have 1:m users with differing roles.

Lets look at the following scenario.... A Printer cartridge firm, selling a wide range of printer cartridges.

The client / merchant for the sake of the scenario is called PrinterCartridge and want a shop with a domain

www.printercartridge.com

They may also want specialist websites for brother, epsom and hp cartridges

www.brotherprintercartridges.com
www.epsomprintercartridges.com
www.hpprintercartridges.com

What I can imagine, is the shop (PrinterCartridge) administrator logs in and enters all his printercartridges. Assigns the cartridges to categories and then assigns which categories exist in which shops.


Therefore I think, instead of having products keyed by store, they need to keyed by client / merchant. I believe categories should be keyed by store/shop (through a link table due to the m:m relationship)

In the admin, when the user logs in you may been to carry around the currentClient object.

And yes this, in essence touches every part of nop... and is labour intensive. Worked on an ecommerce system before, and am writing my own doing this exact same functionality.

mkeay I agree with you.... me too ending up writing from scratch the system in order to over come this. The problem people think they can add few commands and procedures and will be able to have a multi store system... The problem with  some programmers or system administrators they don't look into the maintenance side as they feell it will fix itself.
But once a system is running live .. it becomes harder to change table structure... relations... coding... unless you really know how to do it, and how to test it so you don't end up busting all your live data....

Having a client/merchant ID as well as store/site ID depends on 2 things...

a) Type of application
b) Flexibility for future requirements.

If you are a hosting company, providing eCommerce websites for subscribers to the platform, and thus serve up multiple sites, then grouping the data by client/merchant is very important.

In fact, I would argue that this should actually be the starting point.

If you consider that at present you may have 10 clients/merchants with there own databases being hosted by yourself, then this is probably managable. If you consider 100 clients/merchants with there own databases, this starts to become unmanageable.

Depends on how you deliver solutions to your clients.

Also bear in mind, that changing a live database is not as easy as people make it out to be. Some people argue that the column should be allow nullables or default values, but how many times in the heat of battle have people promoted code that either doesn't allow nulls or missed a default value, leaving egg on the face of the web developer/hoster.

Disk space is paramount, and a good 3 month cleaning schedule to cleanse the database.

Writing code is easy, solving customer problems is not. The hard work is done in the analysis and preparation stage, not in writing the code. Bear that in mind when considering the most appropriate solution.

i agree with bklooste

in theory, the whole concept is to be able to assign a base category at the start of the application instead of 0. this allows you to run different sites pointing to single DB, of course, of course admins must manage their own categories although they would have access to everything (a restriction to allow only access to the base category can be added in the admin area). a very limited solution (the site name, config and many params will be shared).

that is if you want to have separate installations. but the complex part is to be able to handle  multiple sites with multiple domains and different themes, parameters, config, payment configs ... then you need to write a bit of code and change the SPs and DB tables, which is what bklooste has done. creating a sitemanager class to handle all of this is the right way.

i chose a bit different approach. i preferred to start making the site automatically pick its theme and set of master pages based on a couple of settings.

i am able to completely relook the site (theme and layout) with one click with possibility to assign each page to a theme/masterpage separately if needed. but that does not give me the true multisite such as what bklooste has done.

i am only waiting for the next release of nopcommerce to add this functionaly, and have the new features included.

I am in full agreement that you have to have multiple sites, you need a site table, but my point, if you read the entire thread, is that you cannot consider one without the other.

I.e. At present in nopCommerce you have 1 web application, with 2 parts.... a store front with admin area. But if you are going to fundamentally change the entity model one should also consider other requirements, and the other side of this discussion is the client/merchant and there interaction with the site.

You could end up with an administration front end that allows a client to log in, add categories, add products, assign products to categories, assign categories to stores etc...

All I am saying is this, in my view, serving multiple sites is only half the problem.... Again, life always looks easy if you have one client/merchant with multiple sites, but with multiple clients, then thats a different kettle of fish, and products (catalog) should be keyed on client/merchant at that point.

Just my opinion, but an opinion based with commercial experience and my own hard toil.

Yes. You've got it.

The large merchant will want there own DB, that is certain. No doubt with specialist customizations that go with it. But for the small to medium merchant, then a platform/portal that can support 500-1000 merchants is cost effective for both hosting/outsourcer and in the end customer.

If that type of solution is adopted then you need to key tables in the database.

Client/Merchant

Store/Site

The relationship between client/merchant and store/site is 1:m

Store/Site is used by the application for presentational elements - themes, categories for the site (through another table)

Client/Merchant is used by the admin application for administrating the products, sites, etc......

As I said, the only reason I came across this is that I have a working ecommerce platform doing this. This provides me with 2 applications (store & admin) and 1 database. This allows me to release a new admin application with a new report which all merchants inherit as well as other features.

The reason for me joining this discussion was to highlight what I believe is a hole in the analysis, especially with large scale entity model changes taking place. I was looking at what was being offered by the open source, to see if was viable to move to an open source platform. I am not sure that nop or any other open source products are mature enough yet for my type of application.


Each have there own view on analysing requirements and coming up with an appropriate solution.

a lot of people just want to have multi store front for the same products they are selling, just to have a marketing advantage of several websites, which that is the coming edition will have a common products and categories just having them displayed a bit different.

The problem lies as mentioned when you are hosting for small companies which have no relation to each other, completly different products, services and management. Even payment gateways, one company might want to use one not the other.. who is registering for the gateway you (the hosting company) or the merchant himself.

Unless you can brake the program to three sections:
- Administration (the person hosting),
- management/admin for the stores you are hosting so they can manage everything, even to the details of the email and the content of the about page, terms of use, conatct us, anything and everything in there store.
-Customers who are purchasing these products.

It just gets too complicated to keep modifying the source you overlook things...But with proper analysis you will be able to identify the problems as they are occuring and make changes to the system because you understand it, and have proper analytical documentation.... unless you are one of the people who always keep things in his mind: "yeah I remember I have an error on line 23893, and line 83737 and line 87873, ..... , 676732...when I finish I will fix it".

I ruther be able to come in a year and be able to expand the system, and be able to fix bugs as soon as they happen.

A Happy customer = 10 Happy NEW customers.....

I need your opinions: I am actually stuck in this one

I will be hosting several companies from the same towns.... which means they have shared customer information as addresses and emails.

One solution is to allow the same customer log into other sites with the same login id.... but how to I explain this to customes without showing the relation between one hosted store and the other. This method will have unique email registration. The problem when I delete a store and want to delete all its customers so I can maintain the DB. this also applies to customer addresses.I will need store customer mapping. you treat customers as user roles mapped to one or several stores. and you delete the mapping before you delete the customer.. but this come with complicated source to delete mapping addresses and customers as you have to access several tables, to filter the out and solve the customer store mapping and delete everything. One mistake in the delete proces you will need to role back everything.. maybe 10000s records....


The second solution is to not require unique emails, have customers register for each site as if it is completly independent of others. and also identify customers by store id. With this you run in a problem of bogus registration and spam. but easy to maintain... Also huge DB.

If anyone thought about this I will appreciate the input. Thanks