Максим Федоров

Лезу в класс Main и вижу что метода sayHelloWorld в нём нет. Логически понятно что он не в родителе т.к. было бы другое обращение (через parent::) но это всё равно несколько сбивает с толку, особенно если слово use не сразу заметишь

Установите нормальное IDE и не будет никаких проблем, например в том же PHPStorm кликнув на методе Вы сразу можете перейти к его реализации без лишних поисков и телодвижений

Есть ли какие-то best practice и негласные соглашения по их использованию, например писать метод $o->sayHelloWorldTrait(); тогда уже по названию метода понятно и что он делает и откуда берётся.

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

В какой папке хранить трейты если папки проекта разделены на model, view, controller?

А трейты у Вас к чему относятся? к бизнес-логике, логике обработки запросов или представлению? К какому слою относиться трейт в том и размещайте

Вопрос по статическим членам трейта

Зачем мешать молоко с мухами? Конфиги это - не функционал программы, соответственно смысла размещать их в трейтах вообще нет

Что это за шаблон проектирования? Вроде как синглтон а вроде и нет.

FlyweightFactory

Как по вашему, он удачен? В моем случае он показал себя хорошо, однако я мог просто не попасть на какие-то проблемные места, что думаете?

Сложно судить т.к. удачное использование шаблона зависит только от задачи к которой он применяется. Если Ваши объекты особо не имеют состояний, тогда данный паттерн вполне уместно применить, если же Ваши объекты это сущности - тогда стоит применить паттерн Identity Map

уж извините за грубость но Вы написали бред который и не может работать, во первых при срабатывании поведения на события в указанную функцию передается не заданные Вами атрибуты а экземпляр класса yii\base\Event т.е. никаких $insert и $changedAttributes не будет передано, в Вашем случае в метод будет передан экземпляр класса yii\db\AfterSaveEvent. Во вторых зачем Вы наследуетесь от AttributeBehavior? по коду смысла от этого наследования нет, кроме того метода afterSave, который Вы вызываете в коде
parent::afterSave($insert, $changedAttributes);
в классе AttributeBehavior нет. А правильно реализовать Ваше поведение приблизительно так:

class EntityLogBehavior extends \yii\base\Behavior
{
    public function events()
    {
        return [
            ActiveRecord::EVENT_AFTER_INSERT => 'afterSave',
        ];
    }

    public function afterSave($event)
    {
        $event->changedAttributes // читаем и что-то делаем с измененными атрибутами
    }
}

P.S. настоятельно рекомендую детально изучить саму концепцию поведений

просто хотелось бы сделать "красиво", чтобы был один контейнер,

"красиво" зависит от того с какой стороны смотреть. Если смотреть с стороны docker-практик то каждый "процесс" должен быть запущен в отдельном контейнере изолированном от других, а не в одном, т.е. контейнер с базой, контейнер с приложением, контейнер ну допустим с каким-нибудь сервером очередей и т.п.

Как я себе это представляю, есть таблица user(user_id primary), при создании юзером галереи, я создаю таблицу (gallery_id primary, user_id, gallery_name, gallery_thumb), а при загрузке юзером картинок в галерею, я создаю еще одну таблицу (img_id primary, gallery_id, img_name)

Структура правильная, но зачем создавать для каждого юзера свою таблицу? храните все галереи в одной таблице, так же как и изображения

попробуйте заменить в корневом каталоге httaccess на такой

Options All -Indexes -Includes +FollowSymlinks

<IfModule mod_rewrite.c>    
    RewriteEngine On
</IfModule>

<IfModule mod_rewrite.c>
    RewriteCond %{REQUEST_URI} ^/.*    
    RewriteRule ^(.*)$ web/$1 [L]

    RewriteCond %{REQUEST_URI} !^/web    
    RewriteCond %{REQUEST_FILENAME} !-f [OR]
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^.*$ web/index.php
</IfModule>

а в web на

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php

в данном случае создастся экземпляр класса Foo, т.к. Вы не используете позднее статическое связывание. Соответственно если хотите что бы создавался экземпляр класса Bar используйте его, например:

class Foo
{
    static public function create() {
        return new static();
    }
}

P.S. и лучше у методов явно указывать модификаторы доступа

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

В этой связи у меня напрашивается вопрос - насколько new Query() и createCommand() являются признаками говнокода? Придется ли краснеть, когда этот код увидит другой программист, или можно будет сказать "и так нормально"?

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

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

Не надо рефакторить приложение полностью, надо рефакторить небольшими кусочками по мере работы над другими задачами. Так сказать делать код с которым Вы работаете немножко чище чем он был

Да прочитайте Вы ошибку

Setting unknown property: app\models\Financy::2900

О чем о на говорит? о попытке установить не известный атрибут класса в 2900 строку класса app\models\Financy. А это значит что? что либо Вы обращаетесь не к существующему свойству, либо работает не с объектом

Inflector работает и с кириллицей. Если у Вас не работает - значит дело в Вашем проекте, например строка которую Вы пытаетесь обработать не в UTF. В общем нужно дебажить...