Pojedyncza instalacja z wieloma bazami danych

Czy można wykonać jedną instalację, a dzięki tej instalacji stworzyć wiele sklepów z różnymi bazami danych?

Coś takiego: zrobię jedną instalację na domenie 1 z bazą danych, a od administratora stworzę nową stronę internetową i sklep na nowej bazie danych dla domeny 2 .

Wiem, że za pomocą jednej bazy danych można uzyskać wiele sklepów. Ale czy może być tak samo z różnymi bazami danych.

Świetna odpowiedź slarek. Zrobiliśmy coś bardzo podobnego. Zamiast edytować plik index.php, konfigurujemy osobne foldery poza bazą kodową magento i dołączamy mage.php z tych folderów, a następnie edytujemy plik etc_dir (i inne katalogi) jak w powyższej metodzie.

struktura folderów:

/ www / client1
/ www / client2
/ www / client3
/ www / clientX
/ www / magento

Wewnątrz każdego folderu klienta znajdują się:

• /www/clientx/etc/local.xml (ze zdefiniowaną unikalną bazą danych i unikalną bazą danych redis)
• / www / clientx / etc / modules (jest to link sym do / www / magento / app / etc / modules)
• /www/clientx/index.php

w /www/clientx/index.php

define('MAGENTO_ROOT', '/www/magento');

... (reszta index.php działa jak zwykle) ...

$client = isset($_SERVER['CLIENT_ID']) ? $_SERVER['CLIENT_ID'] : '';] Mage::run($mageRunCode, $mageRunType, array('etc_dir'=>'../'.$client));

Ustawiamy

$_SERVER['CLIENT_ID'] in Nginx with 
`fastcgi_param  CLIENT_ID clientx; `

Nie sądzę, że jest to możliwe po wyjęciu z pudełka. Magento obsługuje konfigurację bazy danych master / slave, ale musisz mieć je dla wszystkich sklepów.
I nie sądzę, że można to łatwo zrobić z niestandardowym kodowaniem, ponieważ sklepy są przechowywane w bazie danych.

Dlatego w zależności od widoku sklepu musisz wiedzieć, z którą bazą danych się połączyć, ale aby poznać widok sklepu, musisz wykonać zapytanie do bazy danych. Więc biegasz w kółko.

Chcesz mieć kilka oddzielnych sklepów z własnymi bazami danych przy użyciu pojedynczej bazy kodów?

Cóż, nie ma prostego i zalecanego sposobu, aby to zrobić. Biorąc to pod uwagę, możemy zobaczyć, co można zrobić:

Informacje o bazie danych pochodzą z pojedynczego pliku xml: app / etc / local.xml Ten plik jest ładowany z app / Mage.php, więc jeśli zmienisz ten plik, możesz teoretycznie zdecydować, który plik konfiguracyjny chcesz załadować (na podstawie pożądanego warunek, taki jak nazwa domeny). Voila, inna domena, inna baza danych. Teraz pojawia się część Bad News (tm).

1. Zastępujesz w tym celu kod podstawowy i tzw. „Boską klasę”. Jest to uważane za BARDZO ZŁĄ praktykę w świecie Magento! Za każdym razem, gdy uaktualnisz, zmiany zostaną zastąpione.
2. Nakładające się treści. Nie cała zawartość jest przechowywana w bazie danych, jest też folder multimediów i folder sesji (var / session), dla którego musisz znaleźć obejście (na przykład niestandardowe ścieżki oparte na bazie danych) lub zapisać zarówno obrazy, jak i sesje w bazie danych (wcześniej pytasz: tak, jest to możliwe).
3. Pamięć podręczna. Z pewnością nie chcesz, aby różne sklepy współdzieliły folder pamięci podręcznej (var / cache). Na szczęście możliwe jest użycie zewnętrznych pamięci podręcznych, takich jak memcached, zamiast przechowywania plików w tym folderze. Nadal musisz się upewnić, że twoje identyfikatory pamięci podręcznej się nie pokrywają, ponieważ jeśli tak, to będziesz w świecie bólu.
4. Nie możesz korzystać z kompilacji (i tak funkcja jest przestarzała).
5. Może coś jeszcze zapominam. Ktoś?

właśnie znalazłem to rozszerzenie:
https://github.com/steverobbins/Magento-Multi_Client

Magento Multi Client
Hostuj wielu klientów na tej samej podstawie kodu Magento.

Każdy klient ma swój plik local.xml i etc / modules.xml. Pozwala to określić osobne bazy danych i usługi buforowania dla klienta, a także włączyć / wyłączyć moduły zgodnie z żądaniem.

Każdy klient zachowuje swoją niezależność, ale dzieli bazę kodu.

Można to uznać za podejście Magento Go do hostingu stron Magento.

Musisz tylko utworzyć nowy folder, aby zawierał pliki konfiguracyjne, aw pliku index.php dodajesz tablicę opcji do Mage :: Run ().

W tym folderze będziesz mieć tę samą zawartość co app / etc /, w tym folder modułów.

Pierwsza domena:

Mage::run($mageRunCode, $mageRunType, array('etc_dir'=>'app/domain1'));

Druga domena:

Mage::run($mageRunCode, $mageRunType, array('etc_dir'=>'app/domain2'));

to powie Magento, gdzie są pliki konfiguracyjne dla domeny.

Jaki jest twój główny cel? Inny obszar administracyjny lub łatwiejsza obsługa kodu źródłowego?

Zrobiłbym to z mieszanką „lokalnych” katalogów i plików oraz połączonych (ln-s) wspólnych katalogów i plików

/ www / common / www / shop1 / www / shop2

pospolity

• aplikacja /
• js /
• lib /
• ...

"lokalny"

• / var /
• index.php
• .htaccess
• app / etc / local.xml

Ale może być trochę mylące.