Hi there
Given that only certain mods and extensions are multistore compatible I assume the next solution would be to have two (or more) separate stores running import/export scripts on (frequent) cron jobs to try and keep stock levels in sync? I also like the idea of being able to tailor text and seo to each site rather than it all being shared, even if they are using different themes and may not feature all the same categories and products. Does anyone have any examples of other solutions that they have used in a similar situation please? I'd love to hear your experiences.
Thanks,
That's a bit of a two-edged sword. If they share the same domain and are not in their own subdomains, then they can make their own contributions to overall unique content of the domain. Otherwise, separating them would have some practical advantages, including as to keeping scripts out of one another's ways. You could let each of separate ones take on its own inventory even of same products in separated stockpiles, much as you might let separate physical stores do their own ordering from the same preapproved suppliers, without mixing their stockrooms (a CPA can do that separately, by making a single scramble of them to suit his own tastes if he so wishes). You might also suffer reduced occurrences of confusion while focused upon separate arrays of details in admin, If they are separated.
Hi butte
Yes I am thinking unique urls rather than sub domains and rather than going down the addon domain sharing same root route(!). I like the idea of shared and unique products in each store, unique seo and unique content, keeping them distinct and focused on their target markets.
Is there a third way out there or are these the only 2 options?
If going down the separate database route with cron job import/export for stock control across all stores how do people handle this - how is the 'master' stock level maintained? If store A sells product X and product Y and store B sells the same products, when store A sells some stock of X store B can import the stock level from A but how would it work in the opposite direction - if simultaneously store B sells some stock of Y when store A imports the stock level from store B it would see stock levels of X being higher than its own and import the stock level. Does anyone actually run 2 or more stores like this and can explain how they have it set up please?
Thanks
Yes I am thinking unique urls rather than sub domains and rather than going down the addon domain sharing same root route(!). I like the idea of shared and unique products in each store, unique seo and unique content, keeping them distinct and focused on their target markets.
Is there a third way out there or are these the only 2 options?
If going down the separate database route with cron job import/export for stock control across all stores how do people handle this - how is the 'master' stock level maintained? If store A sells product X and product Y and store B sells the same products, when store A sells some stock of X store B can import the stock level from A but how would it work in the opposite direction - if simultaneously store B sells some stock of Y when store A imports the stock level from store B it would see stock levels of X being higher than its own and import the stock level. Does anyone actually run 2 or more stores like this and can explain how they have it set up please?
Thanks
OC v 1.5.4 with alot of tweaks,exts & mods.
Stocking is simplified if both find their own separate optima, budgets, and cron jobs, subject to executive (admin) overrides from above. In large grocery, restaurant, fuel, hardware, department, and other chains, whatever the trucks unload that was budgeted stays where it was unloaded, subject to rare executive (corporate) overrides from above. True, vehicles and coffee cups tend to wander among chain dealerships, but not conspicuously so.
Thanks again butte
Needing to automate the unifying of the stock levels of common products across 2 or more stores with no linked database I am now really interested to hear if anyone has any practical (operating) example of how they make this work - what extensions are used, what frequency of cron is manageable, what 'rules' are set for master store for stock levels and how..etc.
Hopefully someone is successfully running a similar set up or has experience of one, or alternatively can share their story of a failed attempt or alternative solution.
Thanks,
Needing to automate the unifying of the stock levels of common products across 2 or more stores with no linked database I am now really interested to hear if anyone has any practical (operating) example of how they make this work - what extensions are used, what frequency of cron is manageable, what 'rules' are set for master store for stock levels and how..etc.
Hopefully someone is successfully running a similar set up or has experience of one, or alternatively can share their story of a failed attempt or alternative solution.
Thanks,
OC v 1.5.4 with alot of tweaks,exts & mods.
So are you suggesting that all and only common (shared) products be stored on a separate DB or that all products, for both (or more) stores be all stored on a separate DB? Would there be no other queries that needed updating (I guess that it would men updating product queries both in the core store and in calls made by any extensions?) Could this even be done my vqmod?billynoah wrote:you could have all stores share a single database but use different db prefixes. then you could change the prefix in any query to the product table to a common prefix so all stores share only the product table.
I'm guessing that this may be 'harder' in the short term to set up (certainly if the changes couldn't be made to the code via vqmod(s) but more accurate/straightforward in the longer term. I assume that all product in the shared DB would display in the admin of all stores but could be disabled on a per store basis - given that I would ideally edit the product_decirption for each product on a per store basis, the shared db need only contain product_stock and product_option_stock data. Can the data be 'split' in this way so that stock is called from one db and description/image/meta/seo is called from each stores db?
Thanks for the suggestion billynoah - it's a little beyond me to understand all its implications straight off, so any further clarification would be much appreciated
OC v 1.5.4 with alot of tweaks,exts & mods.
Also might it be possible to just add a bit of code to the /system/library/response.php file instead and alter the product query using a regex? Again this is just outside my knowledge but I know that this kind of a thing can be done - maybe not in this case though! 
OC v 1.5.4 with alot of tweaks,exts & mods.
The disadvantage in using different prefixes is that the entire array of tables is replicated, and at some juncture the .sql file becomes substantially, even unmanageably bigger than big or huge. The disadvantage in using different databases is just keeping track of their credentials. Whatever means, manual, vqmod, cron, etc., might be used to (re)load and update one database or prefix would work perfectly well for the other database or prefix. The two (databases or prefixes) for separate stores would be separate. For practical purposes two cron jobs on the same database should not be simultaneous (surges and overloads worry hosts). You could also marry or semi-marry them.
Most extensions I've tried are multi-store compatible. With vqmod being able to use wildcards, it's easy to apply them across all stores or just 1 if you designate that stores template. The exception I've found are themes that have controllers for color/etc. as they can only handle 1 store.
Running Opencart v3.0.3.9 with multi-stores and the default template from https://www.labeshops.com which has links to all my stores.
Hi Labeshops
This maybe the case - although once you get into more than a few vqmods and you have to copy/paste/edit chucks of every one to make them do different things to different stores I am guessing it would become complicated! We already have one store where we wanted English Admin and French Store languages but didn't want to have both languages in the admin side - avoiding having to fill in 2 fields for required fields in products etc was a big requirement. We ended up copying the english.php and admin/language files over the french admin and french.php and setting french as default (only lang) for both front and back end - it's amazing how often you can spend a while scratching your head before you realise that the vqmod is looking for english and not french in the language file, despite it looking to insert english text into the files!
Also I am looking for the ability to market the products in different ways - so I want to have different text, images, keywords etc for each store - all in all I suspect that multistore isn't the solution for us here unless I have misunderstood it in a big way.
This maybe the case - although once you get into more than a few vqmods and you have to copy/paste/edit chucks of every one to make them do different things to different stores I am guessing it would become complicated! We already have one store where we wanted English Admin and French Store languages but didn't want to have both languages in the admin side - avoiding having to fill in 2 fields for required fields in products etc was a big requirement. We ended up copying the english.php and admin/language files over the french admin and french.php and setting french as default (only lang) for both front and back end - it's amazing how often you can spend a while scratching your head before you realise that the vqmod is looking for english and not french in the language file, despite it looking to insert english text into the files!
Also I am looking for the ability to market the products in different ways - so I want to have different text, images, keywords etc for each store - all in all I suspect that multistore isn't the solution for us here unless I have misunderstood it in a big way.
OC v 1.5.4 with alot of tweaks,exts & mods.
The basic idea is that all products would be shared, and if you are sharing the product table then every field from there would apply across all stores - including enabled/disabled. So no individual store control over these things - change in one you'd change them all.JIMSLITA wrote:Can the data be 'split' in this way so that stock is called from one db and description/image/meta/seo is called from each stores db?
If you really wanted to spend the time you could create a special shared table that only holds the stock field and alter the queries accordingly.
I don't like the idea of a cron job since inevitably some events would happen in a way that would make the data inaccurate. I think if you are using separate db's then then thing to do would be to have a function which updates all db's instantly when stock changes in one.
There are many possible solutions here - if it was me I'd probably just go with multistore and deal with extension compatibility issues as they come up. This way you'd keep the smallest, most manageable dataset and it seems like the most simple and conventional approach.
Who is online
Users browsing this forum: No registered users and 81 guests
