У нас есть продукт, разработанный в PHP Symfony. Сейчас у нас есть несколько клиентов, для которых мы поддерживаем разные базы кода и базы данных (MySql).
Они получают доступ к своей соответствующей кодовой базе, используя поддомен, такой как client1.myproduct.com и client2.myproduct.com
Теперь мы хотим создать единую базу кода для обоих клиентов и сохранять только файлы, которые являются разными (с точки зрения логики) для обоих из них в отдельных поддоменах.
Таким образом, оба поддомена будут указывать на одну и ту же базу кода, но при необходимости будут получать доступ к файлам из своих соответствующих поддоменов, т. Е. Всякий раз, когда логика отличается для некоторой функции для обоих клиентов.
Может ли кто-нибудь предложить, что это лучший способ сделать это?
сайты: [foo.com, bar.co.uk, http://www.mike.es]
// index.php require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php'); // get the domain $domain = $_SERVER['SERVER_NAME']; // get rid of www, com, es etc ... foreach(array('www.', '.com', '.es', '.co.uk') as $crap) { $domain = str_replace($crap, '', $domain); } $confs = array( 'foo' => 'somefoo', 'bar' => 'somebar', 'waz' => 'andwazconfig' ); $cfg = (!empty($confs[$domain])) ? $confs[$domain] : 'default'; $configuration = ProjectConfiguration::getApplicationConfiguration($cfg, 'prod', false); sfContext::createInstance($configuration)->dispatch(); // End of index.php Надеюсь это поможет
Да, вы можете это сделать. Symfony Routing может обрабатывать этот прецедент, но это не одна из самых простых задач. Для более подробного описания взгляните на Symfony-Documentation: http://www.symfony-project.org/more-with-symfony/1_4/en/02-Advanced-Routing
Я описал использование динамических поддоменов в Symfony здесь, используя sfDomainRoutePlugin.
Однако вам потребуется переписать большую часть вашей существующей логики приложений для поддержки нескольких клиентов в одном приложении, и вы также должны объединить две старые базы данных.
Я запросил ту же информацию и получил возможность получить ответ Майка и Фабиня. Вот подробности:
Для одной логики с субдоменами: http://trac.symfony-project.org/wiki/HowToDoMultipleSitesWithSingleCore
Несколько сайтов на основе идентичных конфигураций Это может быть странная тема, но я хотел бы настроить наш доступ в субдоменах, все с доступом SSL. Нам нужны разные сайты, потому что SSL заставляет виртуальные домены на основе IP, что означает для нас разные корни документов. Такие как:
• http://www.mydomain.com • admin.mydomain.com • parents.mydomain.com Однако это были все сайты с одинаковой схемой ядра и плагинами. Преимущество этой конфигурации:
• Общие файлы модели: все классы XxxPeer будут связаны между приложениями. Недостаток:
• Теперь у вас есть 2-n различных кешей / журналов для мониторинга. Если вы посмотрите на типичную структуру каталогов Symfony, ее можно разбить на две группы типов:
• Общие каталоги: ◦batch ◦config ◦data ◦doc ◦lib ◦plugins ◦test • Конкретные справочники приложений: ◦apps ◦cache ◦log ◦web Вот шаги, которые я предпринял:
• Разработайте схему и сайт http://www.yourdomain.com. Как только это начинает объединяться, вы можете начать разработку дополнительных сайтов. • На новом сайте символическая ссылка Общие каталоги • На новом сайте создайте каталоги конкретных приложений ◦NOTE: в веб-каталоге вам может потребоваться скопировать некоторые из исходных материалов (css, js и .htaccess файлы приходят на ум). Держите это в глубине своего разума, когда начинаете поднимать новый сайт. • Запустите команду symfony fix- perms ◦NOTE: для меня Virtualmin создает эти новые сайты с новыми именами пользователей. Вы должны будете гарантировать, что все каталоги конкретных приложений принадлежат этому имени пользователя, поэтому ваши команды с четким кэшем и команды ведения журнала работают. • Теперь у вас настроен проект. Вы начинаете с выполнения: ◦symfony app MYAPP ◦symfony module MYAPP MYMODULE ◦ … • Теперь вы обнаружите, что ваши приложения / MYAPP / modules / MYMODULE созданы, и у вас есть полный равноправный доступ ко всей базе данных
Здесь вы найдете одну логику с разными именами доменов: client1.com client2.com, используя те же приложения.
Для одной логики с разными доменами: «Вы можете указать их все на одном фронт-контроллере, а затем использовать фильтр или родительский класс действия, чтобы делать такие вещи, как изменение шаблона сайта и т. Д. Однако наличие переднего контроллера на домен может быть больше эффективный, и это отличный способ.
Каждый домен может иметь свое собственное приложение, но основная часть логики должна быть реализована в плагинах, поэтому они могут быть включены для каждого домена / приложения, которые им нужны, и разделяются по мере необходимости. Я думаю, сколько кода требуется для каждого приложения, зависит от того, насколько разные сайты на самом деле. "