Небольшой сборник рецептов (или же мини тестов), которые желательно выполнять перед развертыванием symfony-проектов. Часть 3-я.

Удалите .htaccess, везде где это возможно

Файлы .htaccess как правило очень удобны – гибкие, работают везде, изменения можно протестировать тут же. Но обратная сторона медали в том, что правила из .htaccess не могут быть закешированы на уровне apache, сервер вынужден сканировать файловую систему проекта (docroot) для каждогозапроса.

Если вы переместите правила из .htaccess в конфигурацию виртуального хоста в httpd.conf (или подлинкованном к нему файле с виртуальными хостами), эти правила будут кэшироваться apache, что увеличит производительность.

К сожалению, не всегда имеется доступ к конфигурации apache. В частности, на виртуальном shared-хостинге, вот почему symfony по умолчанию использует .htaccess файл по-умолчанию.

Так что, извините, этот совет можно применить только на dedicated сервере (VPS/VDS тоже в доле).

Итак, откройте ваш конфиг с виртуальными хостами:

Часто, конфигурации виртуальных хостов помещают в конце httpd.conf (или делают Include отдельного файла, например vhosts.conf или conf.d/vhosts.conf).

Ваш виртуальный хост может выглядеть примерно так:

<VirtualHost *:80>
  ServerName my-symfony-project.com
  DirectoryIndex index.php
  DocumentRoot "/path-to-your-sf-project/web"
  <Directory "/path-to-your-sf-project/web">
    AllowOverride All
    Allow from All
  </Directory>
  Alias /sf /path-to-your-sf-project/lib/vendor/symfony/data/web/sf/
  <Directory "/path-to-your-sf-project/lib/vendor/symfony/data/web/sf/">
    AllowOverride All
    Allow from All
  </Directory>
</VirtualHost>

Вам нужно добавить ваши правила в секцию <Directory “/path-to-your-sf-project/web”>

<Directory "/path-to-your-sf-project/web">
  AllowOverride None
  Allow from All
  Options FollowSymLinks ExecCGI

  RewriteEngine On

  # uncomment the following line, if you are having trouble
  # getting no_script_name to work
  #RewriteBase /

  # we skip all files with .something
  #RewriteCond %{REQUEST_URI} ..+$
  #RewriteCond %{REQUEST_URI} !.html$
  #RewriteRule .* - [L]

  # 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
  RewriteRule ^(.*)$ index.php [QSA,L]
</Directory>

Сохраните конфиг и удалите ваш .htaccess файл – если вы не модифицировали этот файл под ваши нужны, он теперь не нужен.

Тестирование изменений и рестарт apache

Apache имеет встроенный инструмент тестирования конфигурации на предмет синтаксических ошибок: configtest.

На большинстве linux-серверов вы можете запустить утилиту управления apache следующим образом:

/etc/init.d/apachectl configtest
или
/etc/init.d/httpd configtest

Документируйте!

Ваш проект должен иметь как минимум один README файл, где вы можете описать особенности настройки проекта и вебсервера.

Этот совет был предложен Jérôme Macias тут http://forum.symfony-project.org/index.php/m/81968/#msg_81968

Логгирование ошибок

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

В apps/frontend/config/settings.yml активируйте опцию:

prod:
  .settings:
    logging_enabled:    true

Потом, в apps/frontend/config/factories.yml внесите следующий изменения:

prod:
  logger:
    class: sfAggregateLogger
    param:
      level: err
      loggers:
        sf_file_debug:
          class: sfFileLogger
          param:
            level: err
            file: %SF_LOG_DIR%/%SF_APP%_%SF_ENVIRONMENT%.log

И очистите кэш:

php symfony cc

Не забудьте настроить cron-job для логгирования логов (можете посмотреть в сторону logrotate). Документация по логгированию: http://www.symfony-project.org/jobeet/1_4/Doctrine/en/22#chapter_22_sub_logging.

Правка deployment списков

Скрипты для тестового окружения в продуктовую среду попасть не должны!

Для того чтобы на продуктовый сервер попали только продуктовые скрипты, symfony предоставляется два инструмента для этого:

• команду php symfony project:clear-controllers
• файл myproject/config/rsync_exclude.txt

rsync_exclude.txt по-умолчанию фильтрует скрипты, относящиеся к dev-окружению. Но вы также можете добавить свои исключения:

/web/*_cache.php
/web/*_test.php

Также можете добавить такие некритичные файлы:

Thumbs.db
.DS_Store

Не забудьте также защитить продуктовую БД

Вы также можете добавить следующие файлы в rsync_exclude.txt:

/config/databases.yml
/data/sql/schema.sql

Escaping для шаблонов

Бесполезно для проектов на symfony 1.3/1.4

По-умолчанию, output escaping отключен. В файле /apps/frontend/config/settings.yml добавьте:

all:
  .settings:
    # Output escaping settings
    escaping_strategy:      true
    escaping_method:        ESC_SPECIALCHARS

Защита форм

Бесполезно для проектов на symfony 1.3/1.4

symfony имеет возможность защищать каждую форму в приложении от CSRF атак. Для того чтобы подключить эту возможность, вы должны указать csrf ключ в apps/frontend/config/settings.yml

all:
  .settings:
    csrf_secret:       chooseYouOwnSecretKey

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

Отображайте сообщение “Сайт недоступен” на время работ

Чем больше ваш сайт, тем медленне работают некоторые таски symfony. В некоторых случаях, эти операции могут значительно замедлить ваше приложение и помешать нормально работе пользователей.

Отображать некую страницу, которая будет предупреждать пользователя о ведущихся на сайте работах, это наилучший выход в данной ситуации.

Для того чтобы настроить перенаправление пользователей на страницу unavailable.php, в то время когда вы выполняете так типа php symfony cc, внесите изменения в apps/frontend/config/settings.yml:

all:
  .settings:
    check_lock:    true

Оптимизация маршрутизации

Система маршрутизации symfony – это одна из убийственных фич этого каркаса.

<p>Please have a look on <php echo link_to('our products', 'product/index') ?>.</p>

Укажите в вашем шаблоне, какие модуль/действие вам нужны и предоставьте маршрутизатору сделать все остальное.
Вы можете использовать правило по-умолчанию:

default:
  url:   /:module/:action/*

Или добавить свое собственное

product_list:
  url:     /our-products
  param:   { module: product, action: index }

Очистите кэш и все соответствующие ссылки и URI будут изменены.

Выглядит как магия, но маршрутизация имеет свою цену.

Каждый раз, когда при обработке запроса в шаблоне встречается product/index, symfony сканирует все правила, определенные в routing.yml и определяет, какое из них будет обрабатывать запрос: правило по умолчанию? или какое-то другое?

Этот процесс повторяется для каждой ссылки…

Если у вас много страниц и много правил маршрутизации, вы можете увеличить производительность вашего приложения, используя метки маршрутов, вместо пары module/action:

<p>Please have a look on <php echo link_to('our products', '@product_list') ?>.</p>

Это решение позволит ускорить процесс маршрутизации, но сделает представление ссылок в коде менее читабельным.

Небольшой сборник рецептов (или же мини тестов), которые желательно выполнять перед развертыванием symfony-проектов. Часть 2-я.

Favicon

Браузеры запрашивают favicon.ico файл, когда юзер в первый раз посещает страницу и впоследствии использует его для отображения в адресной строке и в меню закладок. Этот файлик не только делает внешний вид вашего сайта целостным, но и позволяет визуально отделять его от других сайтов в закладках, добавляет уникальности.

Вот несколько полезных ссылок для создания иконок:

• Пустой favicon
• Генератор favicon
• Еще один генератор

Имена кукисов

Механизм сессий использует куки на стороне клиента и эти куки по умолчанию именуются symfony. В apps/frontend/config/factories.yml добавьте следующие строки для всех окружений:

storage:
  class: sfSessionStorage
  param:
    session_name: my_project

Если у вас используется sf[Doctrine]GuardPlugin, вы можете изменить имя куки “Remember me” в myProject/config/app.yml

all:
  sf_guard_plugin:
    remember_cookie_name:   myProjectRememberMe

Проверка продакшн сервера

Для проверки того, корректно ли настроен сервер для symfony-проекта, ребята из Sensio написали тестовый скрипт. Загрузить его можно здесь: http://svn.symfony-project.com/branches/1.4/data/bin/check_configuration.php. Поместите его в web-директорию (зачем именно туда непонятно, так как тестируются общие настройки). Выполните скрипт:

$ php check_configuration.php

********************************
*                              *
*  symfony requirements check  *
*                              *
********************************

php.ini used by PHP: Z:usrlocalphp5php.ini

** WARNING **
*  The PHP CLI can use a different php.ini file
*  than the one used with your web server.
*  (especially on the Windows platform)
*  If this is the case, please launch this
*  utility from your web server.
** WARNING **

** Mandatory requirements **

  OK        PHP version is at least 5.2.4 (5.2.4)

** Optional checks **

  OK        PDO is installed
  OK        PDO has some drivers installed: mysql
  OK        PHP-XML module is installed
  OK        XSL module is installed
  OK        The token_get_all() function is available
  OK        The mb_strlen() function is available
  OK        The iconv() function is available
  OK        The utf8_decode() is available
  OK        A PHP accelerator is installed
[[WARNING]] php.ini has short_open_tag set to off: FAILED
            *** Set it to off in php.ini ***
[[WARNING]] php.ini has magic_quotes_gpc set to off: FAILED
            *** Set it to off in php.ini ***
  OK        php.ini has register_globals set to off
  OK        php.ini has session.auto_start set to off
  OK        PHP version is not 5.2.9

Соответствующую документацию можно почитать тут: http://www.symfony-project.org/getting-started/1_4/en/02-Prerequisites.

Языковые настройки

По умолчанию, symfony помещает lang=en на каждую страницу вашего проекта. Если ваше приложение работает с другими языками, отредактируйте apps/frontend/templates/layout.php следующим образом:

<html
  xmlns="http://www.w3.org/1999/xhtml"
  xml:lang="<?php echo $sf_user->getCulture() ?>"
  lang="<?php echo $sf_user->getCulture() ?>"
>

Удаляем /backend.php/ из URI

В файле apps/frontend/config/settings.yml вы можете скрыть отображение имени bootstrap скрипта при помощи опции no_script_name. Эта опция включена для первого сгенерированного рпиложения (как правило frontend) и отключена для последующих.

Почему?

Потому что без указания backend.php (ну или грубо говоря имени приложения через скрипт), symfony не может понять, какое из приложений запускать. Обратите внимание на web/index.php:

<?php

require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);
sfContext::createInstance($configuration)->dispatch();

Явно указано приложение (frontend) и окружение (prod). Т.о. мы должны придумать как указать symfony нужное приложение, не используя для этого backend.php явно.

Мы можем, например, использовать разные домены:

• http://my-app.com для фронтэнда
• http://my-app-backend.com для бэкэнда

Или, что еще лучше, для бэкэнжа можно использовать поддомен:

• http://my-app.com для фронтэнда
• http://admin.my-app.com для бэкэнда

Если ваш проект размещен на выделенном сервере

Вам нужно добавить новый виртуальный хост в httpd.conf:

<VirtualHost *:80>
  ServerName admin.my-app.com
  DirectoryIndex backend.php
  DocumentRoot "/path/to/the/web/directory"
  <Directory "/path/to/the/web/directory">
    AllowOverride All
    Allow from All
  </Directory>
  Alias /sf /path/to/the/symfony/data/web/sf
  <Directory "/path/to/the/symfony/data/web/sf">
    AllowOverride All
    Allow from All
  </Directory>
</VirtualHost>

Если ваш проект расположен на виртуальном хостинге

В этом случае у вас скорее всего нет доступа к http.conf и единственный доступный способ конфигурирования – это .htaccess. Добавим после строк:

<IfModule mod_rewrite.c>
  RewriteEngine On

Следующие строки:

# The admin subdomain returns to the backend
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP_HOST} ^admin.my-app..*
RewriteRule ^(.*)$ backend.php [QSA,L]

И, наконец,

можно модифицировать settings.yml:

prod:
  .settings:
    no_script_name:  true

И очистить кэш:

php symfony cc

PHP акселератор

Для продуктового сервера вам нужна максимальная производительность. Установка акселератора (вики-статья про акселераторы http://en.wikipedia.org/wiki/PHP_accelerator) даст хороший прирост производительности при малых затратах. Одним из популярных акселераторов является APC (Advanced PHP Cache – http://www.php.net/apc).

Установка на выделенный сервер

Процесс установки APC на выделенный сервер прост насколько это вообще возможно ))

pecl install apc

Виртуальный хостинг

Как правило поставить что-то на виртуальном хостинге нельзя. Но в Doctrine ORM вы можете включить встроенный механизм кэширования. Включить кэширование можно добавив следующий метод в mySfProject/config/ProjectConfiguration.class.php (документация: http://www.doctrine-project.org/documentation/manual/1_2/en/introduction):

/**
 * Configure the Doctrine engine
 **/
public function configureDoctrine(Doctrine_Manager $manager)
{
  $manager->setAttribute(Doctrine::ATTR_QUERY_CACHE, new Doctrine_Cache_Apc());
}

P.S. Установка eAccelerator для PHP5 под Windows http://hudson.su/?p=808 (хотя для posix систем принцип тот же, из исходников вы вряд ли его будете собирать, yum install или apt get…)

Оставайтесь с нами, окончание следует ))

Небольшой сборник рецептов (или же мини тестов), которые желательно выполнять перед развертыванием symfony-проектов.

Страница “Oops! Page Not Found”

Когда запрошенный URL не соответствует ни одному маршруту или когда вызывается sfError404Exception, symfony пытается отобразить действие default/error404:

Для того чтобы облагородить эту страницу, добавьте метод executeError404() в класс apps/frontend/modules/default/actions/actions.class.php:

/**
 * Error page for page not found (404) error
 *
 */
public function executeError404()
{
}

После этого создайте шаблон apps/frontend/modules/default/templates/error404Success.php. Если хотите, можете взять оригинальный файл и модифицировать его под ваш дизайн.

Теперь нужно протестировать, как будет выглядеть ваша страничка 404. Возьмите одно из действий проекта, которое работает и добавьте в его начале строку:

// тестовый эксепшн
throw new sfError404Exception('Only for test, don't forget to remove it!');

После этого вы можете протестировать соответствующую страницу в продуктовом окружении. Если в вашем приложении модуль default защищен – нужно убедиться, что действие error404 не является защищенным: в файле apps/frontend/modules/default/config/security.yml проверяем (или добавляем) следующие стоки:

error404:
  is_secure: false

Вы также можете использовать другой модуль. Для этого модифицируйте apps/frontend/config/settings.yml:

all:
  .actions:
    error_404_module: foo   # To be called when a 404 error is raised
    error_404_action: bar   # Or when the requested URL doesn't match any route

После этого остается только очистить кэш:

php symfony cc

Страница “Oops! An Error Occurred”

Эта страница отображается в продуктовом окружении когда symfony перехватывает ошибку.

Symfony ищет файл error.html.php и у вас есть выбор, где его разместить:

1. В mySfProject/apps/frontend/config/error/error.html.php. Имеет смысл в случае, когда у вас планируется отдельная версия для каждого приложения (app).
2. В mySfProject/config/error/error.html.php.

Если хотите, вы можете взять оригинальный файл и изменить его.

Для того чтобы протестировать страницу ошибки в любое действие добавьте строку:

throw new Exception('Only for test, don't forget to remove it!');

Протестируйте соответствующую страницу в продуктовом окружении.

Страница “Login Required”

Когда неаутентифицированный пользователь пытается открыть страницу, которая объявлена как secure в security.yml, symfony пытается отобразить действие default/login:

Для того чтобы изменить внешний вид этой страницы, добавьте метод executeLogin() в класс apps/frontend/modules/default/actions/actions.class.php:

/**
 * Warning page for restricted area - requires credentials
 */
public function executeLogin()
{
}

Затем нужно создать шаблон apps/frontend/modules/default/templates/loginSuccess.php.

Если хотите, можете взять оригинальный файл и модифицировать его.

Для того, чтобы протестировать эту страницу нужно:

1. Перейти в продуктовое окружение
2. Разлогиниться (используйте линк logout или же, если у вас его нет, удалите все куки для домена с вашим приложением (в firefox можете воспользоваться плагином web developer)).
3. Откройте защищенную страницу.

Используем отдельный модуль. Для этого модифицируем apps/frontend/config/settings.yml:

all:
  .actions:
    login_module: foo   # To be called when a non-authenticated user
    login_action: bar   # Tries to access a secure page

Убедитесь, что foo::bar не защищенное действие (мы ведь хотим показывать эту страницу незалогинившимся пользователям!) – проверьте или добавьте в apps/frontend/modules/foo/config/security.yml следующие строки:

bar:
  is_secure: false

После не забудьте очистить кэш:

php symfony cc

Соответствующая документация для 1.2, для 1.4 doctrine, 1.4 propel.

Страница “Credentials Required”

Когда пользователь не имеет необходимых прав доступа (credentials) для действия, symfony пытается отобразить действие default/secure:

Для того чтобы настроить внешний вид этой страницы, добавьте метод executeSecure() в apps/frontend/modules/default/actions/actions.class.php:

/**
 * Warning page for restricted area - requires login
 */
public function executeSecure()
{
}

и создайте шаблон apps/frontend/modules/default/templates/secureSuccess.php. Если хотите, можете взять оригинальный файл и модифицировать его.

Теперь нужно протестировать экшен. Для этого нужно:

1. Перейти в продуктовое окружение
2. Войти в систему, но не как super admin
3. Для одного из модулей добавить в apps/frontend/modules/yourModule/config/security.yml:

all:
  credentials: [ aCredentialYouDontHave ]

4. Очистить кэш
5. Открыть любое из действий данного модуля

Если вы хотите использовать другой модуль, модифицируйте apps/frontend/config/settings.yml:

all:
  .actions:
    secure_module: foo   # To be called when a user doesn't have
    secure_action: bar   # The credentials required for an action

И очистите кэш

php symfony cc

Страница “This Module is Unavailable”

Когда пользователь пытается вызвать действие из модуля, который объявлен как disabled, symfony пытается отобразить действие default/disabled:

Для того чтобы настроить внешний вид этой страницы, добавьте метод executeDisabled() в apps/frontend/modules/default/actions/actions.class.php:

/**
 * Module disabled
 *
 */
public function executeDisabled()
{
}

и создайте шаблон apps/frontend/modules/default/templates/disabledSuccess.php. Если хотите, можете взять оригинальный файл и модифицировать его.

Теперь нужно протестировать отключенный модуль. Для этого нужно:

1. Перейти в продуктовое окружение
2. Для одного из модулей добавить в apps/frontend/modules/yourModule/config/module.yml:

all:
  enabled: false

3. Очистить кэш
4. Открыть любое из действий данного модуля

Если default модуль защищен, убедитесь что действие disabled доступно пользователям – проверьте или добавьте в apps/frontend/modules/default/config/security.yml следующие строчки:

disabled:
  is_secure: off

Если вы хотите использовать другой модуль, модифицируйте apps/frontend/config/settings.yml:

all:
all:
  .actions:
    module_disabled_module: foo   # To be called when a user requests
    module_disabled_action: bar     # A module disabled in the module.yml

И очистите кэш

php symfony cc

Страница “Website Temporarily Unavailable”

Вебсайт может отображаться как “недоступный” если:

• приложение отключено через таск php symfony project:disable
• В процессе очистки кэша, если опция check_lock включена в settings.yml.

В этих случаях symfony ищет файл unavailable.php и вы можете разместить его в следующих местах:

1. В mySfProject/apps/frontend/config/unavailable.php (имеет смысл, если у вас будут разные версии для разных приложений)
2. В mySfProject/config/unavailable.php

Если хотите, вы можете взять оригинальный файл и модифицировать его.

Не забывайте очистить кэш.

Чтобы протестировать эту страницу, нужно отключить фронтэнд и dev окружении:

php symfony project:disable frontend dev