Смотрю в /etc/xrdp/sesman.ini — там в секции [Security] указана группа tsusers. Группа такая есть, а вот юзеров в ней нет, в том числе и того, которым я пытаюсь зайти. Интересно, это Ulteo нахулиганил? И из каких соображений? Я бы еще понял, если бы он там своего юзера прописал, но группа-то реально пустая. Странно.

Занес своего юзера в группу и все ОК, нормально вхожу. Только странно — раньше заходил в KDE, а теперь попал в Gnome. Интересно, это почему?

Однако я тут пытался настроить nginx для работы bbPress — не получилось. Наверное, недостаточно ковырялся. Но всему есть предел, если издержки оказываются слишком большими, стоит поискать другие решения. У меня не все пермалинки bbPress заработали, зато регулярно вылезали лишние редиректы.

С Buddypress ситуация еще сложнее. Если есть желание не ограничиваться форумами групп, которые эффективно реализованы на bbPress, входящем в состав Buddypress, а хочется устроить и глобальный форум, придется поломать голову с неопределенным результатом. Интеграция Buddypress с глобальным форумом пока не проработана, есть коллизии, с которыми придется повозиться. Я пока не сумел побороть эти проблемы, тем более с учетом настройки nginx. Так что ограничиваемся пока форумами групп и ждем развития Buddypress в направлении интеграции с глобальным форумом.

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

Вроде бы вот оно — RedBeanPHP. На первый взгляд похоже на игрушку. Есть большие сомнения насчет эффективности. Вопрос, годится ли это в качестве рабочей среды. Но вот в качестве ORM точно годится. Просто в освоении. Легкая и гибкая объектная модель. До поры можно вообще не думать о структуре базы. До той поры, пока не придет время сделать Freeze — заморозить структуру базы. Вот тут уже можно и делом заняться — нормализацией, оптимизацией… Главное, то что у меня вызывало тот самый барьер — сделано. Object-relational mapping.

Самый простой и обычный вариант — отправить себе по почте результат заполнения клиентом формы. Но часто идут дальше и пользуются клиентскими вызовами для того, что по идее надо делать кроном. Не будем сейчас дискутировать — плохо это или хорошо, факт, что так часто делают. Многие плагины вордпресса, например. Скажем, генерирующие посты из rss или datafeeds.

Но если уж и использовать клиентский запрос для того, что к нему прямо не относится, то желательно не обременять клиента ненужным ожиданием исполнения кода, не связанного с генерацией страницы. То есть надо исполнять такой код асинхронно.

Если мы уже работаем в связке nginx — php-fpm, то у нас есть для этого адекватное средство — функция fastcgi_finish_request(). Почему-то в PHP Manual она не упоминается, только в FastCGI Process Manager (FPM), и то мельком.

Итак, сразу после формирования клиентской части вызываем fastcgi_finish_request(), после чего спокойно и асинхронно занимаемся своими серверными делами — отправляем почту, забираем сторонний контент, апдейтим базу и пр. — клиента это уже не волнует.

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

Особенно если предусмотреть три фактора, обеспечивающих максимальную производительность SQLite:

1. Асинхронный режим

2. Журналирование в памяти

3. Транзакции