I wanted to see what would be the proper way to call a .env file inside my project? One of the developers that I'm working with, just told me that everything is setup and that all I would need is to create a .env file in the root.
Here is how the function is being called:
$settings = [
'name' => 'DB_NAME',
'user' => 'DB_USER',
'password' => 'DB_PASSWORD',
'host' => 'DB_HOST',
];
I have my .env file setup as the following (I've created the local database using the below credentials):
cc
cc_user
Z_______0!
localhost
Is this the correct method? Do I need quotes around the name, user, password and host inside the .env file? I am doing all this on a localhost environment.
Your .env file should look like this:
DB_NAME=cc
DB_USER=cc_user
DB_PASSWORD=Z_______0!
DB_HOST=localhost
You don't need quotes here
I suspect you need to set up your .env file with KEY=value pairs, something like
DB_NAME='mydatabase'
Your code sample doesn't give enough to know for sure, but the first thing that comes to mind for me is npm's dotenv package, documentation for which can be found here - https://www.npmjs.com/package/dotenv
Related
I'm putting my Laravel project in production and I've clone it from GitHub to /home/myuser/repositories/myuser/MYPROJECT-app, and my public Laravel folder content is in /home/myuser/public_html.
I've changed (project location)/app/Providers/AppServiceProvider.php and add:
$this->app->bind('path.public', function() {
return '/home/myuser/public_html';
});
To the Register function. I changed the index.php from the public folder to match my project location and everything works well, except when I try to upload a file using the method:
Storage::disk('public')->put('myfiles/', $request->myFile)
It is stored in /home/myuser/repositories/MYPROJECT-app/public/storage/myfiles instead of /home/myuser/public_html/storage/myfiles.
(Note: I cannot use symbolic links because some restrictions with the server configuration, so I'm trying to store all the files within a storage folder within the public path).
I'm guessing I'm missing some configuration to tell Laravel to store the uploaded files in /public_html/storage instead of MYPROJECT/public/storage, but I can't find which file I have to change.
This should work for you, but I cannot assure it 100%. (I will be using Laravel 9.x).
In your config/filesystems.php, go to the disks index and add a new one just for testing purposes:
'outside' => [
'driver' => 'local',
'root' => realpath('/home/myuser/public_html'),
'url' => env('APP_URL').'/storage',
'visibility' => 'public',
'throw' => false,
],
As you can see, we are using realpath('/home/myuser/public_html'), but have in mind that url requires a symlink and you said it is not possible, so you are basically done there.
Let me know if this partially works, does it works but the URL not? Can you read files, store them, etc?
I have a simple web app. I have a production database for the live version, and a test database for development. I store the database credentials in a config file, like so:
<?php
return array(
'hostname' => 'myhostname',
'username' => 'myuser',
'password' => 'mypassword',
'dbname' => 'myLiveDB',
);
?>
This file is tracked by git. On the development branch I want to have file with the same name, just with different credentials. I do my work in this branch, test things out and then merge into master when I want to deploy a newer version.
I never want to see this file change during a merge/rebase operation. Each branch should always keep its own version and it should only be updated by committing directly onto the branch.
What I have considered so far:
.gitattributes files with merge=ours for the config file + git config --global merge.ours.driver true. I don't think this works for rebase, which is a problem. I'm also not sure if every other developer working on this would need to update their config manually, or is there a way to change that setting on a repository level?
ditch the config file, rewrite everything to use environment variables. set them manually for the server and for each dev.
have a config_test.php and a config_prod.php in the repository. When deploying, have the script take a look at what branch we are deploying from and copy the the correct file while renaming it to config.php
I guess the third point might be good and a right method. In spring-boot (java) we used to have different profiles in yamal file (application.yml) with names like dev, test, prod etc and spring itself will take the exact file when it is running in that specific environment. Check something like is there or not.
But in your case, just think whether you need a file which is under git or not.
Think that you have a file under your home directory (say /home/myname/testfile/development.properties). And change the code so that, if this properties file exists then take it otherwise take the other one.
I need to make some slight configuration changes in my local dev env.
Thus, I would like to know what is the "best practice" in distinguishing between environments.
I would like to have only one config file which will behave differently depending on which environment it is executed.
Common and good practice is to use different .env files on different environments.
Basically, a .env file is an easy way to load custom configuration
variables that your application needs without having to modify
.htaccess files or Apache/Nginx virtual hosts. This means you won't
have to edit any files outside the project, and all the environment
variables are always set no matter how you run your project - Apache,
Nginx, CLI, and even PHP 5.4's built-in webserver. It's WAY easier
than all the other ways you know of to set environment variables, and
you're going to love it.
You can use some already created packages to add this to your project. Check this one: https://github.com/vlucas/phpdotenv
Example (just for a demo, not production ready code!):
Note! You will need to add .env to .gitignore file to keep it not synced between environments.
Development .env file:
DB_HOST=localhost
DB_USER=root
DB_PASSWORD=
Production .env file:
DB_HOST=192.168.10.1
DB_USER=dbUser
DB_PASSWORD=123456
Possible config.php file:
<?php
// add composer autoload somewhere here...
$dotenv = new Dotenv\Dotenv(__DIR__);
$dotenv->load();
return [
'db' => [
'host' => getenv('DB_HOST'),
'user' => getenv('DB_USER'),
'pass' => getenv('DB_PASSWORD'),
]
]
I'm making a web-application which run under Laravel 5, and I need to incorporate Withings user's Datas.
I read the API's doc, but I don't understand it very well.
What are the authentication steps, and the order?
Have you any example in aim to help me?
Withings seems to use OAuth1, you can find an authentication flow of the standard, which help to see the global picture, at https://oauth.net/core/1.0/#anchor9 :
Their API is described at http://oauth.withings.com/en/api/oauthguide and also https://developer.health.nokia.com/api (with a request tester), but you probably already got that.
There's some libraries (with the composer name) you might find interesting to use (or read to help with comprehension):
https://github.com/Zn4rK/php-withings/ (paxx/withings)
https://github.com/cfournel/withings (huitiemesens/withings)
Setting Up the Environment
I am going to assume you are starting off with a fresh Laravel 5 installation, but you can skip any of these steps if you have already done them. First off, you are going to set some environment variables in the .env file at the root of your project. Basically, these have to do with the database configuration
APP_ENV=local
APP_DEBUG=true
APP_KEY=8wfDvMTvfXWHuYE483uXF11fvX8Qi8gC
DB_HOST=localhost
DB_DATABASE=laravel_5_authentication
DB_USERNAME=root
DB_PASSWORD=root
CACHE_DRIVER=file
SESSION_DRIVER=file
Notice the APP_ENV, DB_HOST, DB_DATABASE, DB_USERNAME, and DB_PASSWORD variables. The APP_ENV variable tells Laravel which environment we wish to run our web application in. The rest of the database variable names are pretty obvious.
This is all you need to do to configure the database connection. But how does Laravel make use of these variables? Let's examine the config/database.php file. You will notice the use of the env() function. For example, env('DB_HOST', 'localhost'). Laravel 5 uses this function to capture variables from the $_ENV and $_SERVER global arrays, which are automatically populated with the variables you define in the .env file.
there is whole tutorial on this
have a look
http://code.tutsplus.com/tutorials/using-laravel-5s-authentication-facade--cms-23461
I use a global array to define certain configurations for my application. But so far I've read that globals are bad practice and should be avoided. This global is read-only, so I'm not altering it in any way in my code.
What would be the correct way of defining configuration settings?
$GLOBALS['config'] = array(
'mysql' => array(
'host' => 'localhost',
'username' => 'user',
'password' => 'password',
'database' => 'database'
),
'navigation' => array(
'Home' => array('/', '/index.php'),
'Sign up' => array('/signup', '/signup.php'),
'Log in' => array('/login', '/login.php')
)
);
Start with a Configuration class to hold all settings in a collection of key->value pairs and getter and setter methods. This class is part of the normal application code.
To be able to handle different settings for each environment, like the connection parameters in your example, use multiple files.
For each environment a folder exists to store the all environment-specific configuration files.
One of the files stored here is a script that:
creates a static configuration object
sets all configuration parameters to the values for that environment.
Other parts of the application use this static object to get the settings from.
The files in the different folders have equal names, for example in this structure:
- config
- development
- config.php
- staging
- config.php
- production
- config.php
During deployment the configuration files for the environment that you are deploying to are included. What I do is also put the deployment scripts in these folders.
This setup supports multiple environments and you can keep the files with configuration settings under version control.
I don't have much of an idea of PHP. But with respect to OOP, you can create a class(possibly named Config) which contains static read-only variables. And then use them as follows
Config.mysql and Config.navigation