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

В виджете DetailView нет свойства columns, возможно Вы имеете ввиду виджет GridView?
В любом случае Вы не можете использовать код приведенный в вопросе т.к. список атрибутов не может принимать функцию, а только массив. Но Вам никто не мешает сформировать этот массив до вывода виджета

В конфигурации приложения, в свойстве timeZone

1. Судя по всему Вы в data-content пытаетесь вставить объект $heroes - как Вы себе представляете результат? нужно вставлять конкретную строку содержащуюся в атрибуте объекта, например $heroes->content
2. При чем здесь Laravel? Вы формируете обычную строку, ларавель в ней ничего не найдет и не заменит. Используйте конкатенацию строк

если не хотите использовать крон, можно использовать мускульные Event'ы

наклонные кавычки `` используются для экранирования служебных слов базы данных
обычные '' для указания строк

P.S. и отучитесь вставлять неподготовленные переменные в запросы, если не хотите в последствие проблем с sql-инъекциями

Ох что-то Вы намудрили, зачем пользователя помещать в какую-то специальную группу RBAC? Заблокированные пользователи - это пользователи которые вообще не имеют доступ к сайту, поэтому вполне логично было бы вынести статус блокировки в модель пользователя и проверять его в findIdentity

разберитесь с нормальными формами БД и перепроектируйте по нормальному базу данных.

Вы можете реализовать динамическое формирование набора полей на стороне js используя объект ActiveForm. Более подробно о том как работать с js-объектом ActiveForm можно почитать здесь

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

без разницы как Вы будете запускать процесс списания средств по крону или еще как-то, защита от повторного/параллельного списания должна быть реализована в самом алгоритме списания и не зависеть от вызывающих ее процессов. Т.е. на момент списания алгоритм сам должен проверять нужно ли снимать абонплату с клиента или нет. Как именно сделать эту защиту зависит от деталей реализации Вашей системы - но в общем случае вариант с историей вполне уместен, а проблемы параллельного списания вполне можно решить транзакциями/блокировками

1. Генерируете secretKey и сохраняете его вместе с датой и временем генерации
2. Отправляете письмо с ссылкой клиенту
3. Когда клиент переходит по ссылке - проверяете есть ли указанный secretKey и не истекла ли его дата.
4. В зависимости от результата проверке отображаете нужную страницу

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

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

Вы уж меня извините, может я чего-то не понимаю... но сам паттерн ПРОЕКТИРОВАНИЯ где?
Ок, у Вас есть конкретная задача и Вы ее решили - прекрасно. Но это не паттерн - это лишь один из вариантов решения ВАШЕЙ конкретной задачи.

Не стоит путать паттерны и проектирование. Да паттерны используются в проектировании систем, но они сами по себе не есть проектирование. Очень часто люди прочитают пару книжек по паттернам и начинают их использовать где нужно и где не нужно и считают что все их система имеет хорошую архитектуру - но в результате от такой "архитектура" возникает больше проблем чем пользы. Поэтому мой Вам совет отложите паттерны на потом: почитайте что-нибудь именно о проектировании, и его принципах. Хотя бы того же Роберта Мартина. Бесспорно обе книги стоит прочитать, но как по мне их нужно читать имея уже определенные навыки