0

First of all, I am assuming this is NOT bad practice due to various popular software using this method, such as SMF.

Anyway, so I currently have this code:

<?php
// main visual config
$cfg['lang']    = 'en';

// paths
$path['admin']  = 'index.php?p=admin';
$path['admin2'] = 'zvfpcms/admin';
$path['root']   = 'zvfpcms';
$path['images'] = 'zvfpcms/img';
$path['css']    = 'zvfpcms/css';
$path['js']     = 'zvfpcms/js';
$path['pages']  = 'zvfpcms/pg';
?>

The thing is, I want the $cfg variable(s) to be edited directly via an interface.

How would this be achieved? I cannot think replacing strings would be a good idea especially when there are a very large number of possibilities (or even infinite) for future $cfg variables I create.

Or, will I have to settle for a different method...

Answers appreciated!

unrelativity
  • 3,670
  • 6
  • 38
  • 63

5 Answers5

1

Pear Config will let you read and write configuration easily to/from different sources, including a PHP file/array. You would probably need to move $cfg into its own file though and include it so that other variables etc. are unaffected.

You could also do it yourself using var_export() and then writing over the file, again you would probably need to move the variable into its own file. I think that this would write messier/less readable PHP than the Pear class.

Tom Haigh
  • 57,217
  • 21
  • 114
  • 142
0

Just have all the settings in your database, and when a setting changes, rebuild the config file.

  • The software is flat-file, but I'll still respond. Take a hypothetical user, "Bob". Bob renames the zvfpcms folder. How would this be dealt with? – unrelativity May 07 '09 at 07:04
  • If it's flat file, use Spencer's idea of using XML files. If the script determines it is running in a different directory than what the XML file stipulates, the PHP config file should be rebuilt. –  May 07 '09 at 07:35
0

Don't have your PHP edit PHP code. Use an XML config file instead. Read the XML info out, if you want to make a change, change the value in the data structure generated from the XML file and spit it back out into a new config file.

Spencer Ruport
  • 34,865
  • 12
  • 85
  • 147
  • Similar to mine, except you're using XML files. Either way is the best approach IMO. –  May 07 '09 at 07:04
  • I think employing both approaches, depending on the particular setting, is the best way. Sometimes it's far simpler to just go straight to a file rather than digging around a db trying to remember which table stores config settings. – Spencer Ruport May 07 '09 at 07:07
  • Would this have any speed impacts considering the configuration's data is used on almost every page? – unrelativity May 07 '09 at 07:10
  • Using a flat-file would be less efficient than a database. If you can't use a database, then flat-file is obviously your only practical option. –  May 07 '09 at 07:37
  • The difference would be negligible. ASP.Net uses flat files for many application wide settings. – Spencer Ruport May 07 '09 at 08:08
0

Either store the settings in a database, or you could use a standard ini-file (key=value pairs);

lang=en
timezone=CET

Read them:

function loadSettings() {
    $cfg = array();
    foreach (file('settings.ini') as $line) {
        list ($key, $value) = explode('=', $line);
        $cfg[$key] = $value;
    }
    return $cfg;
}

File I/O are less efficiant than standard database calls thou, especially if you already have an open connection to a database.

Björn
  • 29,019
  • 9
  • 65
  • 81
0

The reason I believe that this IS bad practice is because you can have a running system before the edit, have some error in the edit (perhaps you didn't escape a single-quote character) and after the edit the entire application becomes unavailable because PHP can't parse the config file, which affects almost everything you do.

The XML suggestion isn't a bad one as you can handle any errors that occur while you're reading the XML.

If you had a database (reading this post it looks like you aren't using one, which is fine), that would be the best place for the data - that's what it's for. In a flat-file world, reading in a non-PHP file and interpreting it is far better than auto-editing the PHP files yourself.

Fenton
  • 241,084
  • 71
  • 387
  • 401