My code detects the environment from multiple factors and sets all environment variables and constants based on the autodetected environment.
I have the following line in my code:
ini_set('zend.assertions',environment_among(PRODUCTION) ? -1 : 1);
Don't worry about environment_among(PRODUCTION). The issue is that this line throws this warning: Warning: zend.assertions may be completely enabled or disabled only in php.ini
Since this setting depends on the environment as detected by the code, I can't put this setting in the server's php.ini file. How can I configure this locally? A solution that uses Composer is acceptable.
According to the documentation and the ticket that updated the documentation, your php.ini should be set to 0 in order to dynamically change this at runtime. There are third-party assert libraries but the performance-optimized assert can only be handled by the runtime since it is a compilation step.
Related
Can i disallow PHP override php.ini error_reporting settings? And take this settings only from php.ini.
php.init file have: error_reporting = E_ERROR|E_PARSE
PHP code have: error_reporting(E_WARNING|E_PARSE);
But this PHP line is in project core and i can't edit it and I don't need E_WARNING.
Can i disallow PHP override php.ini error_reporting settings?
You can disallow use of error_reporting() function in your code with use of disable_functions configuration directive. The downside is that you cannot have
disable_functions = error_reporting
set per vhost (i.e. via php_admin_value) but it must be set in main php.ini which may be problematic in some configurations.
Also I believe that your question exposed different problem and you are not fixing it here, but rather working around.
edit: just occured to me, you can use php runkit to do this instead of messing with the source code,
option 1:
install runkit ( https://github.com/zenovich/runkit / https://github.com/runkit7/runkit7 ), add runkit.internal_override=1 in php.ini, and run
runkit_function_rename("error_reporting","original_error_reporting");
runkit_function_add("error_reporting",function(int $ignored = NULL){return original_error_reporting();});
before running your intended code (you can also add this code in a file pointed to by the auto_prepend_file php.ini option to make sure it runs before any other code)
or option 2: edit the php interpreter source code,
in php-src/Zend/zend_builtin_functions.c find
/* {{{ proto int error_reporting([int new_error_level])
Return the current error_reporting level, and if an argument was passed - change to the new level */
ZEND_FUNCTION(error_reporting)
then right below that find
if (ZEND_NUM_ARGS() != 0) {
replace it with
if (0) {
then recompile PHP, and voila, error_reporting arguments are ignored :)
in git revision ab8094c666048b747481df0b9da94e08cadc4160 , which is 7.3.0-dev (slightly after 7.3.0-beta1), it is on line 736, see https://github.com/php/php-src/blob/ab8094c666048b747481df0b9da94e08cadc4160/Zend/zend_builtin_functions.c#L736
Regarding display_startup_errors the PHP manual says that even when display_errors is on, errors that occur during PHP's startup sequence are not displayed. So then what is meant by PHP's startup sequence? What does it involve, and what kind of errors can occur there? Some common examples could help.
The most common types of errors you'll see that would be suppressed by display_startup_errors are going to be related to PHP failing to load modules or modules emitting error messages for various reasons.
For example:
PHP Warning: PHP Startup: Unable to load dynamic library '/path/to/module.so' - /path/to/module.so: cannot open shared object file: No such file or directory in Unknown on line 0
This means PHP is configured to load module.so but it's not found so it cannot be loaded.
A module might also emit a warning due to bad ini configuration values:
PHP Warning: PHP Startup: session.name cannot be a numeric or empty '' in Unknown on line 0
This is one of several warnings the session extension emits, in this case because the configuration value for session.name is numeric or empty.
Most of PHP's startup sequence is going to revolve around configuring itself, loading in dynamic modules, calling each module's GINIT and PHP_MINIT_FUNCTION so they can initialize, then running PHP's startup sequence.
How and when these things happen vary depending on what server API PHP is running under. For Apache, this might be as an Apache module, FPM, CGI/FastCGI.
Some good references that talk about this are:
https://www.slideshare.net/laruence/the-php-life-cycle
http://www.phpinternalsbook.com/php7/extensions_design/php_lifecycle.html
https://wiki.php.net/internals/extensions#extensions_lifetime
I have a test suite that runs perfectly OK on my local env but on the server i get errors like:
Missing argument 1 for ngDateTime_Test::testSecondsSinceMidnightStr()
Looks like the providers don't inject values.
I use the same version of PHPUnit on local env and remote server. Does anyone have a clue why it might be happening?
As stated in doc: http://pl1.php.net/opcache
opcache.save_comments boolean
If disabled, all documentation comments will be discarded from the opcode cache to reduce the size of the optimised code. Disabling this configuration directive may break applications and frameworks that rely on comment parsing for annotations, including Doctrine, Zen Framework 2 and PHPUnit
Set opcache.save_comments = 0 , to fix this
or
set opcache.enable_cli = 0 , to fix this on command line interpreter, where you probably invoke
Hello I have simple php script well it is more a html file with few php lines.
Yet it produces tons of errors in log that look like this on every line:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20100525/suhosin.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20100525/suhosin.so: cannot open shared object file: No such file or directory in Unknown on line 0
I can not locate in nowhere in code where suhosin might been called...
This error is present on 2 different servers.
EDIT:
In phpinfo there is no suhosin present...
Thanks.
We will likely need more information in order to provide an accurate resolution, such as What version of PHP is installed on your system? however I will give you a general resolution.
Generally this issue is caused by PHP Upgrade, most recent PHP versions does not support suhosin as this only applied to older versions of php that needed additional security.
If you are on a shared hosting server you need to contact to your hosting provider and notify them about this issue, they are likely able to resolve it quickly.
If you are on a Dedicated server, VPS server or a localhost environment you can solve this issue by following the steps below:
Find your php.ini location [You can use phpinfo() to locate php.ini file]
Open the php.ini file and search suhosin.so
When you find suhosin comment this line extension = "suhosin.so" by adding semicolon at the beginning of the line, For example: ;extension = "suhosin.so"
Save this file
Restart Apache service httpd restart
Note: If ClouldLinux installed on your server, you need to force update CageFS by issuing the following command at the command line cagefsctl --force-update
ini_set('memory_limit', '128M'); // Returns false; memory_limit unchanged
I wasn't able to find a list of things that can cause this. So far I checked:
Safe mode: disabled
disable_functions: Empty
php_admin_value: None that I could find (is there a way to know for sure?)
I ran out of ideas! ini_set works correctly with other parameters (such as "display_errors")
If it's not the PHP version problem posted already try checking that there's nothing on the machine preventing your from raising this limit.
How to check whether Suhosin is installed?
edit (after establishing that Suhosin is installed):
Config details are here: http://www.hardened-php.net/suhosin/configuration.html
I suspect there'll be a file in /etc/php.d/ that you can edit to increase the memory limit bounds. The config variable you need to edit is: suhosin.memory_limit
The manual says :
Prior to PHP 5.2.1, in order to use
this directive it had to be enabled at
compile time by using
--enable-memory-limit in the configure line
That might be the cause of your problem.