Сергей

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

Если вы делаете "глобальный" продукт, я бы на вашем месте выбрал бы вариант: много таблиц с множеством кампаний, когда в каждой таблице может хранится набор данных для нескольких кампаний, но таких таблиц может быть много. Это даст распределение нагрузки (разные таблицы могут хранится, обрабатываться на разных серверах), т.о. вы всегда сможете легко выделить новые ресурсы для новой кампании.

С другой стороны, вы можете хранить все данные в одной БД (одной таблице). На начальном этапе для вас это будет проще, но чем дольше вы будете разрабатывать продукт, тем сложнее будет переход на другую архитектуру. Поэтому лучше подумать обо всем заранее. По крайней мере увидеть подводные камни, и приготовится решать их в будущем.

Вынесите в виджет форму, если она дейтсвительно должна шариться между скринами. А вообще модули должны быть изолированными друг от друга (по возможности).

правильно организовывать "выкладку" на сервер

У каждого свои подходы. В общем случае, выделяют следующее:

Есть ветка master, в которой находится production код, есть ветка staging, в которой находятся фичи, которые нужно тестить. Есть кучи feature-бренчей, которые можно мерджить только со staging, а после того как код в стэйджинге стабилизировался, можно мерджить ветку в продакшен.

Подробнее о таком подходе можно почитать у фаулера, feature-branch. Есть еще другие методологии, типа feature-switch, а еще можно вообще не париться. Все от проекта зависит, количества разработчиков и все такое.

По поводу же выкладки на сервер - самый пожалуй правильный способ, использовать ansible или подобные штуки, и запускать сборку на CI сервере после успешного прогода тестов (что куда лить можно вешать по пушу в соответсвующую ветку).

Миграции в контексте yii придется делать руками, причем сразу при реализации каких-то фич. Миграции все же создавались для версионизации структуры данных, так что это даже больше для разработчика, нежели для деплоя. Сразу хочу заметить, что лучше писать такие миграции, которые не ломают логику работы более старой версии приложений (то есть стараться не удалять поля у таблиц, а только разрешать ничего туда не писать, или таблицы не удалять). Хотя опять же зависит от проекта и команды. Автоматизировать создание миграций для схемы данных будет проблематично, ибо модели не дают надежной инфы о схеме (то есть из модели не сгенерить таблицу, хотя можно это реализовать).

Первый деплой:

git clone
composer install
yii init
#правите локальные конфиги (прописываете базу)
yii migrate

следующие деплои:

git pull
composer install
yii migrate

миграции создаем ручками
yii migrate/create createUserTable
и правим файл миграции

https://bitbucket.org/

Вы для начала определитесь что вы хотите получит в результате вызова статического (кстати почему статического?) метода getDateUpdate?
варианты:
1. Некую дату из константы определенной внутри класса модели, как это сейчас (только константа не определена).
2. Некую дату из статического свойства класса модели, тогда код будет выглядеть так:

public static function getDateUpdate()
{
	return DateFormat::load()->dateToBigString(self::$date_update);
}

3. Все таки значение атрибута конкретного объекта модели, тогда никакой статики и геттер будет выглядеть так:

public function getDateUpdate()
{
    return DateFormat::load()->dateToBigString($this->date_update);
}

https://github.com/mikehaertl/translatable поведение для перевода моделей. Там и про базу описано. Смысл в том, чтобы хранить сущность и отдельно ее перевод.

используй javascript.ru/setTimeout
что-то вроде такого:
<a onclick="setTimeout(func, 5000)">test</a>

т.е. функция func() запустится через 5 секунд после нажатия на ссылку test

/**
     * @var array|\Closure the HTML attributes for the data cell tag. This can either be an array of
     * attributes or an anonymous function that ([[Closure]]) that returns such an array.
     * The signature of the function should be the following: `function ($model, $key, $index, $gridView)`.
     * A function may be used to assign different attributes to different rows based on the data in that row.
     *
     * @see \yii\helpers\Html::renderTagAttributes() for details on how attributes are being rendered.
     */
    public $contentOptions = [];