Потребовалось мне сделать optgroup в виджете choice, и не просто так, а с условием. Если у объекта есть дочерние элементы - то он становится optgroup, а иначе его можно выбрать. За основу я взял sfWidgetFormDoctrineChoiceNestedSet, который можно взять из плагина sfDoctrineNestedSetPlugin. Я скопировал код, добавил в запрос условие:

$query->addWhere('level = ?', 0);

Это потому, что все, что ниже уровнем мы будем получать через getChildren. Иначе нам пришлось бы двигать итератор Doctrine_Collection, что более сложно, заумно, и вовсе у меня не получилось (next($objects) почему-то не дает эффекта).
Сделать optgroup в choice совсем несложно, надо лишь сделать элемент массивом. Ну а что получилось собственно внутри поста.
Читать дальше...

Бывает, что находишь какое-то решение в Гугле, а потом когда я сталкиваешься с похожей ситуацией - второй раз уже не можешь найти. Поэтому я буду записывать моменты, которые мне были полезны и могут понадобиться еще, будет что-то вроде рубрики Symfony tips.

Как вообще убрать фильтры в admin generator?

config:
  filter:
    class: false

Как повесить иконку своему кастомному object_action?

#sf_admin_container ul li.sf_admin_action_##ACTION_NAME## a
{
  background: url(/images/icons/icon.png) no-repeat 0 0;
}

Как недопустить ввода пустой строки в админке?

public function configure() {
    $this->validatorSchema['name']->setOption('trim', true);
}

Fatal error: Call to undefined function include_component()
Вы, скорее всего, указали в settings.yml standart_helpers, и забыли добавить в список Partial.

all: 
  .settings: 
    standard_helpers:       [I18N, Partial]

Мне потребовалось сделать мультиязычный сайт аж на 5 языках. В целом тут нет ничего сложного, кроме того, что пользователю надо будет заполнять 5 форм на разных языках. Логичный вывод - сделать обязательным только один язык, например английский. Остальные заполняются по желанию, а для незаполненных показывается на том же английском. Промучившись некоторое время с рецептами от Календаря Адвента, и не добившись успеха, я нашел пост [Optional translation form for I18n objects with Symfony and Doctrine], который мне помог. Я считаю, что полезным будет сделать его перевод. Так же я добавлю некоторые свои комментарии. (Перевод вольный, эстеты идут лесом) Читать дальше...

Не так давно я писал про тогглеры (переключатели) в Symfony. Вчера я поработал над ними и существенно упростил их принцип работы, теперь они доступны в качестве плагина. Сразу же дам ссылку, вы можете их скачать в виде PEAR package и просто zip-архив. Дальше я расскажу как этим плагином пользоваться. Читать дальше...

Этим постом я отвечаю на вопрос в комментариях о том, как я реализовал стрелки вверх и вниз для категорий. Перейдем к делу Читать дальше...

Давно я не брал в руки шашек. То есть не писал про symfony. А разработка продолжается. Сайт фактически готов, остаются мелкие доделки, доработка напильником и все такое. О "переключателях" или "тогглерах"(togglers), или не знаю как еще их назвать я уже давно хотел написать. Ну вот и пришло время, получайте. Читать дальше...

Продолжаю серию постов про разработку на симфони. На этот раз задача состояла в том, чтобы сделать администрирование тегов. Задача:" все теги можно редактировать на одной странице, теги можно только редактировать и удалять, если тег после редакции совпадает с уже существующим - они склеиваются". Ну что ж, поехали. Читать дальше...

Этот пост не совсем про симфони. На самом деле я опишу, как реализовывал категории и подкатегории для сайта над которым тружусь уже около месяца. Но так как сам сайт создается на symfony, то без нее тут никуда. Задача стояла примерно такая: для удобной навигации и поиска по товарам их нужно отнести к различным категориям и подкатегориям. Количество как первых, так и вторых может быть бесконечно. Единственное ограничение - уровень вложенности, он равен двум. В тех.задании категории и подкатегории были описаны двумя таблицами. Я думаю, что если бы последовал этому - я бы сэкономил пару-тройку часов, однако же, мне пришла в голову идея сделать все в одной таблице. Ведь по сути эти сущности ничем не отличаются, только что подкатегории имеют родительские категории.

Читать дальше...

Продолжаю посты про symfony. Сегодня сделаем динамический роутинг. То есть будем добавлять правила роутинга из php, минуя routing.yml. Это нужно, например, если вы хотите делать страницы вида http://site.com/page1, где page1 может быть создана, может быть удалена и прочее. Дело в том, что указать какой-то общий шаблон нельзя, потому что иначе он будет конфликтовать с дефолтным /:module. Что делать? А вот что. Читать дальше...

Тем, кто изучает симфони известно, что админку часто делают через "generate:app backend". То есть мы создаем приложение внутри нашего проекта. Это прекрасно, но есть одно НО. Чтобы нам зайти в админку требуется писать http://project/backend.php/some-admin-pages. Можно конечно обьяснять заказчикам, что мол понимаете, это другое приложение внутри проекта, другой фронт-контроллер, так надо. Но лучше сделать иначе. Скажу сразу, этот метод взят с официального форума симфони. Но найти его проблематично.

Метод таков:

1. Создаем папку "admin" внутри папки "web". Копируем туда .htaccess из той же "web", и заменяем
   RewriteRule ^(.*)$ index.php [QSA,L]
   на
   RewriteRule ^(.*)$ ../backend.php [QSA,L]
2. Идем в настройки роутинга для backend (app/backend/config/routing.yml) и добавляем папку /admin/ ко всем роутам. Например:

   # default rules
   homepage:
   url: /admin/
   param: { module: default, action: index }

3. Меняем no_script_name на "on" в настройках backend (app/backend/config/settings.yml):
   prod:
   .settings:
   no_script_name: on
4. Чистим кеш и заходим в папку: http://project/admin/ без проблем.