Custom variables in PHP.ini file

How to set custom variables and in php.ini file and I want to use those variables using ini_get function.
I don’t want to use ini_set function and this variable should not be removed using ini_restore function.

Why would you want to do this?

I would like to put some application configurations such as database host name, user name and password in that file.

That’s an interesting idea (if you’re on a dedicated server anyhow)

Am I right in saying that if that was possible you’d be able to do it from a .htaccess file for a domain too?

It’s already there. Have a look under the MySQL section, for instance. You can set default host, user and password there. Maybe even database name, I don’t remember.

Ahh, yes I remember now.

But what about other, domain or even server specific globals?

Haha, well… Someone’s gonna have to try and let us know if it works. :smiley:

The syntax for configurations in the ini file is

variable_name = "value"

Never tried custom variables. :smiley:

So why is the mysql password variable syntax so:

mysql.default_user = “”

Like there is a mysql. namespace?

MySQL is an extension for PHP, and so for organizational reasons, its related configuration uses a namespace.

Also, from what I recall, there is “doc_root”. My guess is that, since the results are retrieved from a string, anyway, it allows most characters.

This seems a nuts idea, but works.

You could take a little used ini option, and stick a string in there with some settings and explode them out later, say you run with safe mode off …


; When safe_mode is on, UID/GID checks are bypassed when
; including files from this directory and its subdirectories.
; (directory must also be in include_path or full path must
; be used when including)
safe_mode_include_dir = "/rse/a/my/"



$settings = explode("/", ini_get("safe_mode_include_dir") );

echo 'kiss '  . $settings[3] 
		. ' ' . $settings[2] 
                . $settings[1] ;

There are probably better ways to do this, maybe with a query string which you could parse out into args.

I can’t remember why I am doing this, would it be faster than loading a global include file, no? - this info is available to every script on your server.

Haha, well, I don’t think this idea is actually useful… Just kind of funny, in a “let’s see if Kelso can eat a scorpion and stay alive” way.

You could take a little used ini option, and stick a string in there with some settings and explode them out later
Using the same theory, could you not just placed a serialized array in the INI?

$settings = unserialize( ini_get("safe_mode_include_dir") );

I could see why this could be an easy way to store data which would be available to any script, however, … in fact…is there a ‘however’ ? :confused:

I must need lunch.


Could be. But you’d have to make sure that it could accept special characters… Can anyone confirm that?

Why stop at arrays… Haha, hell, instead of those damn mysql configurations - why not have a set object. :smiley:

I’m not doing it, I did the last one.

I have a nagging doubt that this is just wrong. If the PHP gods thought that it was a good idea to let us put our own settings in the ini file, they would have done so and documented it for us.

They didn’t and there must be downright good dog’awn reason reason for that.

I mean the whole of the ini file must be loaded in memory, and stays there, behaving a bit like a memcache, apc or what have you. (apc strips out all the comments, I have heard)

You could use SetEnv in .htaccess of httpd.conf and then they will be available in $_SERVER and $_ENV as well as getenv()

This of course makes these available as environment variables, which are accessible by more than just php…

There is also the auto_prepend_file php option.

You could use SetEnv in .htaccess of httpd.conf and then they will be available in $_SERVER and $_ENV as well as getenv()

That sounds a better idea at first glimpse.

I have a dedicated server running just a CMS.

Each client using the CMS uses a shared code base for their admin, and most of the vanilla websites are driven by client specific variables used on nav bars, page titles etc and those vars are squirted into what are mainly rudimentary templates.

Apart from custom work any client can opt to have done, these vars just about make their site for them.

Would about 100 different variables going into a .htaccess file in the parent directory of their website cause a problem do you think?

And to save me testing it, if you know this it would save me some messing ( Dev machine is IIS, see?) can an environment var be non-scalar, e.g a PHP array?

Thanks for chipping in on this.

Try it and see, I guess.

Enviornment variables can only be strings.

I’m really not sure what kind of overhead it would add, but I think it would be fairly easy to test if you used apachebench to test requests per second for a ‘hello world’ php script. This will add overhead to static file requests as well, as I’m sure each apache worker thread would need to copy these variables in as well. I would imagine very little overhead, but I don’t know.

That’s why we were talking about serialization.