0

I mass produce very similar sites, meaning they all use the same basic components, pages and are all single industry specific. These are my low end deeply discounted site designs. None of these sites ever get more than 20-30 visitors a day, so any extra load on the server isn't an issue.

In the interest of time, being that they all use the same components, though they may be in different locations or in a different order I would like to write one definition file that can be included with every site, so I can just call the defined constant instead of writing out the code a couple hundred times every year on every site I build. Also for editing later purposes this would make my life MUCH easier.

the definition file would look similar to the following:

define('UPCONTACT','<h1>Contact Us</h1>');
define('ULCONTACT','<a href="contact_us.php">Contact Us</a>');
define('UPABOUTUS','<h1>About Us</h1>');
define('ULABOUTUS','<a href="about_us.php">About Us</a>');

Obviously this is a very basic example but I think you get the idea.

So the question is what are the pros and cons of using define() in this manner?

user3154948
  • 137
  • 2
  • 11
  • 1
    I think instead of using constants, it is much easier to create templates. Plus you have to option to modify them down the line – Ibu Dec 21 '15 at 22:41
  • I am actually thinking of using this as part of my templating system. – user3154948 Dec 21 '15 at 22:44

4 Answers4

1

It's pretty much ok. The disadvantage is that, given you are using constants, you can't override them for a single page or site.

Use an array instead:

config.php

 return array(
     'aboutus' => '<h1>About Us</h1>',
     'contactus' => '<a href="contact_us.php">Contact Us</a>'
 );

include it like this in your site:

$config = include('config.php');

Then you can print it very easily

<?php echo $config['aboutus'] ?>

You can also change a value when you need it:

$config = include('config.php');
$config['aboutus'] = '<h1>About My Company</h1>';

This is probably your best option.

tacone
  • 11,371
  • 8
  • 43
  • 60
0

It has upsides and downsides.

The upsides involve that such way is quicker than loading settings from a database (and creating a database; and creating an abstraction layer, ...).

The downsides involve that such way is not customizable by the client. If they need a change, ensure beforehand the website is static and you will charge them by every change.

IMHO it is better to have some stuff as customizable by the client, and other stuff not. But there's no technical issue at all by using define() in that way (except perhaps allowed datatypes).

Luis Masuelli
  • 12,079
  • 10
  • 49
  • 87
  • These sites for the most part static, with the exception of the events page, which will have an "admin" area similar to WP Posts page. I suppose I could add another section to the admin for their personal info, location, contact information, email address etc. That would actually be pretty simple. – user3154948 Dec 21 '15 at 22:59
0

A better way to use a ini file or something like that. (and easily editable from a smartphone if it's a recursive task for you :)

Look for a builtin php function, can make simplify your life

http://php.net/manual/fr/function.parse-ini-file.php

or if you would a more stronger and flexible system, go for templating (looking for smarty, or self made regex templating)

Looking for my first regex function (loong years ago) Quitting Smarty to do it manually

Note:

Using Constant does not provide you to dynamically modifying them inline code, and are poor supported type (you cannot store an array without serialize for example)

Community
  • 1
  • 1
MTroy
  • 897
  • 9
  • 20
0

I would suggest cascaded ini files:

$conf_dir = dirname(__FILE__);
$config = array_merge_recursive(
    parse_ini_file($conf_dir.'base.ini'),
    parse_ini_file($conf_dir.'client.ini')
);

The benefits are readability, inability of execution (I like to lock things down that can be), and you can track the base ini in git (or whatever you use) and not the client one. There are some downsides, but such is life. The just feel cleaner, but they are not faster than .php, to be sure.

And if you wanted to eliminate any redundant execution (listen, any "performance benefit" still has "benefit" in it), serialization:

<?php

define('CACHE_DIR', '/tmp/');
// where 'http' is a path part that directly follows the app root, and will always
// be below where this file is called from.

$ini_cache  = CACHE_DIR.'config.ser';

if(!file_exists($ini_cache)) {
    // Build your config in any way you wish.
    $conf_dir = dirname(__FILE__);
    $config = array_merge_recursive(
        parse_ini_file($conf_dir.'base.ini'),
        parse_ini_file($conf_dir.'client.ini')
    );
    // Store it serialized
    file_put_contents($ini_cache, serialize($config));
} else {
    $config = deserialize(file_get_contents($ini_cache));
}

You can get more creative with this, but essentially, this allows you to store/generate your configuration in any way you wish. If you wanted to not have to delete the serialized cache on every change, you could add an atime check:

<?php

define('CACHE_DIR', '/tmp/');
// where 'http' is a path part that directly follows the app root, and will always
// be below where this file is called from.

$ini_cache  = CACHE_DIR.'config.ser';
$conf_dir = dirname(__FILE__);

$config = array();

if(file_exists($ini_cache)) {
    $client_stat = stat($conf_dir.'client.ini');
    $cache_stat = stat($ini_cache);

    if($client_stat['atime'] < $cache_stat['atime']) {
        $config = deserialize(file_get_contents($ini_cache));
    }
}

if(empty($config)) {
    // Build your config in any way you wish.
    $config = array_merge_recursive(
        parse_ini_file($conf_dir.'base.ini'),
        parse_ini_file($conf_dir.'client.ini')
    );
    // Store it serialized
    file_put_contents($ini_cache, serialize($config));
}

With either serialization method, you can use what ever $config generation scheme you prefer, and if you use PHP, you can even get real creative/complicated with it, and the cached hit to the page will be negligible.

Mike
  • 1,968
  • 18
  • 35