I have a Laravel 5 application that works perfectly on multiple servers. But on a specific Server, the values of my .env file are not readable via the \Config facade, or the config() function.
Let me give an example with the APP_DEBUG environment entry, the same goes for all other entries.
My .env file (the same on all servers) consists, amongst others, of the following line:
APP_DEBUG=false
through the use of $app->environmentFile() I know, that my .env file is used.
When I directly output the debug param via env('APP_DEBUG'), I get the correct value (false), but all approaches to read the value from the config (\Config::get('app.debug'), config('app.debug'), app('config')->get('app.debug')) only returned NULL.
I also tried to clear the cache via artisan cache:clear, because I thought, there could be some caching issue, but that didn't change a thing.
I also tried set the permissions of the .env file to 777.
When I output my whole config via \Config::all(), all values that are correctly set on my other servers, are NULL on this specific server.
Any suggestions?
Edit for clarification:
The project is set up twice on the same server on two different Virtual hosts, one to serve the dev.domain.tld (for development), and one to serve the www.domain.tld (for production). Both folders use the same webserver, the same PHP version and the same user
Related
Laravel 8 has config files for auth, mail, broadcasting, queue, services, session .etc, but I am not using those functionalities for my specific application.
Is it fine to leave the config files (and corresponding .env settings) untouched, or is it better to delete those files?
I am talking about both in terms of performance, execution correctness and security, but not in terms of code readability here. In other words I am talking about "real effects to my application".
Short answer:
it's not recommended to do something like that if you don't wanna go out from laravel's ecosystem.
TL;DR:
Since Laravel version 5.1 there was some general changes about the configurations. It means it for your v8 as well.
In every today's laravel project you have bootstrap/cache folder, which includes some bootstrap/cache/.gitignore file for ignoring other files. That ignored (3-4) files are actually cached files, which were creating automatically, and you can't do anything about that in-the-box.
The bootstrap/cache/config.php file is responsible for all the configurations, and it's creating as from config/*.php config files, as well as from all the config files from vendored dependencies. It means, everytime when you're using your laravel app, that file will be created automatically using
all the project-specific configurations
all the vendored configurations
environment variables from .env.
Note: there might be a case, when some in-box package (like laravel's default mail.php config file) or some 3rd-party package (unlikely, but anyway) could not have their own config file, so in vendor core codes there may be a confidence, that it can get some configs exactly from their apropriate config/*.php file, so in that case it's not recommended to delete that. For example, when you're deleting config/mail.php, and you're using that, in both cases you'll have approximately the same cached config, except some small mail-config-features (optimization there only approx. ~60 lines of human readable lines), but in that case you can't use laravel's Mailing functionality.
The sense is that when you want to override some configs, you're just creating some own config file(s) (in general with the same name as it's in vendor's appropriate location), so that laravel can do caching from config/*.php, but not from vendor/username/package/path/to/config.php.
So for optimization, laravel doing that caching process once, and after whole usage it will retrieve conifigs only from bootsrapped bootsrap/cache/config.php configs.
That's why everytime you're changing something in some config/*.php file or/and in .env file, you need to clean (manually) and it will be created again automatically
OR just:
there's a in-build command like:
# this will clean all the application caches
php artisan optimize
# or only for cleaning and recreating config
# this is an old-school version, but still used
php artisan config:cache
All this means, that you don't need to delete some config file from config/*.php, because laravel will check is the cached file exists, (if not, then it will create caches anyway from vendor configs), and all the time it will read them from cached files.
Conclusion: All this means, that
that is not related with security and there's nothing to do about that
if you feel that decreasing the cached bootstrap/config.php file content from 1566 lines to 1500 lines it's a way of optimization, then you're free to do that, but you should know that it could make some problems in future.
Subjective recommendation: in human language, i don't recommend to do something like that. Anyway you can do that, may you can improve something, that couldn't do another contributors yet. But it will not give a real effect to your app.
Sorry, pretty simple question:
I can't find any resource that explains the order of evaluation of the ENV variable in Laravel... Usually in Spring Boot if I define a variable in the docker-compose I know for a fact that it overrides the application.properties value.. is the same in Laravel?
E.g.:
.env
DB_HOST = A
docker-compose.yml
environment:
- DB_HOST = B
in the application, is guarantee that DB_HOST is B?
At time of writing Laravel uses this dotenv environment. The key behaviour of this is determined by line:
static::$repository = $builder->immutable()->make();
Immutable, as described in the official dotenv repository, means that existing environment variables are not overwritten. Therefore the variables that docker-compose sets which are part of the container environment will not be overwritten by .env.
However since this is inferred by digging in the code and not explicitly documented (as far as I can tell), I think you need to treat it as undocumented behaviour and if you are relying on this then be vigilant before upgrading Laravel versions to make sure it has not changed.
Usually the variables that are defined in the .env are returned first. They are stored on config/ files as well. In your case it's stored on config/database.php file.
In my case env('DB_HOST', '127.0.0.1') it's this code.
What's it's saying basicly is that you get the value stored from the variable DB_HOST on .env, otherwise return the defaul value specified which is 127.0.0.1
Edit: As specified in the comments, you can always testing by using dd() or return env(DB_HOST); and you will get the result.
I have recently decided to try out Laravel Sail instead of my usual setup with Vagrant/Homestead. Everything seems to be beautifully and easily laid out but I cannot seem to find a workaround for changing domain names in the local environment.
I tried serving the application on say port 89 with the APP_PORT=89 sail up command which works fine using localhost:89 however it seems cumbersome to try and remember what port was which project before starting it up.
I am looking for a way to change the default port so that I don't have to specify what port to serve every time I want to sail up. Then I can use an alias like laravel.test for localhost:89 so I don't have to remember ports anymore I can just type the project names.
I tried changing the etc/hosts file but found out it doesn't actually help with different ports
I essentially am trying to access my project by simply typing 'laravel.test' on the browser for example.
Also open for any other suggestions to achieve this.
Thanks
**Update **
After all this search I actually decided to change my workflow to only have one app running at a time so now I am just using localhost and my CPU and RAM loves it, so if you are here moving from homestead to docker, ask yourself do you really need to run all these apps at the same time. If answer is yes research on, if not just use localhost, there is nothing wrong with it
To change the local name in Sail from the default 'laravel.test' and the port, add the following to your .env file:
APP_SERVICE="yourProject.local" APP_PORT=89
This will take effect when you build (or rebuild using sail build --no-cache) your Sail container.
And to be able to type in 'yourProject.local' in your web browser and have it load your web page, ensure you have your hosts file updated by adding
127.0.0.1 yourProject.localto your hosts file. This file is located:
Windows 10 – “C:\Windows\System32\drivers\etc\hosts”
Linux – “/etc/hosts”
Mac OS X – “/private/etc/hosts”
You'll need to close all browser instances and reopen after making chnages to the hosts file. With this, try entering the alias both with and without the port number to see which works. Since you already set the port via .env you may not need to include it in your alias.
If this doesn't work, change the .env APP_URL=http://yourProject.local:89
Ok another option, in /routes/web.php I assume you have a route set up that may either return a view or call a controller method. You could test to see if you can have this
‘return redirect('http://yourProject.local:89');’ This may involve a little playing around with the routes/controller, but this may be worth looking into.
I am new to symfony and am responsible for a site that I didn't build. For some reason the site is on a live server but running in dev mode. - Im not sure why??
That aside - The website keeps writing _sess files to my /tmp directory. The contents of each _sess file is exactly the same. See below:
_symfony2|a:3:{s:10:"attributes";a:0:{}s:7:"flashes";a:0:{}s:6:"locale";s:2:"en";}
Do I really need all of these files? Can anyone suggest a way of disabling this feature?
Thanks in advance
The default session storage of Symfony2 writes the session information to file(s). The location these files are written to is determined by the config parameter framework.session.save_path. The default value for this is %kernel.cache.dir%/sessions. This means that in a default installation of symfony the session files would be written to the cache directory for the environment.
However, this can be a problem as the cache directory has to be cleared each time an app is deployed, thus logging all the users out. Therefore presumably your app has been configured (most likely in config.yml) to store the session files in /tmp.
As I understand it, sessions that have expired should be garbage-collected at some point. Symfony also has some config params that affect this - see the FrameworkBundle Configuration. I don't know how much traffic your website has but obviously you do need the session files for active sessions. If you think you have a lot of expired sessions you could try tweaking the gc config params.
Alternatively, if having the session files in /tmp is specifically the problem you could relocate them (by changing the value of the framework.session.save_path) or use PDOSessionHandler to store sessions in the database.
I have this problem with symfony 1.4.20 on a web site I inherited.
It is writing files to
/var/lib/php/sessions
every second, until the server runs out of iNodes.
I've tried changing settings in settings.yml. app.yml and PHP session variables.
Nothing sees to be working though, the only way I can stop it is to change the ownership of /var/lib/php/sessions to root and that prevents any session files being created.
I've an application running on a dev server and connecting to a dev-db hosting an oracle instance.
Now i'm deploying the on a prod/prod-db machine
Since the dev-db url is hardcoded inside the java code, the just-copied binaries still points to dev-db. As a quick warkaround i added a line in Windows Host file on prod so that dev-db now points to prod-db IP address. It's work, but i'm not very satisfied of this global-scope solution.
I was wondering if exits a way to make a hosts file "private" for a certain environments ie. only valid in the scope of my running application
No, there's no way to do this, and it's a bad approach anyway.
You should instead fix the real problem, which is the hard-coding of the address inside your java code. Put such things in a properties file, and use a different properties file for production.