Blog Documentation Book a Demo
Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Style path includes the server WEB_ROOT within it

judgejjudgej ✭
edited December 2008 in Vanilla 1.0 Help
The WEB_ROOT setting points to the root directory that all other paths are set relative to. This works for nearly all URLs apart from the styles. The styles URL includes the web root within it, e.g. in the default settings file:

$Configuration['DEFAULT_STYLE'] = '/vanilla/themes/vanilla/styles/default/';
$Configuration['WEB_ROOT'] = '/vanilla/';

It makes more sense to set the style path relative to the WEB_ROOT, e.g.

$Configuration['DEFAULT_STYLE'] = 'themes/vanilla/styles/default/';
$Configuration['WEB_ROOT'] = '/vanilla/';

Now, I know there are other full paths in the settings file, so this is easy to change, but the big problem is where this same path appears in the database LUM_Style table. It means that if the web root needs to change for a site, then it is not sufficient to change just the settings paths. Unless you go into the database and manually configure the LUM_Style paths, then the styles will not work correctly. Again - I think the Url column in the LUM_Styles table should contain a virtual folder (it's not a URL, BTW) relative to WEB_ROOT.

Comments

  • WallPhoneWallPhone
    How about something like this instead?$Configuration['WEB_ROOT'] = '/vanilla/'; $Configuration['DEFAULT_STYLE'] = $Configuration['WEB_ROOT'] .'themes/vanilla/styles/default/';

    ...
    Actually, come to think of it, changing the way styles are handled might break the ability of users to specify their own style URL--one that could reside on a completely different server. Will have to test it out.
  • judgejjudgej ✭
    It was still the fact that is was hard-coded in the database too that was my main issue, which prevents the forums being moved location.

    The way I generally get around problems such as prefixes like this is to follow a simple set of rules:

    1. If the URL starts with a '/' then treat it as absolute on the current domain.
    2. If the URL starts with a protocol (e.g. http://) then treat it as absolute.
    3. If the URL starts with any thing else, e.g. '../' or 'vanilla/' then treat it as relative to the entry point (or other global 'base directory) of the current application.

    A helper function can take a look at the URL and prefix whatever it needs - the doman, the base path, or nothing.
This discussion has been closed.