Two Stores - One Database

Hi,

I know that this topic has been discussed many times, I'd just like to clarify certain things.

1. Would it be reasonable to do this if I want to implement a mobile site? Basically, I will copy/paste my current site into a new folder, for example, mobile.mysite.com - and completely customize all the newly copied files to display a mobile-friendly website - but of course it will be using the same database.

2. If the above is possible, are there any issues I need to worry about, for instance, how are sessions handled or are there any security implications? Also, certain threads make mention of using different database prefixes, why would you do this and is it necessary?

Thank you!

Two Stores - One Database - To Rule Them All - And In The Darkness - Bind Them.

What you're talking about is two faces to one store. It should be quite feasible. One thing I don't know about is if the two sets of software try to update the db at the same time, whether there is a possibility for confusion.

Database prefixes are only useful if you are trying to have separate sets of information in one db container. Most everyone has no need for this; the prefix is just an automatic artifact of auto-installers.

Thanks for the response, I guess it would need some trial and error testing then...

If it's just to DISPLAY the store differently when on mobile, then you probably just need some templating work, not another whole store.

DrByte:

If it's just to DISPLAY the store differently when on mobile, then you probably just need some templating work, not another whole store.

Hi DrByte,

the reason why I'm opting instead to copy the store and modify separately is becaused I currently I have so many customizations here and there and everywhere - I'd rather interfere with copied-over files than touch the ones doing their job properly.

I'm the kind of person who isn't very organized, and I know I'll slip up somewhere.

So, what do you reckon regarding complications I will face by doing this, if any?

Will an issue like the one gjh42 pointed out be a problem, or even exist?

Are there any complications you can think of that would occur in this scenario?

Yes, glenn pointed out some very valid issues. What you're talking about will require a lot of organized changes to core code to make it work smoothly.

the reason why I'm opting instead to copy the store and modify separately is becaused I currently I have so many customizations here and there and everywhere - I'd rather interfere with copied-over files than touch the ones doing their job properly. Then copy your store files and database into a test location (you can make it hidden from the public) and do all the template work you need there, so if you mess up you can just go back without worrying about your live store. Then when it works perfectly, copy that to your live location (keeping the live db).

This is always the recommended method for making changes to your store; it avoids all kinds of problems. See the tutorials for the complete version of this advice.

gjh42:

Then copy your store files and database into a test location (you can make it hidden from the public) and do all the template work you need there, so if you mess up you can just go back without worrying about your live store. Then when it works perfectly, copy that to your live location (keeping the live db).

This is always the recommended method for making changes to your store; it avoids all kinds of problems. See the tutorials for the complete version of this advice.

Thanks for the response.

This would however have been the normal procedure I would have followed. I'm not concerned about something going wrong during the development process - I would have developed in an an environment secluded from the lives store.

My concern however is after all of that, once I'm ready to connect the new files to the original db, and how it will play alongside the old files. Basically I'm wondering if there would be any conflicts, 2 stores 1 db.

Yes, it is complicated. Yes there will be "issues" which you will need to sort out when merging two stores into one database, since you are making the system work in a way it wasn't originally designed.

And as far as "going live" after doing upgrades and/or major code changes, you will want to have made REALLY GOOD notes about ALL the database changes and admin settings changes you made, so that you can "re-play" (or "redo" whatever you want to call it) them all again against the live database when you "go live" with your new code onto the live site.
If you use an old copy of the database then you'll of course lose everything that happened between the date of the old database and 'today'.
Discussed here, for example, in the context of upgrading: http://www.zen-cart.com/showthread.php?191080-Existing-product-files&p=1094802#post1094802

DrByte:

Yes, it is complicated. Yes there will be "issues" which you will need to sort out when merging two stores into one database, since you are making the system work in a way it wasn't originally designed.

Thanks DrByte - perhaps it would be more safe to have 2 separate databases, that are only connected by the product prices, titles and descriptions then. I'm sure there's some way of doing this, I will do some Googling. Some sort of XML feed system should do the trick me thinks - would be a really cool solution if I could end up figuring it out.

There's a "multisite" addon module that some folks have experimented with.

Just remember that when you make major changes to the code, you make your future upgrades far more difficult.

And if this is only for "mobile", then I submit that what you're talking about is serious overkill.

DrByte:

There's a "multisite" addon module that some folks have experimented with.

Just remember that when you make major changes to the code, you make your future upgrades far more difficult.

And if this is only for "mobile", then I submit that what you're talking about is serious overkill.

I've been at the mercy of being in a situation due to too many different customizations, that's not my problem.

But overkill? I think not - I've just noticed a flood of people accessing my store using things like Opera Mini and their Blackberry Browsers - and I feel I need to make the store easier for them to use.

My point was that setting up a separate store just to display things differently for mobile is like renting a second retail location next-door to your existing retail store just because you want to allow people to buy with cash instead of credit card.

My latest advice was about a safe way of making changes to the one installation for mobile friendliness, not about making two sites... though I didn't explicitly say that in the post:)

Yes, making changes to a single site to improve friendliness to customers, whether that's for mobile or anything else, is absolutely better than trying to make two separate stores and trying to make those two stores share anything.

There have been threads in the past year about ways of serving content differently to mobile and desktop users (or different-sized screens) for a single site. Some involved an automatic template switcher and some were more passive, stylesheet-based.