Closed. This question is not written in English. It is not currently accepting answers.
Stack Overflow is an English-only site. The author must be able to communicate in English to understand and engage with any comments and/or answers their question receives. Don't translate this post for the author; machine translations can be inaccurate, and even human translations can alter the intended meaning of the post.
Closed 5 days ago.
This post was edited and submitted for review 5 days ago.
Improve this question
I already added in the PHP page:
ini_set('display_errors',1);
ini_set('display_startup_erros',1);
error_reporting(E_ALL);
I changed in /etc/php.ini
display_errors = on
And it still doesn't work.
PHP 8.1.15 (cli) (built: Jan 31 2023 15:13:17) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.1.15, Copyright (c) Zend Technologies
Solution alternative
In ".htaccess" add these 2 lines
php_flag display_startup_errors on
php_flag display_errors on
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
Hello I am confuse I have two server one is running PHP 5.6.10 (cli) (buit: jun 11) 2015) , Zend engine V2.6.0 and the other one is running PHP 5.5.38 (cli) (buit: jan 11 2019) Zend engine V2.5.0. , the first one my Vulnerability scanner (Nessus enterprise) said that the version is fine but the second one the Vulnerability scanner (Nessus enterprise) said that is unsupported , could please explain me why does is happening , because I see the first server less version that the second server. Also I check that both web server are running and responding to the scan.
I am not sure what scanner you are using, but the PHP versions on both of your servers are no longer supported since 2017. It would be prudent to upgrade the PHP version on both of your servers to at least PHP 7.3
Using old versions is insecure and could lead to hacks and data breaches. You can see the current supported PHP versions here - https://www.php.net/supported-versions.php
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I want to profile some part of my application to make improvements. The recommended way to do this seems to be to enable xdebug in php.ini but this makes it write profiler stuff on every request which is slow and generates a lot of files.
Constantly enabling and disabling would be annoying though.
What I want is to have something I can run from the command line that will run specific requests to particular URLs and write a profiler report to a specific folder when run but not profile the rest of the time.
Make sure that your php.ini contains:
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1
Now you can profile a single web page using cURL:
curl -I http://my-website.local/?XDEBUG_PROFILE
Note the XDEBUG_PROFILE query parameter: this is what enables Xdebug's profiler (see the documentation: https://xdebug.org/docs/profiler).
cURL will show us:
HTTP/1.1 200 OK
Date: Tue, 10 Mar 2020 08:45:50 GMT
Server: Apache/2.4.29 (Ubuntu)
X-Powered-By: PHP/7.4.2
X-Xdebug-Profile-Filename: /tmp/cachegrind.out.6173
Content-Type: text/html; charset=UTF-8
The profiler added a X-Xdebug-Profile-Filename header for us that contains the cachegrind file, which we can then open in a program such as KCachegrind.
If that header is not present, you're either using a version of Xdebug < 2.6, or the Xdebug profiler is not configured correctly.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I use plugin https://wordpress.org/plugins/facebook-auto-publish/ for Wordpress, but I got error Uncaught Error: Call to undefined function mb_strripos().
To check I've created single php file:
<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);
echo mb_strripos("qwert", "w");
?>
And I got the same error. In php docs I didn't find what was wrong.
Output of php -v:
PHP 7.0.33-0ubuntu0.16.04.5 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.33-0ubuntu0.16.04.5, Copyright (c) 1999-2017, by
Zend Technologies
Where is I'm mistaken? Thank you
You're using a plugin that's attempting to call a multibyte string function, mb_strripos(). The plugin isn't checking if those functions are available first however.
mbstring isn't a default extension in PHP. If you want to use those functions, you must install the extension first. Details on how to do that can be found in the documentation: https://www.php.net/manual/en/mbstring.installation.php
The approach you take to installation is going to depend on your hosting environment. It may be that you can install the extension yourself; it may be that you have to contact the hosting provider instead. Without knowing your particular setup, I can't make a suggestion.
The plugin really ought to be checking for mbstring support and showing a user friendly error message if it's not available rather than allowing it to trigger an error.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have the following setting at my php.ini located at D:\wamp\bin\apache\Apache2.4.4\bin:
error_reporting = E_ALL
I now have changed it to
error_reporting = E_ALL | E_STRICT
Then I restarted all services of Wamp.
It doesn't still show the the notices that the production server show.
At both states, in phpinfo() I can see error_reporting set to 32767.
I think there was a little bug that escaped in WampServer2.4 and that was that the php.ini file had the error_log parameter commented out.
So edit php.ini ( using the wampmanager -> PHP -> php.ini )
Look for
;error_log = "c:/wamp/logs/php_error.log"
and change it to
error_log = "c:/wamp/logs/php_error.log"
Assuming you are installed on the C: drive
Also check
log_errors = On
just to be sure.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Improve this question
Currently my production servers have PHP 5.5.1 installed and working fine.
PHP 5.5.1 (cli) (built: Jan 14 2014 11:37:09)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
However according to this post PHP has released 5.5.12 to fix some OpenSSL issues. We are running on CodeIgniter.
As I see there is no breaking change between 5.5.1 and 5.5.12, only bug fixes and few additions. So it should be fine to upgrade PHP version smoothly.
However recently we also upgraded to newer version of OpenSSL avoid heartbleed bug. So now is it necessary to upgrade the PHP for same reasons?
If I am not missing anything then upgrade won't cause any version related issue?
NOTE: As the post mentions the example of shared hosting/servers, we have our own multiple dedicated servers running behind load balancers.
PHP releases avoid any type of syntax-breaking changes at the minor-version-release level, so as long as you're still PHP 5.5 your code will almost certainly still be valid. Since you have multiple servers, you could try upgrading one of them, completing your test suite/unit test/basic sanity tests/etc. first before rolling out the upgrade to all your servers.
You could spend a lot of time poring through the diffs on the commits referenced in that post, but ultimately you may find a move from 5.5.1 to 5.5.12 is fairly safe and may yield other improvements too, so I'd focus your energy on testing.