Максим Тимофеев

В зависимости от того что там надо сверять вижу 2 варианта: первый Вам описал Максим Федоров, второй - подключить Вашу таблицу как связь с таблицей user и в моделе User реализовать метод проверки (я не знаю что там проверяется, но по сути не важно). И подправить метод авторизации и регистрации в соответствующих моделях форм.

Mailgun - самый правильный вариант, в разрезе связки yii, так как есть для его api готовое решение и не одно:
https://github.com/search?utf8=✓&q=yii2+mailgun

Самый удобный кастомный скрол как по мне:
manos.malihu.gr/jquery-custom-content-scroller

скорее всего из-за crfs_token-а, либо шлите GET либо добавляете токен в POST или отключите проверку в экшене (самый не верный вариант)

stackoverflow.com/questions/2693585/background-tra...

Такие вещи лучше делать на svg:
www.jqueryscript.net/lightbox/Elastic-SVG-Modal-Wi...

jpeg не может иметь прозрачность.

Что бы разбирать почему не работает тот или иной скрипт, вначале стоит открыть консольи посмотреть нет ли там ошибок, а они там есть и косвенно могут влиять на выполнения кода ниже, так что для начала исправьте ошибки в консоле.
Да и мусор почистите. У Вас где-то куски от fondation при этом подключен bootstrap. Многое по 2 раза подключено.

Так же как и везде. Есть базовая валюта и есть коэффициент, на который она умножается. Коэффициент в базе, крон раз в день или чаще заходит на ЦБ и по api получает курс, сохраняет в базу.
А вот как хранить выбор пользователя, тут уже есть варианты. Я бы запихнул это в сессию, но можно вообще запихивать в localStorage, туда же или в (sessionStorage) пихать курс, php всегда при этом рендерит с базовой валютой, а js заменяет уже на нужный. То есть отдать часть математики браузеру. Что иногда может дать прирост производительности.

Поставить цель на ссылку на скачивание и считать клики

если в сообщениях прослеживается определенная очередность, то можно иметь в таблице user доп поле типа integer, например stage и выводить сообщения. Относительно према, наверняка отдельная логика. Так как есть таблица с платежными данными и т.д. И есть отдельный компонент, который хранит логику соединения всего этого и формирования сообщения.

Хранить в txt не особо удобно. Я бы посоветовал стандартный вариант в виде mysql но видимо Вас он не устраивает, раз идет речь о костылях. Могу предложить хранить в php файле, в котором будет следующая структура

<?php
return [
'email1'=>['someData'=>'natasha'],
'email2'=>['someData'=>'petya'],
];

и т.д.
при этом можно получать массив и соответственно искать в нем что угодно. Так же есть удобные форматы json, xml, csv. Есть и key-value хранилища (db-engines.com/en/ranking/key-value+store)
txt самый странный выбор, он удобен для логов и т.д. То что не надо редактировать.