What's the easiest/best way to change laravel to use php for .env ??

@skunkbad Unfortunately Laravel uses .env files for configuration. The theory is, you’re supposed to use proper environment variables in your staging and production environments.

you can just delete the .env and make all the changes in the config (php) files.

The config files are php scripts that just return arrays. You can build logic in there if required.

If you review, eg, config/database.php you will note that the env value is checked first and if it does not exist then the value in the config file is used.

@Snapey, I have been using config files. But how about these:

APP_ENV=development

APP_DEBUG=true

APP_KEY=sjdflkjsdlkfjlskdjflksjdlfksjdlfkj

APP_TIMEZONE=America/Los_Angeles

they are all used by the config files. Most of thise mentioned in app.php

those are all set/read in /config/app.php. Anything that starts with APP_ is /config/app.php

@Snapey and @Cronix, thanks! @Cronix, are you the same guy I used to know from the CI forum?

@Cronix an x- codeigniter user, no way. I've heard worse.

Haha, yes, that was many years ago now! (I think Taylor was still using CI back then). How're things in Temecula (IIRC)?

@jldrw I built multimillion dollar sites using CI, that are still going strong today. CI was really good in it's day. Even Linus Torvalds said CI was the best framework back then. Laravel was just being developed at the time.

Yes, Temecula. Things are going OK here. I was working for the same guy for about 5 years, but got laid off. I ended up finding other work, but figured I should get more experience with Laravel. So I made a website, and just had a few things that I wanted to change, like this .env file. Overall I'm still not a big fan of Laravel ... maybe it is something that will grow on me.

I'm sure it will grow, I've been using it for about 3 years now and still have a lot to learn. There's just a lot more in Laravel, which makes it nice, but also a pain at the same time. So many layers data is traveling through from the request to the final output.

I've just been used to certain ways of doing things based on "best practices", and then see that the Laravel way is sometimes going against what I think is the right thing to do. I know you've heard it before, but the Facades usage stinks to me. Only other real gripe is that there are some holes in the documentation that wasted a few hours of my time.

Things I do like are the service providers and container usage. Although a few years ago I preferred CI-like magic routing, I do enjoy Laravel's routing features. I think I'll like it more when I use it a little more.

@skunkbad to show laravel flexibility I had a older app (different framework) that needed a quick upgrade, due to newer php versions

I chose for it to re-use the database helper

https://github.com/nova-framework/framework/blob/2.2/app/Helpers/Database.php

Just for this one small app. I then

<?php

namespace App\Helpers;

class DBS
{

    public static function __callStatic($method, $params)
    {
        $trace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 2);
        
        if (isset($trace[1]['class'])) {
            $class = $trace[1]['class'];
            $slh = strrpos($class, "\") + 1;
        } else {
            return null;
        }
        $model = "\App\Models\SMVC" . "\" . substr($class, $slh, -10) . "Model";
        $instance = new $model();

        return call_user_func_array(array($instance, $method), $params);
    }

}

Above is just to call the methods (pretty static looking)

So I could call model methods like

public function getDog($dogid)
    {
//code        
return $this->db->selectOne("SELECT * FROM " . PREFIX . "dogs WHERE dogid =:dogid", array('dogid' => $dogid));
//code
    }

and from controller

//code
$dog = DBS::getDog($dogid);
//code

Point is I can use various laravel goodies with older code, and as time went by I converted all to normal laravel code.

[I] just had a few things that I wanted to change, like this .env file.

@skunkbad A lot of frameworks are starting to configure applications this way, because storing sensitive configuration values (like API keys and database credentials) should be done in environment variables. Parsing an .env file emulates this.

I know you've heard it before, but the Facades usage stinks to me.

Façades is a strongly-contested “feature”. But you don’t have to use them; you can inject your dependencies if you wish.

@jlrdw , that is nice. I can appreciate Laravel, and I think it's important that I know my way around it. I think my biggest problem is me. After 12 years working with PHP I tend to want to be stubborn and do things my way ... which is easier than learning a new way.

@martinbean , it's all good. But in my case I want to dynamically switch the environment on some small projects where I'm the only dev. Old habits are hard to break.

I want to dynamically switch the environment

@skunkbad Then use different .env files with these different environment settings.

@martinbean , I'm not familiar with the ability to have more than one .env file. How does one switch between .env files dynamically?

@martinbean , I figured it out. Just pass a filename to Dotenv's constructor. Thanks for the idea.

don't overlook the fact that putting secrets in .env will usually keep them out of your repositories so that you don't accidentally commit them to version control.

@Snapey, dually noted. Being that I'm usually the sole developer working with private repos, committing secrets isn't usually a concern. That's why for me the ability to dynamically switch .env files based on environment is such a nice thing.