Ini_Set() Scope of Effect

ini_set() scope of effect?

ini_set() is global for everything that happens in the script (not just the current file: the whole thread of execution that is occurring), for this entire one request; it doesn't matter whence you invoke it, it will always affect the global settings for this script. The effect will expire when your script terminates - e.g. through exit, die, or running off the end of index.php.

It will not affect any other scripts running simultaneously (those need to call ini_set themselves), and it will not persist into later requests (if you need persistent settings, you need to edit php.ini).

Note that the documentation says the same thing:

Sets the value of the given configuration option. The configuration option will keep this new value during the script's execution, and will be restored at the script's ending.

---

Edit: Since it is apparently unclear: the value you change using ini_set will be valid for the whole script onwards. It doesn't matter where the execution currently is (in what file, in what class, in what function); the setting will be the same, everywhere. It will remain so until you change it again, or until the whole script terminates. (not the current file, not the current function; the whole script)

how long do these php settings last, or are they permanent changes?

From the documentation:

Sets the value of the given configuration option. The configuration option will keep this new value during the script's execution, and will be restored at the script's ending.

They're only changed while your script is running, and within the context of your script.

What is the PSR-1 Compliant Alternative to Using ini_set()?

PSR-1 is just talking about the top-level code in the file. That top-level code should either be causing side effects or declaring things.

In your example, you're defining a class and its methods. The side effect doesn't happen when loading the file, it happens when you call the function. To be PSR-1 compliant, that call should not be in the top-level code of this file.

On using ini_set('max_execution_time', 0);

You can place it anywhere, but that setting won't take effect until it runs. So if you put it at the top, then the script will never timeout. If you put it down below on the function that can take awhile, then you may get a timeout above if the script takes a long time to get to where you called it.

When you use ini_set() that option stays in effect for the entire execution of the script.

Is it possible for a host to lock a php ini settings?

Short answer: possibly.

It could be that they've disabled use of ini_set via the disable_functions directive in the global php.ini, however that doesn't explain the behavior you're seeing; the documentation isn't clear, but I'd expect it to throw an error if you called a disabled function, nor does it explain why ini_get returns what you've previously set. It's also entirely possible they're running their own patched version of PHP that alters this behavior. Not unheard of, but unlikely.

Things to try:

• setting it with session_set_cookie_params instead (needs to be before session_start)
• double checking that you're setting the correct param (session.cookie_lifetime) and that your ini_set is definitely placed before session_start, or that you don't have another session_start somewhere else

Hiding deprecation warnings from a vendor-provided class only

You can attach a user error handler to eat the error up before PHP sees it. This handler would only intervene if the error was generated inside the source of the guilty library. For example:

class SingleSourceFileErrorSuppressor
{
    private $_file;

    public function __construct($file)
    {
        $this->_file = $file;
    }

    public function handleError($errno, $message, $file)
    {
        if ($file !== $this->file) return false;
    }
}

You would use the class like this:

$naughtyLibrary = realpath('naughty.class.php');
$suppressor = new SingleSourceFileErrorSuppressor($naughtyLibrary);
set_error_handler([$suppressor, 'handleError'], E_DEPRECATED);
require($naughtyLibrary);

Updated: I decided that modifying the vendor's library source is not the best idea even for trivial modifications because you have to remember to maintain them, so changed the suggested installation procedure. The new procedure has a different drawback: it doesn't automatically search the include_path. The original suggestion is available through the answer's edit history. Choose your poison.

open_basedir restriction in effect File is not within the allowed path

Check your configuration.php file. Ensure that the log and tmp entries look like

public $log_path = '/home/futbol/data/www/futbol.kg/logs';
public $tmp_path = '/home/futbol/data/www/futbol.kg/tmp';

If these entries are correct, and you still get that message, disable all non-core system plugins, as it then must be one of them causing the problem.

How to correctly use `.user.ini`-file in PHP?

In the documentation it says:

These files are processed only by the CGI/FastCGI SAPI

and

If you are using Apache, use .htaccess files for the same effect.

So if you run PHP as an Apache module, from the commandline, or using the builtin-Server, the .user.ini-files are not processed.

To find out your Server API, simply generate a PHP script with the following content and call it in your webbrowser:

<? phpinfo();

open_basedir restriction in effect. File(/) is not within the allowed path(s):

Modify the open_basedir settings in your hosting account and set them to none. Find the open_basedir setting given under 'PHP Settings' area of your Plesk/cPanel. Set it to 'none' from the dropdown given there.
I have shown them in the Plesk panel picture.

---

Related Topics