ahmedmsvb

Experience

9,200

1 Best Reply Awards

  • Member Since 6 Months Ago
  • 84 Lessons Completed
  • 0 Favorites

13th January, 2018

ahmedmsvb left a reply on Syntax Error Or Access Violation: 1071 Specified Key Was Too Long • 3 days ago

Hi,

You might need to check this: https://laravel.com/docs/5.5/migrations#creating-indexes [section# Index Lengths & MySQL / MariaDB]

28th December, 2017

ahmedmsvb left a reply on Laravel 5.4 Relation Between Models Not Fetching Correct Data • 2 weeks ago

Change this:

    public function brand(){
        return $this->hasOne('App\Brands', 'brandID');
     }

to:

    public function brand(){
        return $this->belongsTo('App\Brands', 'brandID');
     }

23rd December, 2017

ahmedmsvb started a new conversation [Opinion] Unused Controller Methods • 3 weeks ago

Hi,

I'm working on a mid-size project. At the beginning, I was always generating resource controllers (even if I'm not going to use all the methods)

Now, my controllers contain 50% working code and 50% idle empty methods generated from "make controller -r" command.

What is the best practice here:

  1. delete these methods and re-create them as necessary?
  2. or, just keep them just in case I need them later?

(I tend to follow approach #1)

Thanks,

30th October, 2017

ahmedmsvb left a reply on Switching From Development To Production Questions • 2 months ago

That's what the .env file is used for.

As you stated, use one .env file for local and the other for production.

Regarding the "env('APP_ENV', 'production')," code, it performs the following: 1- Looks for a variable named "APP_ENV" in the .env file. 1.a. If found => return its value. 1.b Otherwise, return the default 'hardcoded' value ('production' in our case).

Usually we add the .env file to our .gitignore. This ensures not overwriting the production or sharing our settings/passwords in different environments.

25th October, 2017

ahmedmsvb left a reply on Protecting A DELETE Route For The Already Logged-in Users • 2 months ago

But doesn't this break the single responsibility rule? (delete method will be responsible for two actions)

ahmedmsvb left a reply on Protecting A DELETE Route For The Already Logged-in Users • 2 months ago

First of all, thanks!

This will solve my problem the easy way (not sure if I' over-complicating things!)

But what if I need to implement something like the "confirm your password" page displayed by yahoo when editing important profile info?

The flow that I have to implement is: 1- User clicks delete => 2- display the "enter password" page => 3- user enters password and click submit => 4- call the delete action on my model (somehow)

I have several Model objects with their respective "delete" actions, so step #4 needs to be dynamic.

ahmedmsvb started a new conversation Protecting A DELETE Route For The Already Logged-in Users • 2 months ago

I created an application that enforces the users to keep logged-in always (all routes have "auth" middleware)

During specific actions from the user (delete a record for example), I need the user to re-enter his password for verification.

I created a middleware called ConfirmPassword checking for a session-flashed variable (not the best option); if the variable is not set:

  • user must confirm his password
  • set the flash variable => true

The problem happens after I validate the user's password, where the old URL is removed from my session. I tried saving the url as well to the session, but this changed the method from DELETE to GET

Any ideas/help?

Edit Your Profile
Update

Want to change your profile photo? We pull from gravatar.com.