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

Новости, сообщения, описания - это все статьи, а статьи - это блог. Блог является важной составляющей любого сайта.

Блог настолько важен, что самая популярная CMS на планете WordPress - это блог.

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

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

В WordPress для подобных задач используется область виджетов. Как писать виджет в WordPress подробно написано в кодексе. Но всегда есть нюансы.

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

Должна быть возможность легко размещать такой вопросник в статье или на странице блога WordPress. Об этом была речь в предыдущем посте.

Для подобных задач в WordPress есть механизм short-code. При создании сайта или в процессе развития сайта в страницу или пост вставляется специальный код. Если есть зарегистрированные коды, страница проходит проверку. Если код обнаружен, то вызывается обработчик. Результатом работы обработчика является html код, который вставляется на место short-code.

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

Любой товар состоит из элементов. Довольно часто производитель, поставив задачу написать электронный магазин, позволяет выбирать комплектацию заранее, до производства. Выбирая комплектующие есть возможность сэкономить или наоборот, согласиться с утверждением "Я этого достоин(а)" и заказать по полной.

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

Но это отвлеченный пример, а был конкретный - Demo, Plugin.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Василий оставил комментарий в конце января

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

Речь о расширении yii2-byone-uploader, которое может загружать, сжимать, обрезать картинки для любой модели. Я писал о нем уже пару раз.

На тот момент этой функциональности не было. Собирался я долго. Но вот, наконец добавил требуемое. Теперь спешу написать несколько слов о процессе. Демо (при редактировании).

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

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

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

Чтобы разобраться, как это возможно, я решил написать плагин для агенств недвижимости. Расширять структуру данных не хотелось - это уже будет не WordPress. Решил сохранять JSON-определения объектов недвижимости в поле post_content и преобразовывать эти определения "на лету" - Demo, GitHub

Заказчик попросил вывести данные о сделках в таблицу в формате CSV. Данные должны быть максимально полными.

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

Ну и прочее - кто, когда, с кем, контакты клиента и, наконец, все комментарии к сделке.

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

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

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

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

Иногда важно определить дополнительную информацию для загружаемого файла. Например это может быть описание. В расширении yii2-byone-uploader возможность добавить описание к файлу уже предусмотрена.

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

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

Например, можно устроить, что-то вроде надписи в столовой - "Уберите, пожалуйста, за собой посуду" (демо).

Бывает, что количество полей в таблице не слишком велико и редактировать в модальном окне проще и нагляднее. Что необходимо, чтобы организовать стандартный набор операций - CReate, Update, Delete?

В предыдущей статье уже была ссылка на работающий пример.

Следующим шагом стало выделение процесса аутентификации на сервисе Google в отдельный класс. А это, в свою очередь, позволило сделать расширение, немного упрощающее решение задачи.

Если у вас есть аккаунт в Google, то вы наверняка пользовались документами. Например, электронными таблицами.

Доступ к таблицам разрешен только вам и тем, кому вы предоставите такое право. Причем доступ возможен не только из Google.

Можно просматривать список таблиц и редактировать выбранную таблицу оставаясь в рамках своего приложения. Примерно так - http://sample.vorst.ru/googl

Для этого разработано Google Sheets API, доступное в двух вариантах - клиентская библиотека и REST API.