I have a weird issue with Symfony, in my local environment when I run symfony server:start it's taking production configuration not dev configuration.
I have two index files in the public folder index.php and index_dev.php. I also added a .env.local with APP_ENV=dev
Also, I tried to set environment variables as the following.
export SYMFONY_ENV=dev
But index.php is always loaded, and not index_dev.php as I expected.
How I can fix this?
It seems you are copying the app_dev.php pattern, which is how it used to be in olden times (up to Symfony 3).
Fortunately, that's no longer how things are done. Since Symfony 4, you should have a single front-controller.
All requests should go through the same entry script (index.php, generally), and there you can implement whatever logic you need taking into account the different environments.
The default index.php file already has some logic to account for the APP_DEBUG environment variable being set, you could always modify this file to add other behaviour depending on the environment.
Related
The Bolt documentation mentions setting up configuration files for each environment, but doesn't explain how to make it happen.
When you have multiple environments for the same site, like development, staging, or production, you’ll want parts of the config to be the same, and some different per environment. You’ll probably have different database info and debug settings. This can be accomplished by splitting the config.yml file. Put all settings you share over all environments in the default config.yml, you can commit this in your version control system if wanted. Every setting which is different per environment, or which you do not want in version control (like database info), you put in config_local.yml. First config.yml is loaded and then config_local.yml, so that config_local.yml can override any setting in config.yml.
Of course I have no problem creating an additional config file, but how do I tell Bolt which environment it's running in and which file it ought to load?
Turns out Bolt is completely unaware of its environment. It always loads config.yml followed by config_local.yml, regardless of domain name.
From Config.php, starting at line 226:
protected function parseGeneral()
{
// Read the config and merge it. (note: We use temp variables to prevent
// "Only variables should be passed by reference")
$tempconfig = $this->parseConfigYaml('config.yml');
$tempconfiglocal = $this->parseConfigYaml('config_local.yml');
$general = Arr::mergeRecursiveDistinct($tempconfig, $tempconfiglocal);
The solution to my problem is to never allow config_local.yml to get deployed.
The config_local.yml file is intended for development use so that you can override configuration setting that might be committed to your VCS in production use.
In my own cms system, I have a config file that is not registered in git (i.e. it is listed in .gitignore), but I will need to have that config file available on server.
What is the best practice to do this on Heroku environment?
You have several options that immediately come to mind; presented here in order of preference from strongest to lowest:
Use config vars. They will be available in $_ENV or via getenv(), and that's the most portable approach. If you add any add-on on Heroku, the corresponding information will be set as config vars so you can read from the environment at runtime. For instance, when you heroku addons:add heroku-postgresql, there will be a DATABASE_URL config var that looks roughly like this:
$ heroku config | grep DATABASE_URL
DATABASE_URL: postgres://user3123:passkja83kd8#ec2-117-21-174-214.compute-1.amazonaws.com:6212/db982398
You can then read this info from the environment and parse it as a URL to determine all the connection details:
$dbinfo = parse_url(getenv("DATABASE_URL"));
The same applies to any add-on. If you add a RedisToGo add-on from the add-ons store, you'll have a REDISTOGO_URL env var with the connection info. If you add a Mandrill add-on, you'll have a MANDRILL_APIKEY that you can use to interact with the API.
This is the recommended Twelve-Factor practice and has three very clear advantages:
if you want/need to change a config setting, you don't have to re-reploy your app
you can deploy the same code without changes to e.g. a production and a staging app (also see the heroku fork feature), not to mention local dev environments, as these only differ in their config vars
on occasion, the values of config vars may change. For instance, the Heroku Postgres HA feature may cause the value of DATABASE_URL to change. If you hard-code the value into your app, it'll go down when this happens and you have to re-deploy. If you dynamically at runtime read from getenv("DATABASE_URL"), you'll be safe.
Remember that you can set any config var yourself, e.g. heroku config:set FOO=bar and then $foo = getenv("FOO") or $foo = $_ENV["FOO"] (the former has the advantage of not throwing a notice if the variable/key doesn't exist, so you can do $foo = getenv("FOO")?:"default value").
Use something like IncenteevParameterHandler
Use the composer compile step to copy/move a config.php-dist to config.php (or similar) during git push heroku master
Do the same as above but using a Composer post-install-cmd; however, that will run every time someone does composer install, so it's probably not what you want.
Remove the config from .gitignore :)
P.S. Only option #1 reads config vars at runtime so you're automatically safe in the event the value of a config var changes.
I tried to setup a development environment where my server environment is emulated by virtual machine running centos 6.3 and development is done from host OS. The application code (codeigniter app) is in a shared folder mounted to /home/foo/Desktop/code/app and I have created a virtual host in apache to serve this application.
On the development side, git is used as the VCS .
The problem is that when loading a helper two files are being included. Eg, I have a helper in application/helper named my_date_helper. It has two functions. I autoload this helper.
When running this application php throws this error
Fatal error: Cannot redeclare time12to24() (previously declared in /home/mlakhara/code/cosys/application/helpers/my_date_helper.php:9) in /home/mlakhara/code/cosys/application/helpers/MY_date_helper.php on line 11
When I comment the function, it says the functions are undefined.
Also the time related functions throw a warning telling me to set a timezone which I have already in the php.ini file using date.timezone option.
I assumed that these two files can be same included twice with different names, but the line numbers suggest something else.. (function is declared at different lines).
The application functions correctly when served from normal folder (non shared). I removed git from the vn and tried but it did not make any difference.
What can be the problem ?
---------------EDIT -----------------------
Taking hints from Magnus Eriksson's answer, I found that I was autoloading these 'extended' helpers instead of loading the actual path and date helpers. This lead to getting two copies of the same function. However the problem with timezone setting still persists.
As a corrective measure I added the time value to my .htaccess file as well. However is there any better way to do it.
Try removing "my_" in the filename. CodeIgniter uses "MY_" to extend the core and might test with both lower and upper case and thus loading the same file twice.
Either way, as Rob W pointed out, always wrap your helper functions in if (!function_exists()) {}
About the timezone problem: Since I haven't seen your php.ini or your setup, I can't say why it isn't working.
One solution should be to add date_default_timezone_set('UTC'); (or what timezone you want) first thing in index.php.
Since I don't always have access to modify php.ini on clients production servers, I usually add that in.
You are defining the function twice. When including the files, try using require_once('path/to/file.php') instead of include or require. Otherwise, in the source file, you can do:
if(!function_exists("time12to24")) {
function time12to24() [...]
}
I'm trying to set up a FuelPHP app, and I've run into a puzzling problem. Every time the app tries to connect to the database, I get the following error:
Fuel\Core\Database_Exception [ Error ]: invalid data source name
I've set FUEL_ENV to "stage" in Apache's VirtalHost configuration and the database credentials in fuel/app/config/staging/db.php seem to be correct: I can log in to PhpMyAdmin using the same username and password. I'm stumped as to what else to try - any advice would be much appreciated.
In case it helps, I'm using FuelPHP 1.4 on an Amazon EC2 instance running Ubuntu 12.04 LTS on which I've installed MySQL and PHP via apt-get. I have another app (on another instance) running an older version of FuelPHP (1.2.1) which runs with no problems.
Incidentally, this question is probably closely related to this one, but I'm asking it as a separate question because the problem I'm having is not limited to the command line.
Ok, this has taken far too long to get to the bottom of, but it turns out to be simple to fix: for some reason, in FuelPHP 1.4 the stage environment's config directory is called staging (in previous versions it was stage).
I don't know whether this is a directory naming mistake, or whether this is a new name and something somewhere in FuelPHP hasn't been updated to use it, but I found changing the directory's name to 'stage' fixed the problem.
I had the same issue when running unit tests with FuelPHP's oil utility. If you're running into this issue, it most likely is a configuration issue.
To debug, somewhere in the code that isn't working put something like the following to see what environment FuelPHP is trying to use:
<?php
echo "env: " . Fuel::$env;
exit;
In my case, it showed it was trying to use the 'Test' environment. Since I didn't have a 'test' folder in my app's config folder, it was failing.
In most versions of FuelPHP, however you have the Fuel::$env set in your .htaccess file will work throughout all versions of FuelPHP. However in older versions, you may run into this issue.
You can either edit the bootstrap.php file and manually set the FuelPHP environment how you want, or setup the environment that it's trying to use.
Apache web server: SetEnv FUEL_ENV DEVELOPMENT Hope this helps someone
For those of you who none of this worked make sure of two things
there are multiple db.php files /fuel/app/config/development/db.php. check environment as #Chad Hutchins mentioned and double check the username and password is correct
Make sure /var/mysql/mysql.sock exists. In my case I was using /Applications/XAMPP/xamppfiles/var/mysql/mysql.sock so i needed to create a symlink. Followed the instructions here
Hope that helps someone
For a bit of history - this is the first time I attempted to setup a test symfony project, just to have a play with it.
The symfony project was setup in the following location:
~/symfony_projects/myproject/
Now, with cpanel, the httpd.conf is automatically generated (but I'm sure you knew that), and it uses ~/public_html/ as the web root and splits it up by domain name (virtual hosts) - so for this example, lets say it's ~/public_html/example.com/.
So the symfony project is all setup now, the next problem was trying to figure out how to setup the server so it points to the /web part of the project - this is where I found it tricky.
I tried doing the following:
ln -sf ~/public_html/libs/Symfony/data/web/sf ~/symfony_projects/myproject/web/sf
ln -sf ~/symfony_projects/myproject/web/* ~/public_html/example.com
That unfortunately didn't work though. When trying to go to http://www.example.com it just gave me a 500 error.
Any other options here? Taking into consideration that I cannot modify the httpd.conf. And even if I could, it's auto-generated and would rather not (in cpanel).
* Update *
I just tried what was suggested by #Dan, but with the same issue - getting HTTP Error 500 (Internal Server Error). So, it looks like something else is the issue.
I checked my error_logs but didn't see anything useful there. Is there any other way I can check to see what the problem is?
* Another Update *
Just tried http://example.com/frontend_dev.php and it works perfectly - gives no errors at all, which makes it kind of hard to debug the production controller.
So the Development controller works flawlessly and the production is spitting out the 500 error - any ideas? :/
I just copy everything out of web/ (including css/, js/, etc. subfolders) one level higher, then edit the index.php/yourapp_dev.php files' require statements to reflect the change in path. Add some rewrite rules to forbid direct access to the rest of the directories and you're all set on servers where you can't change the document root.
If you look at the http.conf virtual host entry for the symfony project the last line in generally a commented out include statement. If you uncomment that line you add any extra virtual host configs you need into that file. Then just restart apache. Anything in the file will then be appended in place of the include statement.