как альтернатива вот https://github.com/OmgDef/yii2-multilingual-behavior но я не юзал

Например productname => хранить в базы данных формате json {"en":"Hello", "ru":"Приветь"} это правильное решение или нет?

тебе же нужно наверное будет хранить еще описание товара на разных языках) как по мне не круто это все в одной строке хранить)

тебе же нужно наверное будет хранить еще описание товара на разных языках) как по мне не круто это все в одной строке хранить)

Большое спасибо!! очень полезные советы

Большое спасибо!! очень полезные советы

а так советую вообще открыть github написать в поиске yii2 и отсортировать все по stars и смотреть чем народ пользуется) и много чего полезного найдешь)

ребят как переопределить description?

ребят как переопределить description?

seo?

да

Yii::$app->view->registerMetaTag([ 'name' => 'description', 'content' => 'Я так использую' ]);

и есть в контроллере экш view я делаю регистр мета тег он дублируется просто

ну в смысле сначала выводится дефолтный потом мой

не сталкивался(

после массива еще раз написать надо что это)

и тогда будет переопределять

да кто его знает что это за говно

удали этот блок через просмотр кода

удали этот блок через просмотр кода

да это понятно) но все же

да это понятно) но все же

хз, думал спрашиваешь что делать)сорян

Привет! Хочу заюзать CSRF токены в GET запросах /article/delete?id=[id] Какие вижу варианты: 1. сделать форму для кнопки и должно hidden поле сгенериться, т.к. в конфиге 'enableCsrfValidation' => true 2. Ajax запрос Больше ж никак не измудриться?)

хз, думал спрашиваешь что делать)сорян

Да не спасибо)

Привет! Хочу заюзать CSRF токены в GET запросах /article/delete?id=[id] Какие вижу варианты: 1. сделать форму для кнопки и должно hidden поле сгенериться, т.к. в конфиге 'enableCsrfValidation' => true 2. Ajax запрос Больше ж никак не измудриться?)

Почему гет а не пост?)

а какая разница?)

в ларке любые запросы без токена не отправляются

в гете токен п**ц длиный получится, чисто так для сексабилити , не то использовать гет

Почему гет а не пост?)

ну с пост все понятно, про гет стало интересно

ну с пост все понятно, про гет стало интересно

берешь гет и вырубаешь валидацию csrf профит)

в гете токен п**ц длиный получится, чисто так для сексабилити , не то использовать гет

"сексабилити" ахаха, надо записать ??

))

спасиб

ну с пост все понятно, про гет стало интересно

прост получится такая фигня : domain.ru/method?id=1&token=b7b659e0d57f08db485f153a550095a74d5b053503e9e891b3a28a796e93535aa%3A2%3A%7Bi%3A0%3Bs%3A13%3A%22_csrf-backend%22%3Bi%3A1%3Bs%3A32%3A%22qV_wLkRTk2E6ai_9UFIDH0x3ltRu3IfE%22%3B%7D

прост получится такая фигня : domain.ru/method?id=1&token=b7b659e0d57f08db485f153a550095a74d5b053503e9e891b3a28a796e93535aa%3A2%3A%7Bi%3A0%3Bs%3A13%3A%22_csrf-backend%22%3Bi%3A1%3Bs%3A32%3A%22qV_wLkRTk2E6ai_9UFIDH0x3ltRu3IfE%22%3B%7D

ну да, не круто смотрится )

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

Делать мультиязычный сайт лучше с помощью Docker, вот пример мультиязычного каталога товаров http://terida.ru/store http://en.terida.ru/store Фокус заключается в том что используется две базы, приложение переключает базы в зависимости от нужного языка, плюсов такого подхода гораздо больше чем минусов

Делать мультиязычный сайт лучше с помощью Docker, вот пример мультиязычного каталога товаров http://terida.ru/store http://en.terida.ru/store Фокус заключается в том что используется две базы, приложение переключает базы в зависимости от нужного языка, плюсов такого подхода гораздо больше чем минусов

а инфа там полностью независима друг от друга или есть пересекающиеся части и где они хранятся? например дата публикации

ребят кто пояснит? wtf

для чего scenario используется

Разные правила валидации

а инфа там полностью независима друг от друга или есть пересекающиеся части и где они хранятся? например дата публикации

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

для чего scenario используется

Лучше не используй сценарии, лучше используй разные формы и сервисы ;)

Лучше не используй сценарии, лучше используй разные формы и сервисы ;)

ну было бы интересно для общего развития)

ну было бы интересно для общего развития)

Как только появятся scenario в эту же секунду начинается температура и головная боль в rules, второй раз пробовать не хочется

ну было бы интересно для общего развития)

Создавайте формы, например CreatePostForm.php UpdatePostForm.php DeletePostForm.php MovePostForm.php и используйте в место scenario в PostService

Как только появятся scenario в эту же секунду начинается температура и головная боль в rules, второй раз пробовать не хочется

со сценариями не было особых проблем, удобненько

Создавайте формы, например CreatePostForm.php UpdatePostForm.php DeletePostForm.php MovePostForm.php и используйте в место scenario в PostService

пока именно так и использую)

пока именно так и использую)

Вот и славненько ;) а про сценарии это лишнее, оставьте их гурманам и фанатам

Вот и славненько ;) а про сценарии это лишнее, оставьте их гурманам и фанатам

все равно нужно поюзать чтобы понимать нужно оно или нет)

но за мнение спасибо!)

ребят кто пояснит? wtf

вот задал ты в контроллере сценарий, и можешь его юзать, описывая в модели правила для сценария (валидируешь ток нужные поля)

почитай https://yiiframework.com.ua/ru/doc/guide/2/structure-models/

вот задал ты в контроллере сценарий, и можешь его юзать, описывая в модели правила для сценария (валидируешь ток нужные поля)

спасибо!)

спасибо!)

?

Эту строчку нужно жирным капслоком и первым пунктом, а не мелким шрифтом где то в конце)

:D ну для не больших проектов сценариев хватает)

:D ну для не больших проектов сценариев хватает)

Я бы назвал их одноразовыми)

Я бы назвал их одноразовыми)

большинство кода, одноразовый...

а сценарии удобны если их правильно применять и понимать

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

слайдер скорее всего не на Yii, курите js

И еще вопрос там разработчик мудрил и в общем там папки от вордпресса

Основные папки я загуглю

А сам шаблон где находится

И еще вопрос там разработчик мудрил и в общем там папки от вордпресса

серьезно?! скинь скрин папки сайта

Подскажите, почему может такая ошибка появлятся Неверный формат значения «Время создания, в рулзах указано так - [['created_at'], 'datetime']

Подскажите, почему может такая ошибка появлятся Неверный формат значения «Время создания, в рулзах указано так - [['created_at'], 'datetime']

Ты сгенерил модель и crud через gii?

в behaviors так - return [ [ 'class' => TimestampBehavior::className(), 'createdAtAttribute' => 'created_at', ], ];

Ты сгенерил модель и crud через gii?

нет

в behaviors так - return [ [ 'class' => TimestampBehavior::className(), 'createdAtAttribute' => 'created_at', ], ];

use yii\db\Expression; public function behaviors() { return [ [ 'class' => TimestampBehavior::className(), 'createdAtAttribute' => 'create_time', 'updatedAtAttribute' => 'update_time', 'value' => new Expression('NOW()'), ], ]; }

use yii\db\Expression; public function behaviors() { return [ [ 'class' => TimestampBehavior::className(), 'createdAtAttribute' => 'create_time', 'updatedAtAttribute' => 'update_time', 'value' => new Expression('NOW()'), ], ]; }

ничего не изменилось)

в БД какой тип поля?

datetime

'value' => date('dateformat from DB'),

Привет! Дискуссионный вопрос: есть админка, и REST api для клиентов. В админке несколько типов пользователей, которые используются для редактирования данных. И есть пользователи, которые как раз во всей предметной области известны, они пользуются апи, их данные смотрят админы. Вот этих "пользователей api" назвать как сущность Users как-то не поднимается рука, т.к. эта сущность доступна в common и когда делаешь админку, кажется, что вот уже есть Users - значит и админы с этой сущностью связаны. Вот не могу понять как правильно это разделить, Client и Admin. Или нормально будет User, Admin (и никто не запутается от общего названия сущности User)

Привет! Дискуссионный вопрос: есть админка, и REST api для клиентов. В админке несколько типов пользователей, которые используются для редактирования данных. И есть пользователи, которые как раз во всей предметной области известны, они пользуются апи, их данные смотрят админы. Вот этих "пользователей api" назвать как сущность Users как-то не поднимается рука, т.к. эта сущность доступна в common и когда делаешь админку, кажется, что вот уже есть Users - значит и админы с этой сущностью связаны. Вот не могу понять как правильно это разделить, Client и Admin. Или нормально будет User, Admin (и никто не запутается от общего названия сущности User)

да нормально все, по правам разделяешь и все

Привет! Дискуссионный вопрос: есть админка, и REST api для клиентов. В админке несколько типов пользователей, которые используются для редактирования данных. И есть пользователи, которые как раз во всей предметной области известны, они пользуются апи, их данные смотрят админы. Вот этих "пользователей api" назвать как сущность Users как-то не поднимается рука, т.к. эта сущность доступна в common и когда делаешь админку, кажется, что вот уже есть Users - значит и админы с этой сущностью связаны. Вот не могу понять как правильно это разделить, Client и Admin. Или нормально будет User, Admin (и никто не запутается от общего названия сущности User)

ApiUser ?

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

Привет! Дискуссионный вопрос: есть админка, и REST api для клиентов. В админке несколько типов пользователей, которые используются для редактирования данных. И есть пользователи, которые как раз во всей предметной области известны, они пользуются апи, их данные смотрят админы. Вот этих "пользователей api" назвать как сущность Users как-то не поднимается рука, т.к. эта сущность доступна в common и когда делаешь админку, кажется, что вот уже есть Users - значит и админы с этой сущностью связаны. Вот не могу понять как правильно это разделить, Client и Admin. Или нормально будет User, Admin (и никто не запутается от общего названия сущности User)

у тебя есть сущность User. А все остальное решается ролями

правильнее называть UserAccount, btw

вот просили скинуть скрин

UserAccount - как учетная запись? учетная запись может быть частью предметной области? ну как бы действия-то выполняет пользователь/клиент. я подумала про то, что через api - это Customer (клиент)

полный бардак

нашел то что мне нужно как мне найти content ?))

слайдер твой должен быть в папке frontend /views/ site/

нашел то что мне нужно как мне найти content ?))

поставь ИДЕ

и почитай доки