I'm aiming for the best and simplest way to access "global" variables set in the config file for my website. So I can use them anywhere, even inside functions

It's for file versioning, and I use htaccess to rewrite urls (trim out version part)

Right now, I'm at this:

// config.php:

class VERS {

  static $css = '_214';
  static $js = '_167';
  static $image = '_56';
  static $other = '_19';


// subpage.php:

require 'settings/config.php';
echo '<link type="text/css" rel="stylesheet" href="style'.VERS::$css.'.css" />';

Is this an ok solution? Are there downsides and/or better ways?

I want to avoid setting multiple DEFINE's, and I aim for a short version var call (like VERS::$css)

EDIT: This is not about alternatives to the filename method itself (like filename?queries etc.)

  • \$\begingroup\$ Why use a class, if you can simply define constants? define('CSS', '_214'); makes CSS available globally... \$\endgroup\$ – Elias Van Ootegem Aug 27 '14 at 11:41
  • \$\begingroup\$ @EliasVanOotegem I could. But I'm already using quite many constants (config). Just wanted to avoid setting more. Tell my why not to use a class? ;) \$\endgroup\$ – mowgli Aug 27 '14 at 11:44
  • \$\begingroup\$ If you really have that many constants, chances are your entire config is hard-coded into your project. That's bad practice: use a class to parse config files (ini, xml, yml, json... whatever data format you like). That's how all of the bigger PHP projects work, if only because that means you're keeping the config all in one place, and can port your code to any environment you like... tweaking it through the config files \$\endgroup\$ – Elias Van Ootegem Aug 27 '14 at 12:00
  • \$\begingroup\$ All my constants are in the included config file only, and the site/code/settings can be ported anywhere, with minimal changes. Not THAT many constants, but 20-30. And many of them are dynamically set, according to the server/db/user environment \$\endgroup\$ – mowgli Aug 27 '14 at 12:13
  • \$\begingroup\$ The number of config params tends to grow, as does the number of environments on which code needs to run. Take a look at all of the major projects out there: they all use separate config files, for good reason. \$\endgroup\$ – Elias Van Ootegem Aug 27 '14 at 12:26

If these are constants, use const, not static:

class VERS {
    const css = '_214';
    const js = '_167';
    const image = '_56';
    const other = '_19';

and then

echo .....VERS::css....

As to whether this is a good idea in general, it would be helpful to show a bigger picture: what the rest of config looks like? how it's used? etc.

| improve this answer | |
  • \$\begingroup\$ Why use const instead of static? The config file is just settings used on the website.. like these version vars, database setup etc. Nothing complex \$\endgroup\$ – mowgli Aug 27 '14 at 10:24

It seems that your goal is to change the URL for any referenced resource whenever it is updated, so that the browser will know when the previously cached version is no longer in use. However, you mentioned that you would then need htaccess rules to strip off the cache-busting version number.

A simpler cache-busting strategy would be to append the cache-busting version number as a query string instead. If the browser fetches the URL style.css?version=214, and a static file named style.css exists, then the webserver should map that URL to the static file. The query string would automatically be ignored by the server.

| improve this answer | |
  • \$\begingroup\$ This is what I'm doing now, but want to upgrade from. The query solution is far from always reliable. Certain browsers and proxies can ignore queries, and/or it messes with the set caching. I appreciate your intension/effort, but this does not answer my question \$\endgroup\$ – mowgli Aug 27 '14 at 10:40
  • \$\begingroup\$ Instead of a query string, appending a path info might also work. That is, fetch style.css/214. The web server should map it to style.css, while user agents and proxies would have a hard time assuming that such URLs refer to different versions of the "same" resource. \$\endgroup\$ – user50399 Aug 27 '14 at 11:04
  • \$\begingroup\$ Please read my question again. This is not about queries or similar \$\endgroup\$ – mowgli Aug 27 '14 at 11:07
  • \$\begingroup\$ The point of appending something to the URL is cache-busting, is it not? I'm pointing out that a smarter URL versioning scheme would relieve you of the need to write htaccess remapping rules. \$\endgroup\$ – user50399 Aug 27 '14 at 11:24
  • \$\begingroup\$ I like the solid proven method of having/changing the version in the filename itself. htaccess rewrite for this is simple, fast and pretty smart (one short rule, and I already use modrewrite). No need for an alternative. But thanks \$\endgroup\$ – mowgli Aug 27 '14 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.