Как структурировать этот веб-проект Symfony?

Это трудно сказать, не зная фактических обязанностей каждого домена / приложения / независимо. Это то, на что вам приходится отвечать, основываясь на требованиях вашего проекта … нет единой стратегии, которую можно рекомендовать для каждого варианта использования.

С учетом сказанного я думаю, что в большинстве случаев у вас есть задачи из двух приложений: один будет служить интерфейсом, а также включать функциональность «членов». Резонанс, я думаю, что этот буксир, вероятно, является приложением sinlge, потому что вы хотите генерировать ссылки на один из другого (что невероятно сложно сделать, если они являются отдельными приложениями) – т.е. Каждый имеет доступ к домашней странице и отвечает на часто задаваемые вопросы, но только у пользователей есть доступ к Загрузкам или что-то еще, но все же они являются одним и тем же сайтом.

Другое приложение будет для бэкэнд и будет содержать функциональность администратора. Независимо от того, сколько приложений вы можете использовать один и тот же веб-каталог, создайте символическую ссылку, а затем укажите apache соответственно:

cd htdocs ln -s SF_ROOT_DIR/web frontend ln -s SF_ROOT_DIR/web backend 

Теперь вы можете указать свой набор cpanel в htdocs/frontend для domain.com и admin.domain.com и указать admin.domain.com на htdocs/backend .

Затем вы можете изменить свой .htaccess, чтобы выглядеть примерно так:

 Options +FollowSymLinks +ExecCGI <IfModule mod_rewrite.c> RewriteEngine On # we check if the .html version is here (caching) RewriteRule ^$ index.html [QSA] RewriteRule ^([^.]+)$ $1.html [QSA] RewriteCond %{REQUEST_FILENAME} !-f # no, so we redirect to our front web controller # if subdomain is admin.* then use backend.php application RewriteCond %{SERVER_NAME} ^admin\..*$ RewriteRule ^(.*)$ backend.php [QSA,L] # not admin so we use the frontend app RewriteRule ^(.*)$ index.php [QSA,L] </IfModule> 

Таким образом, вы должны иметь возможность использовать no_script_name с обоими приложениями.

Другой способ сделать то же самое – изменить index.php следующим образом:

 require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php'); if(0 === strpos($_SERVER['SERVER_NAME'], 'admin'){ $app = 'backend'; } else { $app = 'frontend'; } $configuration = ProjectConfiguration::getApplicationConfiguration($app, 'prod', false); sfContext::createInstance($configuration)->dispatch(); 

Вы можете изменить определение имени приложения, как вам нравится, но вы получите эту идею.

При использовании обоих подходов вы можете сделать базовое определение на основе субдомена, и вы можете применить эту стратегию независимо от количества приложений, о которых мы говорим, если вы используете только мои рекомендуемые 2 или если вы используете 3.

Альтернативный вариант – сделать одно домашнее приложение. Предполагая, что каждое из приложений – это всего лишь одна грань общего приложения, мне нравится идти по этому маршруту. Тем не менее, я бы рассматривал членов, нечленов и администраторов слишком широкое определение модулей.

Если бы вы сделали это так, вы могли бы в конечном итоге получить безумное количество действий в контроллерах. Вместо этого я бы сделал отдельные модули для реальных проблем. Кроме того, нет реальной причины использовать субдомены здесь – гораздо проще просто использовать сегмент URL (т. Е. / Admin или / members) для использования определенных модулей.

Например, позволяет пользователям … Обычно они становятся областью администрирования, поэтому мы можем использовать генератор UserAdmin для этой функции и вызывать модуль UserAdmin или что-то подобное. Тогда для материала userland мы могли бы просто иметь модуль User который обрабатывал бы просмотр и листинг общего профиля, редактирование профиля пользователями и все такое. Тогда для фактического входа у нас может быть модуль UserAuth который строго обрабатывает такие вещи, как login / logout и забытые запросы пароля, а что нет. Вы можете перенаправить любой URL-адрес на любой из этих модулей, поэтому ваша маршрутизация может выглядеть примерно так:

 user_login: url: /login params: {module: UserAuth, action: login} user_logout: url: /logout params: {module: UserAuth, action: logout} user_password: url: /forgot-password params: {module: UserAuth, action: recoverPassword} user_reset: url: /password/reset/:token params: {module: UserAuth, action: resetPassword} user_profile: url: /members/:username params: {module: user, action: showProfile} user_index: url: /members params: {module: User, action: index} user_default: url: /members/:action params: {module: User} admin_user: class: sfDoctrineRouteCollection options: Module: UserAdmin model: User prefix_path: /admin/user 

Последним шагом в этом направлении является обеспечение того, чтобы вы защищали соответствующие модули и действия с надлежащими требованиями к учетным данным в security.yml и чтобы вы также назначили учетные данные соответствующим образом.

Я думаю, что вы должны отделять свои приложения от общественности, участника и администратора. Маршрутизация будет выполняться с помощью apache: вы можете использовать 3 корня документа, указывающие на отдельные папки. Взаимодействие вашего кода можно сделать с помощью плагинов. Вы можете переопределить код плагина: для конкретного приложения, если вам нужно. Если доступ к общедоступным и доступным элементам имеет очень много общего, вы можете рассмотреть возможность использования одного и того же приложения для обоих обращений.

Я бы использовал два приложения symfony. Один для публики и членов, а затем отдельный для функций администратора. Если приложение очень сложно и сложно поддерживать, просто настроить защиту, чтобы только участники могли просматривать ограниченный контент.

Предполагая, что вы находитесь на виртуальной выделенной или подобной, настройка субдоменов выполняется в Apache. Если нет, и вы используете общий хост, то я считаю, что будет очень сложно настроить symfony для работы с субдоменами.