trip.somers

trip.somers

Member Since 4 Years Ago

Plano, TX

Experience Points
12,030
Total
Experience

2,970 experience to go until the next level!

In case you were wondering, you earn Laracasts experience when you:

  • Complete a lesson — 100pts
  • Create a forum thread — 50pts
  • Reply to a thread — 10pts
  • Leave a reply that is liked — 50pts
  • Receive a "Best Reply" award — 500pts
Lessons Completed
101
Lessons
Completed
Best Reply Awards
2
Best Reply
Awards
  • start your engines Created with Sketch.

    Start Your Engines

    Earned once you have completed your first Laracasts lesson.

  • first-thousand Created with Sketch.

    First Thousand

    Earned once you have earned your first 1000 experience points.

  • 1-year Created with Sketch.

    One Year Member

    Earned when you have been with Laracasts for 1 year.

  • 2-years Created with Sketch.

    Two Year Member

    Earned when you have been with Laracasts for 2 years.

  • 3-years Created with Sketch.

    Three Year Member

    Earned when you have been with Laracasts for 3 years.

  • 4-years Created with Sketch.

    Four Year Member

    Earned when you have been with Laracasts for 4 years.

  • 5-years Created with Sketch.

    Five Year Member

    Earned when you have been with Laracasts for 5 years.

  • school-in-session Created with Sketch.

    School In Session

    Earned when at least one Laracasts series has been fully completed.

  • welcome-newcomer Created with Sketch.

    Welcome To The Community

    Earned after your first post on the Laracasts forum.

  • full-time-student Created with Sketch.

    Full Time Learner

    Earned once 100 Laracasts lessons have been completed.

  • pay-it-forward Created with Sketch.

    Pay It Forward

    Earned once you receive your first "Best Reply" award on the Laracasts forum.

  • subscriber Created with Sketch.

    Subscriber

    Earned if you are a paying Laracasts subscriber.

  • lifer Created with Sketch.

    Lifer

    Earned if you have a lifetime subscription to Laracasts.

  • evangelist Created with Sketch.

    Laracasts Evangelist

    Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.

  • chatty-cathy Created with Sketch.

    Chatty Cathy

    Earned once you have achieved 500 forum replies.

  • lara-veteran Created with Sketch.

    Laracasts Veteran

    Earned once your experience points passes 100,000.

  • 10k-strong Created with Sketch.

    Ten Thousand Strong

    Earned once your experience points hits 10,000.

  • lara-master Created with Sketch.

    Laracasts Master

    Earned once 1000 Laracasts lessons have been completed.

  • laracasts-tutor Created with Sketch.

    Laracasts Tutor

    Earned once your "Best Reply" award count is 100 or more.

  • laracasts-sensei Created with Sketch.

    Laracasts Sensei

    Earned once your experience points passes 1 million.

  • top-50 Created with Sketch.

    Top 50

    Earned once your experience points ranks in the top 50 of all Laracasts users.

Level 3
12,030 XP
Sep
16
3 days ago
Activity icon

Replied to Getting 401 On API Calls Using Passport - Malformed JWT Header

I finally tracked this down to a couple of issues on Github for Passport. It looks like there was a vendor package version that wasn't locked down and it created an edge case where the wrong set of packages resulted in double-decryption of the JWT token. Because I was on Laravel 6.x, I was able to upgrade to Passport 9.3 to solve this problem.

Activity icon

Replied to Getting 401 On API Calls Using Passport - Malformed JWT Header

I am having the exact same problem in Laravel 6.18 and Passport 8.5. I've been littering the framework and passport vendor folders with Log::debug() statements basically all day, and I can't figure this out.

I am having the problem locally on Homestead (perhaps an older version, but would that cause this?) and in production through Forge.

Aug
03
1 month ago
Activity icon

Started a new Conversation Clear Mutex Cache Entry For Specific Scheduled Task

The other day we had a task scheduled without overlap get stuck. The solution was to use php artisan cache:clear, but this produced side effects because it cleared cache for the entire application.

Is there a way to clear ONLY the mutex entry for a specific schedule task?

Activity icon

Awarded Best Reply on SoftDeletes + Observer = Volatile Test?

Okay. So it looks like the order of Eloquent events in 6.x is: updated, saved, restored. That's definitely a problem for this sequence.

Has anyone else encountered this type of issue of needing to restore (but also possibly update) relationships like this?

Jul
30
1 month ago
Activity icon

Replied to SoftDeletes + Observer = Volatile Test?

Okay. So it looks like the order of Eloquent events in 6.x is: updated, saved, restored. That's definitely a problem for this sequence.

Has anyone else encountered this type of issue of needing to restore (but also possibly update) relationships like this?

Activity icon

Replied to SoftDeletes + Observer = Volatile Test?

This appears to have upgraded from a volatile test on Laravel 5.8 to a 100% failure on Laravel 6.x, and I still don't know why it's happening. What am I missing?

May
08
4 months ago
Activity icon

Started a new Conversation SoftDeletes + Observer = Volatile Test?

I have a test that occasionally throws an exception, I'd guess about 3-5% of the time. It appears to be a race condition related to Eloquent model events and an Observer. I do not understand how there is a race condition.

Below, I have included my test and the related Observer.

    public function testRestore()
    {
        $deleteResource = factory(Engagement::class)->create();
        $deleteResource->delete();

        // sanity check -- assert that it was actually marked as deleted before we try to restore
        $this->assertTrue($deleteResource->trashed());

        $restoreResource = $this->service->restore($deleteResource);

        $this->assertInstanceOf($this->resourceClass, $restoreResource);
        $this->assertEquals($deleteResource->id, $restoreResource->id);
        $this->assertTrue($restoreResource->exists);
        $this->assertFalse($restoreResource->trashed());
    }
class EngagementObserver
{
    public function created(Engagement $engagement)
    {
        // create History entry
        $history = new History([
            'user_id'         => $engagement->user_id,
            'crm_customer_id' => $engagement->customer_id,
            'crm_contact_id'  => $engagement->contact_id,
            'activity_date'   => $engagement->started_at,
            'activity_json'   => json_encode([
                'action' => 'created',
                'type'   => $engagement->type ? $engagement->type->name : 'Unknown Engagement'
            ])
        ]);

        $engagement->history()->save($history);
    }

    public function updated(Engagement $engagement)
    {
        $history = $engagement->history()->first();

        // make sure activity_date stays correct
        $history->activity_date  = $engagement->started_at;
        $history->activity->type = $engagement->type;

        $history->save();
    }

    public function restored(Engagement $engagement)
    {
        $history = $engagement->history()->withTrashed()->restore();
    }

    public function deleted(Engagement $engagement)
    {
        $history = $engagement->history()->delete();
    }

    public function forceDeleted(Engagement $engagement)
    {
        $history = $engagement->history()->forceDelete();
    }
}

The exception thrown by the test is from the EngagementObserver's updated() method. Occasionally, $history winds up null and breaks the following lines. It should never be null.

You can see in the test that I'm creating an Engagement via factory. This will call the created() method in the observer to create the related History object. When the Engagement is soft-deleted, so is the related History. Then when the Engagement is restored, the related History is also restored. HOWEVER, sometimes the related History is not restored before the observer's updated() method executes.

Can anyone explain why this test winds up being volatile?

Apr
02
5 months ago
Activity icon

Awarded Best Reply on Laravel Mix / Vue Async Component Race Condition

SOLUTION

It appears that the async components were being requested before Vue was actually ready for them. That doesn't really seem possible to me, but it is what it is, I suppose.

const app = new Vue({
    el: '#app',
    data: {
        ready: false
    },
    mounted() {
        this.ready = true
    }
});

Inside of the <div id="app"> DOM element, my main content div now has a v-if="ready" directive. This apparently gives Vue the time it needs to appropriately handle the async components.

Everything appears to be working as expected now. Hopefully someone else can benefit from these notes.

Activity icon

Replied to Laravel Mix / Vue Async Component Race Condition

SOLUTION

It appears that the async components were being requested before Vue was actually ready for them. That doesn't really seem possible to me, but it is what it is, I suppose.

const app = new Vue({
    el: '#app',
    data: {
        ready: false
    },
    mounted() {
        this.ready = true
    }
});

Inside of the <div id="app"> DOM element, my main content div now has a v-if="ready" directive. This apparently gives Vue the time it needs to appropriately handle the async components.

Everything appears to be working as expected now. Hopefully someone else can benefit from these notes.

Apr
01
5 months ago
Activity icon

Started a new Conversation Laravel Mix / Vue Async Component Race Condition

I have recently grown my front-end to the point where I need to convert my component loading to async. This has all gone very well so far except that the async components are not always rendering. There appears to be a race condition related to when the components are processed on an initial page load.

I am using v5.0.4 of Mix with Laravel 5.8 and Vue 2.6.11.

Based on console logging, the components successfully mount on every page load. When a component fail to render, there are no console errors, and the DOM where the component tag was is just empty. Inspecting the resulting DOM, the component tag in the HTML has been removed, but the component template has not been injected in its place.

  • With the dev build from npm run watch, usually none of the async components are rendered. About 1 out of 20 times, either the first component or both components will render. The second has never rendered without the first.

  • With the prod build from npm run prod, usually all of the async components are rendered. About 1 out of 20 times, neither will render. I suspect the issue here is the same but the race condition is narrower with a prod build.

I cannot figure out what the race condition is, so I don't know what to do next. I do not understand how the components can always mount but not always render. I'm looking for someone to shed light on any part of this.

The only thing that kind of makes sense is that the async components are somehow mounting before the renderer is ready. Is that even a thing that can happen?

EDIT: Combined my original post with two replies to clarify problem as I currently understand it.

Activity icon

Replied to My Vuejs Component Are Not Rendering Into The DOM Only In Production

I have the opposite problem. It only renders in production (npm run prod) but does not render for development (npm run watch/npm run watch-poll). The Vue component is still present in Vue Dev Tools, and all of the data is correct. No errors. Console logging works just fine.