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->setPackageObject($pkg); $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.
- 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.
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.
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.
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.
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.
I wonder if there's plans to unify them?
Thanks anyway (I did already try on_start() - no joy!).
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.