Статьи о задачах возникающих при создании сайта и их решении - vorst.ru

Как это сделано


Блог

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

Статьи из рубрики about sites

Email

Как отправить письмо с сайта, чтобы оно не попало в спам

При создании сайта почти всегда предусматривают форму обратной связи.

Допустим у вас на сайте есть форма обратной связи и посетитель заполнил в ней поле Name и поле Email. Логично отправить сообщение с сайта от имени посетителя на адрес администратора сайта или, например, адрес отдела маркетинга.

Но так отправить сообщение не получится. При отправке сообщения с сайта, нужно чтобы отправитель имел тот-же домен, что и сайт.


Правила

rbac - выполнять действие или нет

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

Если вы Админ, то у вас есть общее разрешение create. Оно дает право добавлять данные к любым моделям. Если вы Автор, то такое разрешение давать не стоит. Автор не может, например, добавить новую рубрику.

Если нельзя дать общее разрешение, то нужно создать и выдать частное разрешение. Чтобы позволить Автору добавлять статьи, нужно создать разрешение createPost. Оно должно проверяться следующим, в случае неудачи при проверке разрешения create.

$auth->addChild($createPost, $create);

Чтобы Админ мог добавить статью, нужно, чтобы он имел разрешение на все, на что имеет разрешение Автор.

$auth->addChild($admin, $author);

Все отлично и логично. Четкая иерархия разрешений и ролей. Но, например, вы Автор и пытаетесь редактировать чужую статью. Действие не желательное. Как проверить, что статья не ваша? Или как проверить, что этот комментарий не к вашей статье и вам не стоит на него отвечать?


Разрешения

rbac - разрешения на доступ, роли для групп пользователей

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

Проверяется разрешение просто, например:

if(Yii::$app->user->can('update', ['model' => $model])) {
  // code for model updating
}

То есть может быть выполнен некий код, если за ролью текущего Пользователя закреплено разрешение update. Если представить, что с каждой ролью связан массив текстовых констант - "create", "update" и прочее, то правило проверки становится очевидным.

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

Определим те разрешения, что были упомянуты в предыдущей статье.


Настройка RBAC

rbac - подключение ролевого доступа

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

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


Событие

пример события

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

В первом случае обработчик события один, во-втором их несколько. Пока рассмотрим первый вариант на основе пары предыдущих статей.


Вспомнить все

Если читатель хочет вспомнить, что просмотрено и прочитано

В магазинах это давно норма. Все, что вы просмотрели, у вас перед глазами. Почему бы не сделать тоже самое для блога - вывести заголовки просмотренных постов и время, которое потрачено на листание и чтение каждого поста.


Два языка

переводим контент сайта

Для перевода интерфейса в Yii применяется таблица из двух колонок. В первой колонке записываются слова или фразы на английском, во второй - перевод на русском. Строки отсортированы по первой колонке. В тексте программы вместо нужного слова или фразы вызывается функция t('Word or Phrase'). Если текущий язык сайта английский, функция возвращает параметр, иначе соответствующий перевод.

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


Развитие сайта

Следует за этапами развития компании

Сначала о компании. Выделим, условно конечно же, три этапа.

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

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

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

А что же сайт?