Plugins that are the base for 'SNS BASE Plugin'

sfSimpleBlogPlugin (Weblog)
http://trac.symfony-project.com/wiki/sfSimpleBlogPlugin

sfGuardPlugin (User management)
http://trac.symfony-project.com/wiki/sfGuardPlugin

sfSimpleCMSPlugin (CMS)
http://trac.symfony-project.com/wiki/sfSimpleCMSPlugin

sfMediaLibraryPlugin (Image management)
http://trac.symfony-project.com/wiki/sfMediaLibraryPlugin

sfLucenePlugin (Search engine)
http://trac.symfony-project.com/wiki/sfLucenePlugin

adBlueprintPlugin (CSS framework)
http://trac.symfony-project.com/wiki/adBlueprintPlugin

sfCryptographpPlugin (Captcha)
http://trac.symfony-project.com/wiki/sfCryptographpPlugin

sfNiftyPlugin: Provide helpers for Nifty Round Cube, to round corners of html elements.
http://trac.symfony-project.com/wiki/sfNiftyPlugin

sfOpenIDPlugin: Consumer for OpenID
http://trac.symfony-project.com/wiki/sfOpenIDPlugin

sfPHPUnitPlugin: PHPUnit test suite integration with symfony
http://trac.symfony-project.com/wiki/sfPHPUnitPlugin

sfPropelActAsNestedSetBehaviorPlugin: Implements nested sets for Propel objects.
http://trac.symfony-project.com/wiki/sfPropelActAsNestedSetBehaviorPlugin

The sfSwiftPlugin is a symfony plugin that provides e-mail sending capabilities through the use of the Swift Mailer library http://www.swiftmailer.org/.
http://trac.symfony-project.com/wiki/sfSwiftPlugin

Самое главное правило:

НЕ ТРОГАТЬ ВНУТРЕННОСТИ ПЛАГИНОВ!!! НИКАКИЕ!!! :)

Главная особенность системы должна быть в следующем:

Чтобы поставить социальную сеть на только что созданный Symfony проект, надо по очереди проинсталить эти плагины, выполнить все действия, указанные в их readme файлах.

Потом проинсталить НАШ sfSNSBasePlugin, в котором будут настройки, которые оверрайдят настройки плагинов выше, собирая их в одно целое.

Апдейт от 13.02.2008, 22:52

Сделал настройку конфигурации рутинга и settings.yml для плагина sfGuardPlugin из плагина sfSNSBasePlugin.

Как именно:

рутинг засунул в sfSNSBasePlugin/config/routing.yml
настройки settings.yml засунул в sfSNSBasePlugin/config/settings.yml

прошу заметить, что prepending routes в config.php закоменчены.

Плагин, это, по сути, обычный symfony application.
Тоесть, фаловая структура там такая же как и в application-е.

Можно сделать модуль например sfSNSBasePlugin/modules/sfGuardAuthBlah,
actions которого будут наследником actions sfGuardPlugin.

пример:

require_once(dirname(__FILE__).'/../../../../sfGuardPlugin/modules/sfGuardAuth/actions/actions.class.php');

class sfGuardAuthPlusActions extends sfGuardAuthActions
{
... тут мы делаем override екшенов или добавляем новые екшены (расширяем функционал)
}

и потом в sfSNSBasePlugin/config/routing.yml написать что-то типа

sf_guard_blah_signin:
url: /login
param: { module: sfGuardAuthBlah, action: signin }
и когда в броузере запросят /login то вызовется екшен нашего плагина, а не sfGuardPlugin, но главный функционал будет из sfGuardPlugin.

Касательно View:

Если в нашем плагине создать модуль как в примере сверху и в нём в папке templates создать темплиты для екшенов модуля, то вызываться будут они, а не темплиты родительского плагина.
Таким образом, можно создавать собственный UI для любого плагина (или applicationa) не трогая внутренности оригинальных поагинов.