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

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

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

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

Один парень написал: "Нужно сделать поиск слов в таблице "articles" по столбцу "content". В результатах поиска сначала выводить те, которые содержат наибольшее количество слов в статье и далее по мере уменьшения."

Мысль летит) Но ясно, что нужен полнотекстовый поиск.

Авторизация с помощью социальной сети не должна зависеть от типа аккаунта. В предыдущем посте используется код, где в конструкторе классa common/components/SocialContact.php выполняется оператор switch. При добавлении обработчика для новой социальной сети, придется дописывать код, при этом меняя класс.

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

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

На сайте оставили комментарий, вы ответили. Оппонент что-то еще уточнил, вы опять ответили. Цепочка из нескольких вопросов/ответов, которую нужно представить в виде лестницы.

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

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

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

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

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

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

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

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

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

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

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

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

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

Разработка бекенда сайта часто подразумевает ограничение прав при редактировании контента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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