;)

Языки нужно изучать чтобы не стареть умом и понимать окружающих. (: Так что дело доброе.

тут это, между делом спрошу глупость) &l; и &g; - таких же сущностей хтмлы нету? (это типа сокращено от < и > соотвественно)

доброе утро 🙂

Hi! )

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

по идее тебе здесь нужно проверить total и если он большей твоей суммы $price поставить 0

Языки нужно изучать чтобы не стареть умом и понимать окружающих. (: Так что дело доброе.

+

+ Я IF не там поставил, разумеется

тут это, между делом спрошу глупость) &l; и &g; - таких же сущностей хтмлы нету? (это типа сокращено от < и > соотвественно)

Ommg ;p

Dymytro i dont understand this even with Google 😛

На сайте, можно оплатить товар, билет на мироприятие, бронь в ресторане, все это разние таблицы и сущности. Создаю табличку payments, как назвать колонку из типо сущности, и id из таблицы сущности type type_id как то не особо?

Dymytro i dont understand this even with Google 😛

i asking about html-entities, does exists &l; and &g; (as shorten for < and >)? )))

ну как вариант order_type order_id

i asking about html-entities, does exists &l; and &g; (as shorten for < and >)? )))

html-entities is a deadly things on web applicatin ;p in fact u can try to create web_user in Evo with password:  test1234&test22&nbp;& <-- and of course u cant login 😄

html-entities is a deadly things on web applicatin ;p in fact u can try to create web_user in Evo with password:  test1234&test22&nbp;& <-- and of course u cant login 😄

it is usefull for xml )))

ну как вариант order_type order_id

да заказ, это и есть заказ. Это надо привязывать к покупкам всередине заказа

да заказ, это и есть заказ. Это надо привязывать к покупкам всередине заказа

id - это будет ид платежа order_type - тип сущности, которую оплачиваем (заказ в магазине, билет, оплата брони) order_id - ид из таблицы сущности

по идее это все заказы чегото

нет

it is usefull for xml )))

in deed but in Evo we still need a fix for creating new passowrd - adding double "&" do a little mess in password field ;]

по идее это все заказы чегото

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

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

нет у нас заказы товаров - это одна таблица, заказы билетов другая, заказы брони в ресторане третья

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

in deed but in Evo we still need a fix for creating new passowrd - adding double "&" do a little mess in password field ;]

it is better in form password label to write "Use digits, letters and underscore" for example

нет у нас заказы товаров - это одна таблица, заказы билетов другая, заказы брони в ресторане третья

а, ну тогда да. order_type, order_id п.с. но вообще это странно.... ))

ну просто у брони своя логика оформление, в билетов тоже

ну просто у брони своя логика оформление, в билетов тоже

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

ну тут не согласен но за помощь спасибо

В админке оно тоже по разному редактируется

причем бронь от магаза кардинально отличается

ну просто у брони своя логика оформление, в билетов тоже

да в том же шопкипере можно в жсон накидать каких хочешь полей, и вывести в админке их редактирование

да в том же шопкипере можно в жсон накидать каких хочешь полей, и вывести в админке их редактирование

в этом случаи уже есть 3 сущности, и я согласен из разделением на три

it is better in form password label to write "Use digits, letters and underscore" for example

yeap but u can also encodeURIComponent in JS and filter_var(POST, 'var_name', FILTER_SANITIZE_FULL_SPECIAL_CHARS);

в этом случаи уже есть 3 сущности, и я согласен из разделением на три

да я просто говорю, что все можно сделать изначально без заморочек)

and i dont understand why web user creating new password looks like: "return md5()" 😮

it should be one-way salted hash like: password_hash($password, B_CRYPT, ['cost' => 10]) ?

в этом случаи уже есть 3 сущности, и я согласен из разделением на три

Если таблица types, то type_id, если orders, то order_id. Что смущает то?:)

таблиц три, order,tickets,booking

та не смущает ничего просто хотел норм назвать

Таблицы называются во множ числе, а ключи к их полю id - в единственном плюс _id :)

По аналогии контроллер posts, модель post, таблица posts, контроллер users, модель user, таблица users

Связь через user_id и post_id

есть таблица bookings Поля id .... есть таблица order Поля id .... есть таблица payments если по подходу laravel то нужно назвать id paymentntable_id paymentntable_type

да есть проще пример для site_tmplvars_contentvalues: contentid tmplvarid

получим полиформное отношение

А чем кстати букинг от ордера отличается, мне кажется букинг это и есть заказ или это типа занятое время?

А чем кстати букинг от ордера отличается, мне кажется букинг это и есть заказ или это типа занятое время?

я уже @dinkwi обяснил в личке почему так

потому что у них дофига разного

Впервые слышу про paymentable)

да есть проще пример для site_tmplvars_contentvalues: contentid tmplvarid

Это пример из прошлого века:)

Впервые слышу про paymentable)

https://laravel.ru/docs/v5/eloquent-relationships#pl

Если уж в сторону лары ехать то и логику их юзать, а не свою изобретать)

И соглашения об именах

Если уж в сторону лары ехать то и логику их юзать, а не свою изобретать)

это чисто пример

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

Все спасибо, все свободны

Называй таблицу orderS и всем понравится) но про полиморфные связи это ты наверно сильно глубоко копнул)

это чисто пример

Это было про contentid/tmplvarid

Называй таблицу orderS и всем понравится) но про полиморфные связи это ты наверно сильно глубоко копнул)

понятно мне их не нужно

hmm...

on blade template: {{ $documentObject['img'] }} <-- return assets/images/prod2.png

{{ $modx->runSnippet('phptumb', ['input' => $documentObject['img']]) }} <-- return nothing .. why ? o.0

hmm well ok it should have a 'options' nullled or filled ;p

{{ $modx->runSnippet('phptumb', ['inputs' => $documentObject['img'], 'options' => '']) }} 😄

input*

Need options

And not nulled Phpthumb without options have not sense

{{ $modx->runSnippet('phptumb', ['input' => $documentObject['img']]) }} <-- return nothing .. why ? o.0

{{ $modx->runSnippet('phpthumb', ['input'=>$item['image'], 'options'=>'w=320,h=320,zc=1'] ) }}" alt="{{ $item['title'] }}

You've set options in the wrong place

what is different between $data['image'] and $item['image'] ?

what is different between $data['image'] and $item['image'] ?

http://docs.evo.im/04_extras/if.html

what is different between $data['image'] and $item['image'] ?

nono, you should use $documentObject['img'] on the page

aah ok ;]

this is my foreach sample

and something like $documentObject['pagetitle'] for alt

how can i do something like this @evoParser('[*pagetitle@parent*]') without using evoPArser ?

in blade tempalte of course

template*

it is possible make reference with $documentObject['id'] ?