Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
А на стаке мне вот что предложили:
@foreach ($user->payment-methods()->get() as $payment_method)
<div>
@if ($user->get_default_payment_method()->id === $payment_method->id)
<strong>Default Payment Method</strong>
@endif
{{ $payment_method }}
</div>
@endforeachПо сути тоже самое что ты.. Сравнивать прямо в цикле.
$user->payment_methods()->withCount('defaultForUser')->get()Кстати, а вот такие штуки в шаблонах надо ли прятать в метод модели в данном случае PaymentMethod ?
Что бы было типа $user->payment_methods()->getWirhDefaultForUser();
Многие по многим не пойдет. Ведь один платеж может быть только одной картой. У юзера может быть много карт, но карта может принадлежать лишь одному юзеру. Даже если мы возьмум одну и туже карту и два раза зарегистируемся и ее введем, это будет разные PaymentMethod тк в платежном шлюзе разные.
Так, что структуру кажется я верно отразил.
if ($payment_method->id === $user->default_payment_method_id)
Логично тк юзер то известен для данной таблицы! Надо было так и сделать. Но я сделал так:
<h3>Payment methods</h3>
<table border="1">
<tr><th></th><th></th><th></th></tr>
@foreach($user->payment_methods()->withCount('defaultForUser')->get() as $payment_method)
<tr>
<td>
<div><strong>id:</strong> {{$payment_method->id }}</div>
<div><strong>gateway id:</strong> {{ $payment_method->braintree_id }}</div>
</td>
<td>
@if($payment_method ->type == PaymentMethod::PAYPAL_ACCOUNT)
<div><strong>Paypal: </strong> {{$payment_method -> paypal_email}}</div>
@else
<div><strong>Card: </strong>{{ $payment_method -> card_brand }} **** **** **** {{$payment_method -> card_last_four}}</div>
@endif
<td>
@if ($payment_method -> default_for_user_count)
<strong style = "color:green">Default</strong>
@endif
</td>
</td>
</tr>
@endforeach
</table>Допустим есть платежные методы данного юзера и только один из них является методом по умолчанию. Признака is_default у платежного метода нет. Зато у юзера есть поле в котором храниться id метода по умолчанию
class PaymentMethod extends Model
{
....
public function user()
{
return $this->belongsTo(User::class, 'user_id', 'id');
}
...
}
class User extends Authenticatable
{
...
public function payment_methods()
{
return $this->hasMany(AppPaymentMethod::class, $this->getForeignKey())->orderBy('created_at', 'desc');
}
public function default_payment_method()
{
return $this->hasOne(AppPaymentMethod::class, 'id', 'default_payment_method_id');
}
public function getDefautPaymentMethod()
{
$paymentMethod = $this->default_payment_method()->first();
return $paymentMethod;
}
...
}Как для юзера взять в шаблоне его умолчательный метод ясно и работает
@if($user -> getDefautPaymentMethod()->type == PaymentMethod::PAYPAL_ACCOUNT)
<div><strong>Paypal: </strong> {{$user -> getDefautPaymentMethod()-> paypal_email}}</div>
@else
<div><strong>Card: </strong>{{$user -> getDefautPaymentMethod()-> card_brand}} **** **** **** {{$user -> getDefautPaymentMethod()-> card_last_four}}</div>
@endifА теперь хотелось бы для каждого юзера в списке всех методов метод по умолчанию выделить. Как это красиво сделать?
Вот цикл
@foreach($user->payment_methods()->get() as $payment_method)
@if($payment_method ->type == PaymentMethod::PAYPAL_ACCOUNT)
<div><strong>Paypal: </strong> {{$payment_method -> paypal_email}}</div>
@else
<div><strong>Card: </strong>{{ $payment_method -> card_brand }} **** **** **** {{$payment_method -> card_last_four}}</div>
@endif
@endforeachПричем подзапроса который бы выполнялся в каждой итерации цикла не хотелось бы как и DB::RAW. Думаю в PaymentMethod нужно метод добавить который будет использовать отношение с User и проверять существует ли объект по этому отношению. Или когда беру все платежные методы $user->payment_methods()->get() как то взять их with user по отношению через PaymentMethod.id = User.default_payment_method_id
Throwable.
Да 7-ка уже давно. Те лучше им все Exception заменить выходит?
Про порядок use не буду замарачиваться. Просто так чуть причешу, что в глаза сумбур не бросался
Ой. Прошу простить. Ошибка синтаксическая @endforeach не поставил. И в глаза не бросается и исключение совсем не содержит инфу в чем проблема.
dd($user -> payment_methods()->get(), $user -> payments()->get());
//выводит две норм коллекции:
Collection {#341 ▼
#items: array:1 [▶]
}
Collection {#117 ▼
#items: array:2 [▶]
}А в шаблоне одна из коллекций выкидывает ошибку при попытке вывести в цикле, а с другой норм
@foreach($user -> payment_methods()->get() as $payment_method)
<div>test</div>
@foreachВыкидывает исключение:
ErrorException (E_NOTICE)
Undefined offset: 1/www/nofiles55/vendor/laravel/framework/src/Illuminate/View/Compilers/Concerns/CompilesLoops.php
*
* @param string $expression
* @return string
*/
protected function compileFor($expression)
{
return "<?php for{$expression}: ?>";
}
/**
* Compile the for-each statements into valid PHP.
*
* @param string $expression
* @return string
*/
protected function compileForeach($expression)
{
preg_match('/\( *(.*) +as *(.*)\)$/is', $expression, $matches);
$iteratee = trim($matches[1]);
$iteration = trim($matches[2]);
$initLoop = "\$__currentLoopData = {$iteratee}; \$__env->addLoop(\$__currentLoopData);";
$iterateLoop = '$__env->incrementLoopIndices(); $loop = $__env->getLastLoop();';
return "<?php {$initLoop} foreach(\$__currentLoopData as {$iteration}): {$iterateLoop} ?>";
}
А как накатить файлы миграций на основе существующих в БД таблиц?
Все это в авторизованном состоянии
У меня постоянные ошибки когда захожу внутрь тем из ссылок которые на главной форума..
И вчера целый день она была.
К примеру:
namespace App\Http\Controllers\Admin;
use \App\Classes\Models\User;
use \App\Classes\Models\Payment;
use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Config;
use Exception;
В какой последовательности записать? Какой тут принцип? Возможно сначала классы самой Laravel, а затем мои? Или еще как то?
А можно ли полноценное использование cashier и braintree с каким то другим платежным шлюзом?
Ну скажем у юзера нет карты или пейпала но есть скажем webmoney, может он выбрать не форму от braintree которую я сделал, а другую от webmoney далее платит и создается на моем сайте подписка, но со статусом типа is_webmoney и регулярные платежи идут от webmoney, а другие от braintree…
Понятно что в теории все можно, но какие общепринятые сейчас практики на этот счет? Или тогда и подписки от braintree лучше не использовать, а только одиночные charge?
Webmoney это условно, возможно какой то еще шлюз… Сейчас это не нужно. Просто хочется понять не зря ли на подписки внутри braintree завязываемся?
$paypalPayment = isset($webhook->subscription->transactions[0]->paypalDetails);
$user->payments()->create([
’braintree_id’ ⇒ $webhook->subscription->transactions[0]->id,
’braintree_payment_token’ ⇒ $webhook->subscription->transactions[0]->creditCardDetails->token,
’subscription_id’ ⇒ $subscription->id,
’period_start’ ⇒ $webhook->subscription->billingPeriodStartDate,
’period_end’ ⇒ $webhook->subscription->billingPeriodEndDate,
’amount’ ⇒ $webhook->subscription->transactions[0]->amount,
’paypal_email’ ⇒ $paypalPayment ? $webhook->subscription->transactions[0]->paypalDetails->payerEmail: null,
’card_brand’ ⇒ $paypalPayment? null : $webhook->subscription->transactions[0]->creditCardDetails->cardType,
’card_last_four’ ⇒ $paypalPayment? null : $webhook->subscription->transactions[0]->creditCardDetails->last4,
’typer’ ⇒ Payment::TYPE_SALE,
]);
тут если paypal заполнить нужно так, если карта иначе. Автозаполнение модели видимо не поможет… Вынести это все в модель Payment, передавая на вход массив с нужными данными и признак $paypalPayment, но как то не изящно. А как Вы такое пишите?
PS: Код не отформатирован, тк кнопка CODE в последнем хроме не срабатывает…
Кстати а как все старые миграции просто убить? Удалить их файлы просто?
Почему то теперь по команде migrate:rollback и migrate сразу несколько миграцией срабатывают
www-data@nf-web2:/www/nofiles55$ php artisan migrate
Migrating: 2017_10_09_102226_create_plans_table
Migrated: 2017_10_09_102226_create_plans_table
Migrating: 2017_11_02_210724_payments_table
Migrated: 2017_11_02_210724_payments_table
Migrating: 2017_11_08_153942_subscription_start_date
Migrated: 2017_11_08_153942_subscription_start_date
Migrating: 2017_11_10_113155_payment_braintree_id
Migrated: 2017_11_10_113155_payment_braintree_id
В общем видимо придеться миграции все переписать и пересоздать..
>Или ты спрашивал про автоматическое объединение миграций?
Типа того
>Дак ты приведи в порядок миграции сначала
А как уже прошедшие миграции привести в порядок? Откатить все и просто переписать?
Я имел ввиду не таблицы пересоздать, а именно что бы вместо всех этих миграций осталась одна... тк вся это их история честно ничем не полезна..
Данная команда вроде бы просто пересоздала таблицы, а миграции то остались все перечисленные...
>Используй одну миграцию на таблицу, особенно если работаешь один.
Так приходит идеи, что то одно нужно в таблицу добавить то другое.
Попробовал
www-data@nf-web2:/www/nofiles55$ php artisan migrate:fresh
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated: 2014_10_12_000000_create_users_table
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated: 2014_10_12_100000_create_password_resets_table
Migrating: 2017_08_30_122207_create_activations_table
Migrated: 2017_08_30_122207_create_activations_table
Migrating: 2017_08_30_131621_create_mediable_tables
Migrated: 2017_08_30_131621_create_mediable_tables
Migrating: 2017_08_30_173136_add_verified_col
Migrated: 2017_08_30_173136_add_verified_col
Migrating: 2017_08_31_090113_create_email_change
Migrated: 2017_08_31_090113_create_email_change
Migrating: 2017_08_31_092703_create_pass_change
Migrated: 2017_08_31_092703_create_pass_change
Migrating: 2017_09_08_083411_cashier_prepare
Migrated: 2017_09_08_083411_cashier_prepare
Migrating: 2017_10_02_203042_AddCurrentPeriodEndColumn
Migrated: 2017_10_02_203042_AddCurrentPeriodEndColumn
Migrating: 2017_10_07_121655_ChangeToBrainTree
Migrated: 2017_10_07_121655_ChangeToBrainTree
Migrating: 2017_10_09_102226_create_plans_table
Migrated: 2017_10_09_102226_create_plans_table
Migrating: 2017_11_02_210724_payments_table
Migrated: 2017_11_02_210724_payments_table
Migrating: 2017_11_08_153942_subscription_start_date
Migrated: 2017_11_08_153942_subscription_start_date
Migrating: 2017_11_10_113155_payment_braintree_id
Migrated: 2017_11_10_113155_payment_braintree_id