Magento

I have scoured the forums for the answer to this, but to no avail. Many threads come close to answering my question, but I have not found a definitive answer. Here is my situation:

I want to set up multiple websites with different domains on the same host sharing a single database. The screencast looked promising: http://www.magentocommerce.com/blog/comments/video-creating-multiple-online-storefronts-part1/.

However, I quickly discovered that I cannot copy index.php to my secondary domain’s DocumentRoot, and edit it to include Mage.php from my primary domain’s Magento installation. The reason is that my web host does not allow PHP to include files from outside a given VirtualHost’s document root. This is similar to being chroot jailed, but in this case my hosting company has set some PHP-level security constraints that do more or less the same thing (setting open_basedir, for example). I cannot change this.

This thread mentioned something similar: http://www.magentocommerce.com/boards/viewthread/5879/. The advice then was to install Magento on both domains, and have them share a database. I have seen this suggested on other threads too. But has this ever been tested? I don’t see how to do this documented anywhere, and when I try it, the installer gets confused.

I followed Moshe’s advice from this thread: http://www.magentocommerce.com/boards/viewthread/10282/. When I go to install Magento on the second site using the same db connection parameters, the installer wants to switch to the primary domain halfway through, or it starts the install process all over again.

Has anyone successfully set up multiple domains with their own Magento installations and a shared database?

Try this:

1. Complete 1st domain installation
2. copy app/etc/local.xml from 1st domain copy to 2nd domain copy - you will not need to go through install wizard on 2nd domain.
3. In Admin Create another website and/or store, note the store view code.
4. Edit 2nd domain’s index.php: Mage::run(’domain2_code’); #(replace with store view code)

I tried copying the index.php and .htaccess and local.xml to a separate folder and have successfully created a new store view.  When i load the site at: http://localhost/newstore it would load up fine, but when i load a new category, http://localhost/newstore/newcat i would get the page not found error message.  But if i add the store name query string to the endof the url path, it would load the category perfectly fine...http://localhost/newstore/newcat?store=newstore

What am i doing wrong?

Did you follow the steps in this post TO THE LETTER?

http://www.magentocommerce.com/boards/viewreply/25061/

This information is elsewhere in the Magento supplied docs and webcasts, but this was the first that I could quickly relocate.

Strangely, I’ve had the effect of having everythng work perfectly in a same-server, multi-store setup then after turning OFF cache everything points to the main store. Fiddling with cache in various ways has not restored the system to its prior working goodness. Hmmm…

Kalqlate,

Not sure if this will help but Nicola was very kind enough to give me a hack for this in the .htaccess file. It will re-direct your URL’s to the /store and force the thing to work.

http://www.magentocommerce.com/boards/viewthread/7178/P30/#t39833

Thanks, lindaw.

No success here. I read through the other thread that you referenced and I feel your pain.

I’ve been debugging the issue for the past several hours. I think it’s time for a re-install.

Something tells me that multiple stores handling in Magento is quite fragile at the moment. I attempted to track a secondary store in the database that at one time was somewhat stable (only “somewhat” because a customer login registered to that store sometimes redirected to the main store instead for unknown reasons) and found that the store’s reference was dropped at some point in the EAV chain. It seems that somehow the system became oblivious to it ever having existed. I’ve checked and double-checked the folder layout, .htaccess and index.php files, and all is in order there. The only remaining factor is the contents of the database.

Hopefully Team Magento is tracking this problem in its various flavors and will test and debug each use case soon (among all of the other things they’ve got on their plates). I believe Magento will be great once we get through the expected infancy phase.

Hey Kalqlate,

I feel yours more, that last one at least fixed (hacked) it for me.

So do you have 1 website, 2 stores and 2 different domains?

Great! I’m glad the hack worked for you.

Actually, I’m feeling no pain, other than debug time, as I’m still in the getting-to-know-you phase with Magento and I’m only running in a test environment.

Regarding my configuration: Single domain, 2 “websites” (folders), 2 stores.

Mainstore: http://www.domain.com/
Store2:  http://www.domain.com/store2/
Store3:  http://www.domain.com/store3/

My goal is to have separate stores arranged this way where each store selectively enables product categories from a common database.

Again, at one point everthing was close other than customer login occassionally being misguided to the root store. The only thing that I can think of that triggered the state of no longer being able to access or login to the secondary stores was turning off the cache feature.

With the new install I’ll track everything a bit more closely and file a bug report with definitive scenarios.

Thanks for caring, lindaw!

(Actually, I had thought to comment in my prior post that one of the things that will help make Magento great, beyond the wizards at Varien, is a great community of people helping people!)

Yeah this forums pretty good for that. I’ve received so much help it’s only fair I at least try even though I’m so unsure sometimes.

Only there are more people who have less of an idea than the people that do have an idea given that Magento is fresh. That’s the hardest part.

My set-up is different to yours so yeah, I can’t really offer sound advice. You sound like you know what you’re doing though and I’m sure you’ll have it sorted in no time.