Few moments ago I realised that symfony prints out all exceptions in my prod env. How can I turn this off?
After a little bit of looking, it seems this is how to (there is probably a better solution but I couldn't find it).
Under web/app.php, change $kernel = new AppKernel('prod', true); - the true here sets display_errors to true, so just change it to false.
If that fails, you should ensure that display_errors is turned off (if it's production, probably best done in php.ini itself rather than using ini_set).
Related
I know this subject has like ... many duplcates here and there, but trust me I've spent time fetching these posts and my question remains answerless.
I'm running a PHP script on a Debian Linux / Nginx / PHP-FPM / APC / I think that's all.
I'm executing the script from my SSH terminal (CLI) like : > php plzrunthisFscript.php &
It used to work flawlessly but now, it returns this famous error.
What I've tried ALREADY and it failed (I mean it didn't change anything) :
Check what PHP.INI was used with a phpinfo(); inside my script (it's /etc/php5/cli/php.ini)
maximum_execution time is hardcoded to 0 (means no limit) for CLI if I'm not mistaken.
Tried to add at begining of my script : set_time_limit(0);
Tried to add : ini_set('max_execution_time', -1);
Tried to execute my php command with parameter -d max_execution_time=0
Tried to execute from a web interface (served by Nginx)
Tried to execute from another web interface (SErver by Apache2 this time) gives same error on page.
tried to configure max_execution_time 15 in /etc/php5/cli/php.ini to check if the php.ini that is supposed to be used (because phpinfo() inside my script is ignored or not : it's ignored
Everytime, it brings this error, and sometimes even after more than 300 seconds I think, which is really confusing.
If someone has any idea on how to fix this, or has some things I can try, please advise.
Thank you for your time.
God I finaly solved it!
I think that could be considered as a Magento Bug in a way.
Here is how to reproduce this :
You have Magento (My version is CE 1.7) running with APACHE 2.
One day, you decide to get rid of Apache and try to adopt Nginx.
You configure everything and it's working great, but you end up with this error one day, trying to rebuild your indexes as you often do.
Thing is, when you run (for example) : php indexer.php --reindex catalog_url &
This script includes another one called abstract.php which contains this awesome function :
protected function _applyPhpVariables()
This function will look for a .htaccess in your Magento root directory, then parse every single configuration parameters, and will execute the index script with these parameters.
How clever ...
Anyway, to solve this you just need to (delete / rename / burn) this .htaccess file, and then everything will go back to normal.
Thanks for your help everyone.
I have been learning PHP on my own and I've used a web host account to test my scripts, where they have register_globals on by default. I know that this is not secure but I haven't bothered when just testing sample code.
Now I'm working on a small live site for a non-profit organization I'm a member of and the host they are using have register_globals off by default, as it should be.
So, now my question. I have been used to this working (with register_globals on):
Presume we are loading index.php?pID=1. The code of index.php will contain this row:
if($pID==1) include('content1.php');
Note that I've used $pID and not $_GET['pID'] and that I haven't assigned $_GET['pID'] to $pID anywhere in my code. This has worked fine anyway. So (of course) I'm wondering if it's because of register_globals being off that this is suddenly not working when I'm using the same code on my orgs host?
If so, is there a work-around to make superglobals magic again or do I have to live with manually assigning all $_GET variables to my own globals?
DO NOT attempt to implement register_globals, it is a massive security hole and never should have been implemented in the first place. Hence why it was deprecated in PHP 5.3 and removed in PHP 5.4.
You don't need to re-assign your variables, just replace them with the $_GET equivalents. I.E.
if($pID==1) include('content1.php');
should become
if($_GET['pID']==1) include('content1.php');
To demonstrate why register_globals was bad, take a look at this simplified example:
if(login_success('admin')) {
$admin = 1;
}
if($admin == 1) {
require('super-secret-admin-file.php');
}
Because $admin is never initialized anywhere, if register_globals was on and you opened file.php?admin=1 you would gain access to the admin section of the site regardless of if you are an admin or not.
I read #Dmitri 's original example of how to use fastcgi_finish_request() question and tried to follow the example in the answer in my Kohana 3.1 setup in index.php:
echo Request::factory()
->execute()
->send_headers()
->body();
Right after that, I added:
fastcgi_finish_request();
sleep(5);
Initially, I thought it worked. But then I realised in only worked for every other request. Example:
Navigate to localhost (works, no pause)
Click link to localhost/controller (pause 5 seconds)
Click another link to localhost/controller (works again, no pause)
And it continues on like that. Am I missing something? Like maybe a setting in php5-fpm config file?
Running PHP 5.3.5-1ubuntu7.2 with Suhosin-Patch, Nginx
Call session_write_close() before you call fastcgi_finish_request() to resolve this issue:
session_write_close();
fastcgi_finish_request();
sleep(5);
Next to the server-response itself (which you can control with the fastcgi_finish_request function and rest assured it works that way), there can be other resources that is blocking the (next) script from starting right ahead.
This can be file-lockings (popular for session) and other stuff. As you have not shared much code and we do not see your Kohana configuration you should take a look which components you use and which resources they acquire.
Is it because your web server only handles one php instance at a time and it is still exciting the previous script?
I'm using CC.net on against a Source Safe database, and have a problem that someone deleted some files from the database, and the deleted files weren't removed. I didn't see a config switch or anything that I could set for it to clear the code directory prior to building.
Am I missing something?
As Alex says there is a CleanCopy flag in the source code block. However, my situation was a little different. I use subversion and I found the CleanCopy flag was NOT doing what it said it would on the box.
To solve the problem I added a task which runs a batch file that clears out the build's working copy prior to checkout. It is a bit slower (about 1 min for code base of 400Mb) but guarantees no old code.
Kindness,
Dan
All you need to do is set CleanCopy to true in your source control block. The documentation is very clear on this. The above answer is the wrong way.
I building my sites on the localhost (runs wamp on windows), and when I upload it to my server, I always get
"Cannot modify header information - headers already sent"
I understand that there shouldn't be any blank lines and everyhing, and usually this works out. but now I need to redirect someone after the header has been sent, how can I make my server act like my localhost ?
i'm using cpanel and WHM:
cPanel 11.25.0-R42399 - WHM 11.25.0 - X 3.9
CENTOS 5.4 x86_64 virtuozzo on vps
I will appreciate any help
In short, you need to prevent PHP from outputting anything to the browser before you get to the point where you want to use the header() function.
This should be done by careful programming practices, of which your 'no blank lines' is one, or by storing PHP's output in an output buffer, and only outputting when you're ready for it.
See the ob_start() and ob_flush() methods. You use ob_start() at the start of your application. This disables output and stores it into a buffer. When you're ready to start outputting, use ob_flush() and PHP will send the buffer's contents to the browser, including the headers that are set till that point. If you don't call ob_flush() then the buffer is output (flushed) at the end of the script.
The reason why it works on your WAMP development environment is most likely that output buffering is already enable by default in the php.ini. Quite often these all-in-one packages enable a default buffer for the first 4k bytes or so. However, it is generally better to explicitly start and flush the buffer in your code, since that forces better coding practices.
Well,
I guess by more thinking and better programing you can manage to keep all redirects before any HTML is written.
This problem solved by the old rules...
#user31279: The quickest and dirtiest way I know of is to use # to suppress the warning, so e.g.
#header('Location: some-other-page.php');