vism

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

Поймите, что, во-первых, программист учится всегда, потому что постоянно что-то меняется в его работе. Во-вторых, он постоянно ищет решения новых проблем самостоятельно, а не применяет решения, которые ему показали во время учёбы. И, в-третьих, программирование на 90% состоит из рутины, которая никак не тянет на развлечение.

Я не исключаю, что вы сможете, наконец, справиться с всем этим избытком эмоций, обуздать тягу к немедленной гратификации (вознаграждению за совершенные действия), избавиться от эффектов современного воспитания, которое вы получили, но что в вас останется после этого, я сказать не могу. Могу только сказать, что вам на вход в профессию понадобится больше сил и времени, чем если бы вы уже сейчас могли спокойно ковыряться с интересом в каких-то (пусть и самых простых) задачах, проводя за этим часы. Маленький совет: забудьте о том, что видеокурсы существуют, вообще. Только печатная информация: книги, статьи. Видео крадёт время.

Всё сильно зависит от технической реализации и желания ФНС ловить фрилансеров.

В моём представлении сама по себе оплата НДС Upwork'ом ещё не значит, что они будут передавать данные о доходах фрилансеров. Они обязаны будут передавать данные о своих доходах. Хотя при желании одно из другого получить вполне реально. Это что касается количества денег.

Сам факт некоего неопределенного дохода проверить будет очень легко, ведь Upwork обязан будет сообщить, кто приобрёл его услуги (оплатил комиссию). А единственная услуга на Upwork - это возможность заработать.

Думаю, для тех, кто работает в белую, эта новость только к лучшему. Никаких больше налоговых сусликов и "налогов на гугл".

Ну а какие варианты? Фронт где-то далеко в системе клиент-сервер. Если фронт закончил запрос к серверу, то для него, что очередь там, что не очередь. Т.е. в вопросе два момента:
1. Как фронт получает обновление статуса: либо обращается к нужному ендпоинту, либо поднимает веб-сокет соединение и слушает.
2. Как бэкенд понимает, что Job готов. Насколько я помню, в Laravel есть события для этого. Дальнейшая реализация обработки событий зависит от того, как фронт "слушает" изменения - выставляешь ты флаг для ендпоинта или отправляешь событие в сокет.

Blade это обертка, которая несет в себе незначительные отличия от нативного php

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

class MyTest extends \PHPUnit\Framework\TestCase
{
    public function testDoSomethingOne(): void
    {
        /** @var \PHPUnit\Framework\MockObject\MockObject $mockOfA */
        $mockOfA = $this->getMockBuilder(A::class)->getMock();

        $mockOfA->expects($this->once())
            ->method('setData')
            ->with(20);

        (new B)->doSomething($mockOfA, 1);
    }

    public function testDoSomethingTwo(): void
    {
        /** @var \PHPUnit\Framework\MockObject\MockObject $mockOfA */
        $mockOfA = $this->getMockBuilder(A::class)->getMock();

        $mockOfA->expects($this->once())
            ->method('setData')
            ->with(10000);

        (new B)->doSomething($mockOfA, 100);
    }
}

The practice of replacing an object with a test double that verifies expectations, for instance asserting that a method has been called, is referred to as mocking.

https://phpunit.de/manual/6.5/en/test-doubles.html

Разумеется, такой режим есть. И разумеется, он совершенно неизвестен тем, кто учил похапе по видеокурсам.
PDO умеет возвращать данные в десятках разных форматов, и в частности индексировать выборку первым полем указанным в запросе
$data = $stmt->fetchAll(PDO::FETCH_UNIQUE);
В случае, если нам нужен словарь то для этого есть режим, который возвращает не вложенные массивы, а одномерный массив, который состоит из пар ключ-значение

$data = $pdo->query("SELECT id, name FROM table")fetchAll(PDO::FETCH_KEY_PAIR);

В общем, с помощью флага --profile удалось установить причину. Все упиралось в недостаток памяти. Увеличил объем RAM до 1Гб (было 384Мб) и update успешно завершился. Пик использования памяти при этом был равен 569.84Мб.

Дополнительно, для тех, кто в будущем столкнется с подобной проблемой, на github я обнаружил еще одну возможную причину такого зависания. Суть ее, как я понял, заключается в том, что при большом количестве зависимостей composer может "зависать" из-за большого количества их возможных комбинаций. Такое случается очень редко, но теоретически возможно. Решение в данном случае: задать требования более строго. Например, использовать более конкретные рамки версий, или вообще указать точную версию.

Базовые знания - потрачено...
У вас инпуты с одинаковыми именами, соответственно передаются они один за другим на сервер, где воспринимаются как переменные с соответствующим именем. Логично что последний зачеканый чекбокс тупо затрет предыдущее значение переменной с тем же именем.
Самое простое решение - добавить "индивидуальности" именам полей.
так в скрипте будет выводиться как многомерный массив c ключом категорией:

<input type="checkbox" name="seller[categ][<?php echo $category['category_id']; ?>]" checked="checked" value="<?php echo $category['category_id']; ?>"/>

так будет выводиться как многомерный массив c автоинкрементным ключом:

<input type="checkbox" name="seller[categ][]" checked="checked" value="<?php echo $category['category_id']; ?>"/>

а так как обычный массив:

<input type="checkbox" name="seller_categ_<?php echo $category['category_id']; ?>" checked="checked" value="<?php echo $category['category_id']; ?>"/>

CDN не хранит данные, file storage не парсит, object storage не хранит файлы, laravel не CDN. Детализируйте вопрос

Второе - не совсем по теме Eloquent'а. Он про магию, и тут скоупы приходятся к месту. А если нужны будут еще условия? Ну, допустим остаите первым вызов этого метода, а если нужны будут еще условия в виде методов? Вот для чего были созданы скоупы, так что первый вариант - однозначно лучше.

Далее: Product:: под капотом как раз и делает (new Product)-> , только кроме этого он может делать и что-то другое, о чем вы не знаете, поэтому я бы использовал Product:: хотя бы ради этого и какой никакой стандартизации.

Далее: почему бы не сделать $user->products()->whereSlug($slug)? Учитывая контекст, смею предположить что именно такой запрос вам нужен не так уж и часто, а значит это - неплохое решение. Нужен будет эктив - ну добавляете скоуп в модель Product и имеете счастье, типа $user->products()->whereSlug($slug)->isActive(). Последние два метода относятся к конечной модели Product, а значит их дублировать не нужно, а вот релейшены в разных моделях (

$user->products(), $page->products(), $something->products()

) - нужно, так что это правильный вариант.

Тем более, Product не должен быть ответственен за методы юзера (как в вашем втором варианте), а если туда напихать еще несколько от разных моделей, со всякими $active = true - получится каша.

TL;DR: Придерживайтесь того, что предлагает Eloquent, и будет вам счастье.