Да не, я без толики политики в данном случае. Мне сказали чтобы для стран СНГ по умолчанию был русский, Прибалтика не входит в СНГ, вот и вопрос.

Заказ такой, плюс хочу в очередной раз стрельнуть себе в ногу, чтобы не было выхода. А то я чтобы что-то новое изучить, вынужден себе придумывать условия, чтобы кто-то меня сверху ёб =)

Кстати, умные люди. Подскажите, не могу для себя определиться. Некий сайт, возможно, будет на Ларке. Вход по паролю. Внутри у каждого юзера будет список товаров, которые он уже купил. Условно станки. У товара -- список запчастей по категориям. Список документации к товару. Список заявок разных от юзера, также слинкованных с товаром. И вот я задумался над правами доступа и размещением контента вообще. Самый простой вариант это по примеру Эво одна таблица для всех типов контента. И вторая таблица т1, которая бы связала айди любого документа с товаром. И вторая таблица т2 для связи товара с юзером. И получаем что надо один раз получить юзера и его товары из т1, а дальше тупо пробегаться по массиву из т2 при открытии некоего документа/запчасти и показывать или нет док/запчасть/прочее в зависимости от того, куплен станок или нет. Но это вроде как не в стилистике Ларки, там для всяких сущностей делают свои таблички. И это выходит надо городить нечто для проверки доступа юзера к каждому типу материалов + конкретный материал.

Кстати, умные люди. Подскажите, не могу для себя определиться. Некий сайт, возможно, будет на Ларке. Вход по паролю. Внутри у каждого юзера будет список товаров, которые он уже купил. Условно станки. У товара -- список запчастей по категориям. Список документации к товару. Список заявок разных от юзера, также слинкованных с товаром. И вот я задумался над правами доступа и размещением контента вообще. Самый простой вариант это по примеру Эво одна таблица для всех типов контента. И вторая таблица т1, которая бы связала айди любого документа с товаром. И вторая таблица т2 для связи товара с юзером. И получаем что надо один раз получить юзера и его товары из т1, а дальше тупо пробегаться по массиву из т2 при открытии некоего документа/запчасти и показывать или нет док/запчасть/прочее в зависимости от того, куплен станок или нет. Но это вроде как не в стилистике Ларки, там для всяких сущностей делают свои таблички. И это выходит надо городить нечто для проверки доступа юзера к каждому типу материалов + конкретный материал.

Я сейчас как всегда буду ересь говорить, но не всё ли равно в какой стилистике ты это сделаешь? Мне кажется главное, чтобы это работало, и это можно было поддерживать, и, желательно, чтобы поддерживать могли и другие, а не только ты😁

Из простых решений - https://github.com/spatie/laravel-permission Если хочется побыть классным и подумать самому то https://code.tutsplus.com/ru/tutorials/gates-and-policies-in-laravel--cms-29780

Ну дык это и есть гейты собственно, по второй ссылке

да, я их называю сироты

А что мешает поставить "оплату при получении", визуально скрыв эти поля от пользователей?

В Опенкарте есть такая возможность - достаточно активировать базовый модуль Free Checkout или использовать более изощренные варианты работы с корзиной, где такое же галочкой выставляется. (;

Да есть, можно поставить гибкий модуль simple 450 р, и настроить. Можно и без него, но много полей.

Ниче не понял.

Ниче не понял.

Нужно opencart поставить?

Когда я с ней работал (с OpenCart), то не было, это где-то лет 6 назад.

Че-то не поставилось, видно?

Это что-то не нашли значит. С 1.3 и 1.4 точно есть этот модуль, а это раньше 2012 года точно было. (:

что то да, наебнулось.

Может быть, я помню, что и у народа спрашивал - говорили, нет такого вроде.

Интересно, why?

так опенсервер, кто знает как он у вас там настроен)

До этого все норм с композера ставилось...

чета судя по надписям там версия композера сильно древняя. Может из-за этого?

Да это не "там", это я сам командой из консоли композер ставил.

чета судя по надписям там версия композера сильно древняя. Может из-за этого?

чета судя по надписям там версия композера сильно древняя. Может из-за этого?

чета судя по надписям там версия композера сильно древняя. Может из-за этого?

Кстати, умные люди. Подскажите, не могу для себя определиться. Некий сайт, возможно, будет на Ларке. Вход по паролю. Внутри у каждого юзера будет список товаров, которые он уже купил. Условно станки. У товара -- список запчастей по категориям. Список документации к товару. Список заявок разных от юзера, также слинкованных с товаром. И вот я задумался над правами доступа и размещением контента вообще. Самый простой вариант это по примеру Эво одна таблица для всех типов контента. И вторая таблица т1, которая бы связала айди любого документа с товаром. И вторая таблица т2 для связи товара с юзером. И получаем что надо один раз получить юзера и его товары из т1, а дальше тупо пробегаться по массиву из т2 при открытии некоего документа/запчасти и показывать или нет док/запчасть/прочее в зависимости от того, куплен станок или нет. Но это вроде как не в стилистике Ларки, там для всяких сущностей делают свои таблички. И это выходит надо городить нечто для проверки доступа юзера к каждому типу материалов + конкретный материал.

Чем проще, тем лучше. Не нужно городить сверх того что необходимо, лучше потратить силы на разделение таких обязанностей таким образом чтобы потом можно было просто заменить "модуль" другим, т.е. когда нужны станут роли, то поменять в одном месте и заработает везде. Вариант описанный Вами очень даже хорош, может с поправками или уточнениями, конечно же. Есть основные таблицы: - товаров - запчастей товаров - категорий - пользователей - отношения категорий к запчастям - отношения товаров к запчастям - отношения пользователей к товарам - отношения пользователей к запчастям (по необходимости, т.к. можно заменить в зависимости от цели) Дальше, в зависимости от концепции, нужно минимум получить id товара и пользователя, пройтись по таблицам и достать нужное. Реализовать лучше через Middleware, таким образом можно будет манипулировать вариантами. Например, можно будет навесить Middleware на определенный роут: Route::get('/product', function () { // })->middleware('myProduct'); А в последствии еще и добавить роли.

Ухх)

Жиза боль, где комит с фиксом?

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

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

ээээ

Вот так баги в коде и проявляются. (:

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

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

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

никто и в ево не мешал делать правильно

Я вот такую плюшу увидел под Лару https://adminlte.io

с ней ещё надо уметь работать, несколько раз попадались мне админки на ней, капец неудобно сделаны

А в чём затыки были?