Doctrine is in production environment but symfony is in dev - php

I'm working on an apache server (not in localhost) with symfony 4
I have my WebProfilerBundle bundle enable only in dev environment
My DoctrineBundle is enable everywhere
When I update (php bin/console doctrine:schema:update) I always get a
[CAUTION] This operation should not be executed in a production environment!
Even if my APP_ENV=dev and even if I am can see my WebProfiler.
Someone know why ?

Unless you are just 'dumping' the SQL that would be run, or you are explicitly adding the '--force' parameter, it will always show the warning.

Related

Symfony 6.1 Tried to make live - having endless problems

I have a site which I've converted to Symfony 6.1 starting from a blank site and copying stuff over from the previous 3.4 site. In dev, everything works perfectly.
Today, I've tried to make it live. I deleted all previous content, cloned my repo and updated to latest version. I created a .env.prod.local file and set the APP_ENV variable to prod from dev.
Symfony is simply not detecting the change of environment. In my folder I have the .env file which is the default, I have not made any changes in that file. In my dev environment, I have .env.dev.local, I changed this to .env.prod.local in my production environment and updated the DB connection string and APP_ENV variable. The resulting errors showed that the env vars were not being picked up. After some research, I ran composer dump-env prod and that produced a .env.local.php file with the same vars as .env.prod.local. However, if I run bin/console debug:container --env-vars it says No environment variables are being used.. If I edit the .env.local.php file and change APP_ENV from 'prod' to 'dev', save and close, and run bin/console debug:container --env-vars again, then I see the vars I am expecting to see.
I cannot run my site in dev mode since it shows the development profiler and this cannot be visible. I cannot run the site in prod since it fails to pickup the vars from the .env.local.php file sometimes - some pages work while others throw a 500 internal server error. On the pages that throw a 500 error, if I change APP_ENV back to dev and load the page again, there is no error and no problems shown in the profiler. I have no information about what the error is in prod mode, I just see a generic error message and there are no logs or error messages on the server that I can find.
I'm running on Apache 2.4 and PHP 8.1.
Any help appreciated!!
After some random and desperate testing, I changed the APP_ENV var to 'live', and this allowed me to see the full error message (instead of a generic 500 internal server error message), and that message showed me that I was missing a /config/services_prod.yaml file. I created this file and cleared the cache, and no more error! Also, setting APP_ENV to live does not show the profiler bar, which was better than setting APP_ENV to dev in an actual production environment and having end users seeing the profiler bar...
All in all a massive PITA, setting this site live should have been an easy process and it's ended up costing me 4 hours just because of having no idea what Symfony is doing with environment variables (despite reading the docs like 5 times). I still don't understand why running bin/console debug:container --env-vars with APP_ENV as prod shows No environment variables are being used., while setting APP_ENV to dev or live and running bin/console debug:container --env-vars shows the expected vars. Seems to be a problem with Symfony?

Annoying warnings "Debug session was finished without being paused" in PhpStorm with Vagrant and Xdebug

I have properly running xdebug on vagrant on my local pc on Ubuntu. It shows its orange table with error info. My testing page is localhost:8030
In Chrome browser I have Xdebug helper.
The problem is that an annoying warning is displaying in PhpStorm each time I refresh the site:
Debug session was finished without being paused
It may be caused by
path mappings misconfiguration or not synchronized local and remote
projects.
To figure out the problem check path mappings
configuration for 'localhost' server at PHP | Servers or enable Break at
first line in PHP scripts option (from Run menu).
I have checked path mappings configuration for 'localhost' server at "PHP | Servers" and they are OK. My PhpStorm project directory is associated to default Vagrant directory /vagrant/web/.
Enabling Break at first line in PHP scripts option does help but it is kind of an opportunism I think.
How to get rid of these PhpStorm warnings?
For PhpStorm 2021.1.1 +
[Ctrl] + [Alt] + S
Settings : Php -> Debug
Scroll to Advanced settings and expand
Uncheck option Notify if debug session was finished without being paused
It would do this if there are no breakpoints being hit when debugging the script. The "break at first line" probably prevents PhpStorm from issuing you the warning, but otherwise it does exactly the same.
In case you do have breakpoints configured, and PhpStorm doesn't stop on them, then it is likely that you have path mappings configured wrongly.
Using Xdebug's xdebug.remote_log=/tmp/xdebug.log setting/feature to see which breakpoints PhpStorm tries to set, and see whether it does so for the correct paths. They will up as breakpoint_set commands in the log file.

Bare error 500 in Laravel - tried everything

In a Vagrant Homestead environment (in Windows via VMware) I get the bare error 500 with some errors (e.g., forgotten "use") but normal Laravel debug error page with others (e.g., failing to define a route properly or failing to pass a variable to a blade template).
I have tried every solution I've found here and in searching, specifically:
Reset permissions of storage dir (changed inside the VM and in Windows via git bash)
Reset permissions of bootstrap/cache dir (changed inside the VM and in Windows via git bash)
Cleared various cache directories
Checked Laravel log (nothing in it about the failed event at all - which seems very odd)
Checked nginx log (nothing in it about the failed event at all - which seems very odd)
Checked FPM log (nothing in it about the failed event at all)
Tried inserting my own exception code, per some people's posts, it never is executed/shown
Tried inserting old error_reporting(E_ALL); ini_set("display_errors", 1); include("file_with_errors.php"); in a few different places per other posts -- nothing.
Tried resetting the encryption key since someone said that might be an issue (why I don't know) -- nothing
Tried reverting back to a backup of a week ago to undo symphony/etc. upgrades -- nothing
Tried composer update -- nothing
Tried php artisan optimize -- nothing
My APP_DEBUG setting is right (and again working appropriately on many errors just not certain ones, like missing "use")
My project has ground to a halt because I can't debug even basic issues, and I'm out of ideas for what to try.
Any help greatly appreciated. I am stuck until I resolve this.

CakePHP 2.0.0-RC2 Console baking error

I originally thought this error had to do with my path setup - I had
separated the core from the app so I could work more easily with git
submodules, so I ignored it. I just did a fresh checkout from the git
repo / a download of the RC2 source / and a cakeinit install of the
2.0 package (also uses git) and all 3 installs have the same issue I
had before.
My code seems to work fine via the browser.
The output of a ./cake bake Model from inside the local copy of the
core in the lib/Cake/Console folder is here
https://gist.github.com/1233884
This totally prevents me from using bake. Baking a project doesn't
work, baking a new database config doesn't work - it also doesn't
matter which of the datasources I try.
Can someone point me in the right direction here? I want to use some
of the bake tools and work on converting some shells for 2.0.
I am using XAMPP (latest version for OS X - I reinstalled it 20
minutes ago as a last ditch attempt)
OSX 10.5.8
The database.php I am working with is here with the passwords removed
but otherwise working
https://gist.github.com/1233891
I have tested it with and without the unix_socket setting and encoding
settings. All works fine from the browser but again not via the cli.
Okay, the error message could have been be a little bit more specific:
Error: Database connection "Mysql" is missing, or could not be created.
DboSource::__construct() is throwing that error here because Mysql::enabled() returns false:
public function enabled() {
return in_array('mysql', PDO::getAvailableDrivers());
}
On Windows, I can reproduce your error by commenting out the following line from my PHP CLI's php.ini file (the one that running php --ini on the command-line returns):
extension=php_pdo_mysql_libmysql.dll
HTH.
I was MAMP on Mac and had the same problem with CakePHP 2.2. I solved the problem by installing the mysql pdo for my mac ports installation. sudo port install php5-mysql
For local testing, I have found that setting the host to the address works. In my config I use the following:
'host' => '127.0.0.1',
This works for Mamp Pro

oci_connect Blank Page in PHP

UPDATE (5/21/2010) SUCCESS!
So after MUCH $head->desk()'ing, I've solved it.
Remember kids, be wary of the instant client version you use, dependent on the virtualization settings!
I had been installing the generic Instant Client (not aware our ESX servers sit on AMD processors, not Intel) and that worked fine internally (the CentOS install was 32-bit since our internal ESXi servers aren't 64-bit). Well lo-and-behold, even if you have a 32-bit install running on a virtualized server which is sitting on an AMD64, it still matters what instant client you install.
It was the last thing I thought to check but as it appears, everything is running fine now.
I would like to thank everyone who helped me run through every possible test to figure this out but in the end, it was my fault for not realizing the differences in the virtualizations.
UPDATE (5/21/2010)
I thought this bug had escaped me when I installed it on a new VM internally but I have now found a narrowing link.
I was trying to install this on our production server when I posted this. After a week of no progress and in need to get back to development, I outfitted a VM on our internal server with a brand new install of Crap... CentOS, and fresh installs of instant client and oci8.
Worked perfectly.
However we just uploaded an exact copy of the VM to our production servers and it magically no longer works. Tried reinstalling everything, no avail.
So the only things I could narrow it down to is a firewall issue (although I get the same issue when trying 127.0.0.1) or possibly an ESX (our production servers) server issue, internal servers are running ESXi.
Any thoughts?
UPDATE (3/8/2010) I installed Xdebug and have it tracing my code. This is the output I am getting:
TRACE START [2010-03-08 17:53:05]
0.2090 327864 -> {main}() /data/aims3/http/octest.php:0
0.2091 327988 -> ini_set(string(14), string(1)) /data/aims3/http/octest.php:3
0.2093 327920 -> error_reporting(long) /data/aims3/http/octest.php:4
0.2094 328048 -> oci_connect(string(8), string(8), string(25)) /data/aims3/http/octest.php:6
The trace halts at that point.
I have installed everything the same way on a local server and it works fine. To say I am at a complete loss would be putting it lightly.
*NOTE: I ran make test and it returned FAIL on every test. I never ran this on my working machine to see if it reports the same errors. Any idea why make test would report FAIL but make doesn't report any error?
I've installed the Oracle Instantclient with no reported errors along with the OCI8 PECL package and at a loss. Whenever I try to open a connection with oci_connect, it halts my entire PHP script.
EXAMPLE:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
$conn = oci_connect("username", "password", "host");
echo "after";
?>
Returns a complete blank page. The module is loaded (seen in phpinfo) and everything installed with no errors.
I am at a complete loss.
CentOS: 5.4
Apache: 2.2.3
PHP: 5.3.1
InstantClient: 11.2
oci8: 1.4.1
Any thoughts?
NOTES
Apache Error Log reports nothing
Attempted Debugging:
1:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
echo "after";
?>
Returns:
beforeafter
2:
Changing host to //host
Returns:
Same error
Is there anything in Apache's error_log? Is this mod_php or FastCGI or normal CGI PHP? What happens if you run the script via the command line?
You could also try setting PHP's error log and looking in there.
EDIT1: Try:
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
And post the results...
EDIT2: I'm really not sure. My best bet is this info from the PHP manual:
The most common problem with
installing OCI8 is not having the
Oracle environment correctly set. This
typically appears as a problem using
oci_connect() or oci_pconnect(). The
error may be a PHP error such as Call
to undefined function oci_connect(),
an Oracle error such as ORA-12705, or
even an Apache crash. Check the Apache
log files for startup errors and see
the sections above to resolve this
problem.
Anyone else have any ideas to help out Bryan?
Bryan,
I am going to be honest: I tried this two years ago and failed miserably. :) I could not get the OCI functions to work for anything by compiling myself.
But in the interest of getting it done I looked for an alternate solution and found it in Zend Core for Oracle. All I did was download, run the installer, and it was done. It installs Apache/PHP, MySQL (optional), and the InstantClient for you.
Now as Zend Server, it is basically the same product. I realize that this may not be the solution you hoped for, but if it works...
Zend Server
are you connecting to remote or to local db? i think, for localhost you must replace "host" with "false". I hope, this will help you...
edit: i think, you are missing a parameter...my last suggestions are: 1. you must set the port (default 1521) AND/OR 2. You must enter db name AND/OR you must set the instance name (the ORACLE_SID parameter)
You never check the return value of oci_connect() or call oci_error() but it doesn't look relevant to your problem since you seem to be suffering from a PHP crash. There's an open bug for RHEL that may affect you too:
http://pecl.php.net/bugs/bug.php?id=16626
Did you build the oci8 package yourself? Are you using a third-party binary?
It has been fixed. See the top for details but here is the cliff notes: virtualiztion environments matter.

Categories