JBF

JBF

Member Since 11 Months Ago

Experience Points
13,420
Total
Experience

1,580 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
126
Lessons
Completed
Best Reply Awards
0
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
13,420 XP
Jul
14
2 months ago
Activity icon

Started a new Conversation Nova Metrics - Change Start Date Of Range

I might be missing something but it seems to me that the ranges used with Nova metrics always have to start from today.

So for example, I can easily show the total sales from the last month or the last 2 months or the last 3 months, etc but I can't show the total sales in just the previous month or the month before that.

I would like to have a metric where the range is by month. So the drop down would be a list of the months. Something like...

This month, Last month, May, April, March, February, January, December, November, ...

Does anyone know if this is possible without custom building the metric?

Jun
03
3 months ago
Activity icon

Replied to Laravel Scout + Algolia - Global Search On Multiple Entities

This functionality is now supported by installing 'scout extended' from Algolia...

https://www.algolia.com/doc/framework-integration/laravel/advanced-use-cases/multiple-models-in-one-index/?language=php

I just set it up today. It works very nicely.

May
03
4 months ago
Activity icon

Replied to Passing Variables To The Controller But Not From The URI

I just figured it out by looking at the symfony docs. You can do this...

Route::get('/foobar', '[email protected]')->defaults('message', 'hello world');

Now I can use request('message') in the controller.

Thanks for your help everyone.

Activity icon

Replied to Passing Variables To The Controller But Not From The URI

Thanks but I don't want them to be part of the uri. The user should not be able to see these values. They would just be internal.

Activity icon

Replied to Passing Variables To The Controller But Not From The URI

Hey guys, thanks for the suggestions. I’m afraid the example was too simplistic. Let me explain a different way. I’ve come across various situations where I would like to do some minor customisation which is dependent on the route and although I could easily push it to the database, or have extra controller methods, some times it would just be easier to pass a parameter from the route definition. I’ve had a break from coding for years but I used to do exactly this with symfony 1.4 where you could easily add extra parameters to the request object from your route file independently from any uri params. In those old days it was a yaml file. A simple example would look like this…

billing_address_show:
  url:                      /billing-address/:id
  param:                    { module: Address, action: Show, type: billing }

delivery_address_show:
  url:                      /delivery-address/:id
  param:                    { module: Address, action: Show, type: delivery }

Both the id and the type parameters could then be grabbed from the request object.

Apr
30
4 months ago
Activity icon

Replied to Passing Variables To The Controller But Not From The URI

Thanks but my question specifically asks if there is a way which avoids using a separate controller method and avoids simply returning a view. I know those options are available. I'm wondering if there is another way?

My example is just very simplistic. There have been a few times when I would like to hand my controllers a value directly from my routes file but I can't see how to do it. I also want to be able to use route caching, so I can't use a closure.

Activity icon

Started a new Conversation Passing Variables To The Controller But Not From The URI

For instance you have 3 static pages, index, about and contact. Each just has a view but you don't want to return that from the route because you want to use route caching.

Instead of making a controller method for each page, is it possible to do something like this in the web.php ...

Route::get('/', '[email protected]', ['page' => 'index']);
Route::get('/about', '[email protected]', ['page' => 'about']);
Route::get('/contact', '[email protected]', ['page' => 'contact']);

And then the controller method

public function showpage(Request $request, $page)
{
	return view($page);
}

I know the above doesn't work but hopefully it illustrates my point. Thanks!

Apr
10
5 months ago
Activity icon

Replied to Are Long Sessions Bad?

@snapey So whenever I visit a website, like Amazon, where they keep me logged in but not authenticated, or they remember my settings between visits, that will / should be done with a cookie, not a long session length? I don't fully understand why that is better, but if that is the best practice, I'm happy to follow it.

There is just one last problem that I'm not sure how to solve. If my session stays at the laravel default of 2 hours, if my user leaves the page open and goes away for a while, for instance, they start browsing at night and return to the page in the morning, the session has ended. So, if they then click any view settings; order by price, filters, grid vs list etc. Or if they are on a contact us page and complete a form, or a product page and add to basket, the CSRF will fail and the user will have to repeat the action after the page refreshes. This is a nasty user experience. Is there a good solution for this problem? To get around it could I extend the session to say 1 week? If a user leaves a page open that long and doesn't use it, I think it's reasonable to require a refresh but every 2 hours seems annoying to me.

Activity icon

Replied to Are Long Sessions Bad?

@jlrdw ps. thanks for that link. It is a helpful discussion

Activity icon

Replied to Are Long Sessions Bad?

@jlrdw In my own experience, I often put things in my basket before I sign in. Also, I often return to a website a few times before I decide to go ahead. A perfect example would be a website selling clothes. I'm sure many people use their basket as a place to collect "items they're thinking about" and then when they're ready, they make the final selection and proceed with the purchase. So, they could easily take a few days to go through that process. For very expensive items, for instance jewellery, I'm sure many people deliberate for weeks. In fact the more expensive the item, probably the better retail logic to make sure the basket is remembered. No-one wants to lose a high value sale.

So, there are definitely situations where storing, in some manner, the basket of a user either unregistered or not logged in, makes good sense. I agree that this won't work / be needed for all use cases. And yes, I would think any basket should be checking for changes in stock and pricing, every time it is instantiated.

I guess whether you use a separate DB table for the basket of a logged in user vs a not logged in user, would be a case of coding style. However, i'm not sure that I can see any benefit? It's trivial to check the last_modified date of all entries without a user_id and delete them after a certain length of time.

Apr
09
5 months ago
Activity icon

Replied to Are Long Sessions Bad?

@snapey I've just realised that I misunderstood how session cookies work. I've just been checking and it seems the session cookie value is regenerated every time the page is loaded. But I suppose you could store the ID of the basket in the session for unauthenticated users. I still don't understand why it is better to have a separate cookie for that?

Activity icon

Replied to Are Long Sessions Bad?

@jlrdw actually, sorry, I do understand what you mean, I was reading too quickly! But my point still stands, I think from the point of view of making sales, it would be best to store the basket of potential new customers for a decent time.

Activity icon

Replied to Are Long Sessions Bad?

@jlrdw Thanks but that seems to contradict your previous comment? I guess I'm not understanding right... The default session in laravel is 2 hours. If I don't extend the session and i don't store the basket in the database with a reference in a cookie, the user will lose their basket after 2 hours. This could just be having lunch and walking the dog! Sometimes I might take a few weeks to make a purchase if I'm buying something expensive. If the site sells lots of items, the quickest way to find what I'm thinking about is to return to my basket. So, I think even for unregistered users, storing the basket for at least a month is sensible for conversions. Or do you mean that I shouldn't store a basket for every visitor? Just people who put something in their basket? That makes sense to me.

Activity icon

Replied to Are Long Sessions Bad?

Thanks Snapey. This is starting to make sense to me but I'm still a little confused. Why do you need a separate cookie for the shopping basket? Couldn't the basket table have a field for the session id? I don't understand why it's dangerous to have a long session cookie timeout but safe to have a long basket cookie timeout? Is it considered good practice that the session is reserved for authenticating users and flash messages and not much else? Sorry, you can tell that I'm a hobby coder rather than a professional ;-)

Activity icon

Replied to Are Long Sessions Bad?

Thanks both of you for the advice.

So, maybe I started with the wrong question. Sounds like I should have asked, what's the recommended way of storing a shopping basket? One that allows unauthenticated users to keep their basket for a decent length of time and allows authenticated users to use their basket on multiple machines.

Do you think storing the database id of a shopping basket in a cookie is the way to go? With a field on the user table to store the basket id once they log in? Maybe merging the contents if they differ? Then just delete any idle baskets not associated with a user after a certain length of time.

Apr
08
5 months ago
Activity icon

Replied to Are Long Sessions Bad?

Thanks Snapey. That's helpful.

If a user explicitly logs out, then yes I would consider that a clear signal to end the session. And yes, whilst the user is logged in, the basket and view settings can be stored in the database.

But that leaves two scenarios -

  1. Before the user registers. New clients who are spending some time thinking about a purchase.

  2. A registered user on a device they use regularly where they don't feel the need to log out. In this case, if we only store the basket and view settings in the DB, then the user has to re-authenticate even for content which is not sensitive and generally has no need to be secure. (unless they are buying gifts for their affair!)

I take your points A + B on board. In the case of what I'm building, I don't think either would be a big issue. Are there any other security issues to consider?

But I guess what I'm really trying to establish is this - is there an accepted best practice for session length for e-commerce? Something that balances security, user experience and conversion rates. I've been looking at some big online retailers and the expiry dates on their cookies, and of course, I don't know what each cookie relates to but many of them expire in 1 year and some in many years. Could they be storing the user session for a year?

Apr
07
5 months ago
Activity icon

Started a new Conversation Are Long Sessions Bad?

Ok, I know that's too general a question. So to expand...

For an e-commerce platform, would it be considered bad practice to have a long session length so that items in the basket or view settings (list or grid, order by, etc) are stored in between visits?

Obviously, the authentication would be kept to a secure, short time. The default in the Laravel auth config is 3 hours and I would be happy if the user has to re-authenticate every 3 hours to get to protected content.

I've tried to investigate this issue online but I find so many different opinions that I can't decide. For the site I'm working on, I think a 1 month session length would give a good UX experience. But is this too long from a security point of view? Thanks.