|
Group: Administrators
Last Active: Tue 10 Sep 2024
Posts: 807,
Visits: 2,748
|
Now that v2.6 is almost ready to go, we're working hard on getting plans for v3.0 finalized. As a starting point, we expect we will need to move some values from the general config system into a per-site system. This may be done with a new table, or it might be achieved with modifications to the existing config table.- general.webshopurl
- Site skin (currently set in languages)
- Site name (friendly name for back end use)
- frontend.display.showtax
- frontend.users.acces
- general.security.ssl
- general.storestatus
- frontend.cataloguemode
- general.googleanalytics.webpropertyid
- frontend.languages.default
Pricesinctax must apply system-wide because the prices entered in the back end must be either inctax or extax.
We would also want to be able to specify which languages and currencies should feature on each site, as well as which payment systems should be available.
We would want to tag orders as to which site they'd come through, and allow filtering/viewing by this.
Customers would be shared across all systems, so customers would not need to re-register on sub-sites. We may allow site-admins to set a site to 'deny' access at default, so only specific users would be allowed to view it.
Mapping products
One of the biggest tasks is how to approach mapping categories and products to the various sub-sites. We feel the best way to so this is to use the existing category system where products and categories can be mapped to multiple parents. To create a subset of products or categories to display on a sub-site, you'd create a new top level category, or designate an existing one. This would form the root of the product catalogue used on the site.
We'd alter the treeview in the back end so such categories were highlighted or in some other way marked up to differentiate them from normal top level categories. This system will allow any products or categories existing in the site to be mapped to any sub-site, even if new categories must be created for this purpose. But it also minimizes the amount of change needed for the back and front end pages and queries that already handle products and categories, which should help ensure performance is not affected, and that we minimize the possibility of introducing new bugs into code.
Viewing sub sites as admin
In normal operation, which site a visitor sees is down to the URL they use. Each sub site could have a sub domain or its own entirely new domain, or possibly even appear in a sub folder. But during development, it would be useful for an admin to be able to switch between which 'site' is being viewed (both during our development, but also for developers using Kartris to build web sites). We'd have some kind of menu system for logged-in admins to make it easier to view the sites regardless of domain, all using whatever domain the admin is using for the back end. This would allow the admin to see the front end of sub-sites which are closed to the public, or to view a sub-site even if the domain it will run under is not mapped to the server yet.
Payment systems
We will have a way to choose which payment systems apply to each site, but these will be shared. So it won't be possible to have each site use its own Paypal account, for example. This functionality may come later. It would however be possible to have one site use Paypal for payments and another use SagePay, as these are two separate payment systems and could be mapped to the appropriate site.
Shipping, tax rates and store location
At present, we're working on the basis that the site operator is one company or organization operating from one location. Therefore the shipping methods, prices, tax rates and store location will be assumed to be the same across all sites.
Custom pages
We will most likely have some way to map custom pages to particular sites, or all sites.
These outline our plans for the v3.0 multi-site functionality. We'd appreciate any input; we know it's a feature that is requested for various scenarios, but only with Kartris user input can be ensure we end up with a robust system that can deal with the widest possible range of requirements.
--
If my post solves your issue, can you 'Mark as Answer' so it's easier for other users to find in future.
If you would like to be informed of new features, new releases, developments and occasional special bonuses, please sign up to our mailing list: http://bit.ly/19sKMZb
|