constants and Config::save

I was just wondering - does the config method not update constants by design, or is it broken?

For example, I have a bootstrapping package that I want to change EMAIL_DEFAULT_FROM_ADDRESS

I'm doing the following;
$co = new Config();
$co->save('EMAIL_DEFAULT_FROM_ADDRESS', '[email protected]');

But this never seems to work, whereas some constants DO work;


I can set those ones in my package.


View Replies:
JohntheFish replied on at Permalink Reply
A couple of thoughts, not answres.

- Is it also set as a define in config/site.php ?

- I don't know what the rules of ownership are. If a config value is set from a package, does that take precedence over one set by the core? Do you want to take over ownership? So maybe try setting without a package.
Config::save($key, $value);

There is also a less verbose way to set from a package:

A final thought, if you save a config value through the api, that value may not read back correctly until the next request (somewhere behind the scenes there is some write caching going on). If you need to read it back immediately, you may need to write to the table using SQL.
moth replied on at Permalink Reply
These aren't defined in config/site.php

The point (well for me) is to have a package that just sets that automatically so I don't have to have developers editing site.php.

And yes - I have tried setting the config item without the package reference and it still doesn't work.

I'm wondering if some of this might be security related? You could do a lot of damage by high-jacking a few site-wide constants from a package.
JohntheFish replied on at Permalink Reply
Just did a quick global search on EMAIL_DEFAULT_FROM_ADDRESS and also had a look at Config using phpMyAdmin.

EMAIL_DEFAULT_FROM_ADDRESS is not a key in the config table. It is only available as a site defined constant. So any setting you make in Config will be there, but will have no effect because the core only looks for a defined constant, not in the Config table.

If you don't want to edit config/site.php, you could try a 'define' in an on_start() event handler in your package.
public function on_start(){
  if(!defined('EMAIL_DEFAULT_FROM_ADDRESS ')){

Whether that works depends on whether the core runs on_start() handlers before setting up the base definitions.

The only other package approach I can think of is for your package install to actually edit config/site.php. That could have file permissions implications and hence security implications.

You could also look at 'starting points' as an alternative to a package.
moth replied on at Permalink Reply
I guess that's the same issue for the other ones that don't work.

I wonder if there's plans to unify them?

Thanks anyway (I did already try on_start() - no joy!).
JohntheFish replied on at Permalink Reply
Another experiment - add some code to config/site to look in the Config table for such settings and make the definitions.

That way, at least you are running the same config/site code for all sites.

You may need to read the database the hard way because there may not be enough of c5's infrastructure established to use the full api at that stage. Its not something I have ever tried.

There was also a howto about making config/site pull in different versions of config/site for different urls. You could use a similar technique to insert your own file of config code. That way again you would have one stanbard config site and your package would write the file it pulled in.