So now that we have that flow created of creating a new episode and a new listening party from this dashboard component, and we're then redirected to that listening party, why don't we start working on how we can grab that information from the podcast episode itself? Because we're relying on the User to input that information, so why don't we put a little bit more onus on the User? Maybe we can start with just cutting everything else out and we'll just start with RSS feeds for now. So I think the RSS feeds alone is going to be a solid choice because then, once we start to have podcasts that are entered into the application, we can maybe have a search for an existing podcast episode.

to have podcasts that are entered into the application, we can maybe have a search for an existing podcast episode. But for now, let's go ahead and remove any mention of YouTube link or direct episode link and we'll just say this is an RSS feed. So instead of podcast, we can still say media URL here, but we'll say, how about the podcast RSS feed URL? And then we can say, entering the RSS feed, we'll grab the latest episode. Perfect. So now we have that placeholder and we have a description. Since we've changed that, we just are looking now for the podcast RSS feed URL.

So now we have that placeholder and we have a description. Since we've changed that, we just are looking now for the podcast RSS feed URL. Now why don't we start a Queue job that we can kick off and this can be a Job because we don't necessarily want this as a long running process on our server when we deploy it. So we would want a Job to kick off before we even redirect to this route. We would want to first make sure that we kick off this job to grab the episode, to create the podcast and get the necessary information from that episode that we need and even the podcast that we need. And the great thing is the RSS feed provides all of that. I believe we might have to dig a little deep for some of the things we need, but it should

And the great thing is the RSS feed provides all of that. I believe we might have to dig a little deep for some of the things we need, but it should give us a great starting point. Now before I forget, we want in this XDateTimePicker to not be able to select a previous date. And thankfully in the WireUI components, we can do that pretty easily. We can just say min is equal to, and we can say now(), and that's going to be for UTC time. That's not going to be the greatest because if I was to select that and then refresh this, I can select, it's still Friday where I'm at. So I can't necessarily select Saturday.

I can select, it's still Friday where I'm at. So I can't necessarily select Saturday. So why don't we go ahead and change it to now, and we can say subDays, and maybe we'll say subDays of 1, and that should give us the time that we need. So now let's start working on that background job to get the information from the RSS feed so that way we can have all the data in place to move forward. So in our terminal, we can go ahead and say php artisan make:job, and then we want to call this, we can say ProcessRssFeed, or maybe like ProcessPodcastUrl. That might be a better option because now we are, it's a podcast URL and the RSS might not be the best way of describing that because we are processing the podcast URL that this

That might be a better option because now we are, it's a podcast URL and the RSS might not be the best way of describing that because we are processing the podcast URL that this user is inputting. So when we're building out this application from start to finish, a lot of these things are just more gut feelings in the sense of what do you think is the best representation for what you're expecting to do with that job, with that component, with those columns on the table. It's not going to be perfect every single time, and you can be flexible to change it just like we have done with a bunch of different things already. So in that job, so process podcast URL, we need to accept, why don't we accept a RSS

just like we have done with a bunch of different things already. So in that job, so process podcast URL, we need to accept, why don't we accept a RSS URL. So in here we can accept the RSS URL and set that here. Now what are we going to do with this RSS URL? Well first, let's go ahead and write this out. Well, we need to grab the podcast name information. We need to grab the latest episode. We need to then add the latest episode media URL to the existing episode that was already created because in our dashboard when we're actually creating this episode, we're creating

We need to then add the latest episode media URL to the existing episode that was already created because in our dashboard when we're actually creating this episode, we're creating a media URL so that when we process the podcast URL, the actual RSS feed, we can say, we can set or update the existing episode's media URL to the latest episode's media URL. We will need to find the episode's length and set the listening party duration, in this case listening party end time, to the start time plus length of the episode. Okay, I think that's a good setup for what are the things that need to happen in this job. Now before we start writing this code, let's make sure that our local environment is set up to run these queue jobs so that we can see what's actually happening behind the scenes.

Now before we start writing this code, let's make sure that our local environment is set up to run these queue jobs so that we can see what's actually happening behind the scenes. Now if you've followed this tutorial, you will see that the environment variable that is default with the options that we selected when we ran laravel new has the queue connection of a database. So in our terminal, if we run php artisan queue:work, we will automatically be able to see any jobs that we process in this queue. I'm going to stop that because any changes that we make, we're going to have to restart this queue worker.

this queue worker.