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.
Options

"http://domain.com/subdirectory" vs "http://subdomain.domain.com"

edited May 2007 in Vanilla 1.0 Help
This is kinda weird.... Set up vanilla, and all is well, when using the URL scheme: "http://domain.com/subdirectory" When I use the URL scheme: "http://subdomain.domain.com" I get an HTML-only version of the vannila system. Everything is there, but the frames are not there, so things are a bit screwed up. The "panel" information is at the top, and the rest of the "index.php" page contents are below. Everything appears as "static html". The subdomain points to the same directory in the webserver, of course. Hosted on GoDaddy - do they perhaps have an issue with their linux/apache/php ?
«1

Comments

  • Options
    theres a path in the mysql database table which you need to change. I cant remember what one it is but i'll take a look shortly.
  • Options
    edited May 2007
    I'm also hosted with GoDaddy and had the same issue.

    I had installed using the /subdirectory structure. Later I decided to switch to the subdomain.domain.com structure. All frames gone.

    The quickest solution for me was to do a clean install (e.g. 1. deleting/re-adding the MySQL dB 2. removing/re-installing Vanilla). The forum wasn't live so I didn't have to worry about losing data otherwise I would have backed up the dB first.

    Everything was fine after that.

    Re: vaz comment, I'm sure there's a more elegant solution, I just didn't want to spend more time on it.

    Lars
  • Options
    The path settings are in conf/settings.php. It will be fairly obvious what needs to be changed when you look in that file.
  • Options
    I think the issue here is the theme paths which are stored in the database. The easiest way to sort it is to go to the theme settings page and re-apply the correct theme to all users, I believe.
  • Options
    So you can only have one or the other? Can't support both at the same time?
  • Options
    I'd check where Vanilla is trying to get the style files from, it wouldn't surprise me if Vanilla is looking in http://domain.com/subdirectory/themes/vanilla/styles/default when browsing through the subdir address, but in http://subdomain.domain.com/subdirectory/themes/vanilla/styles/default when using the subdomain.

    You might be able to modify Vanilla to work with both, but I bet it'd be much easier to redirect the subdirectory to the subdomain, or vise versa.
  • Options
    The path used in the database is "/community/themes/vanilla/styles/default/" or such, so I doubt you could have both, no. You could try changing that path to a full URL or a full file path and see if that works though.
  • Options
    I'm confused by this advice... doesn't vanilla understand and use the concept of a RELATIVE PATH to required resources, like css files? In both cases, the URL may differ, but the RELATIVE navigation from "here" (the root directory for vanilla) to the css file required would be the same, if proper relative path was used, as "no matter where you go, there you are" to quote Ram Dass. :) If everything isn't relative, isn't this a serious and basic bug that requires attention?
  • Options
    lechlech Chicagoland
    In your /conf/settings.php you'll need to update the paths relative to the new directory Vanilla is now sitting in for things like cookies and relative/absolute paths to work out. Otherwise your Vanilla installation will still think it's under the old folder and domain and obviously you don't want that.

    If you have access to phpMyAdmin, you'll need to navigate over to the LUM_Styles table and fix the relative paths of the themes to reflect their current location. Vanilla is obviously attempting to pull them from the old location that's why you don't see the CSS styles applied.
  • Options
    It uses relative paths for all the php files (extensions, languages, libraries, etc) but for some reason that path in the database is set up differently. I don't know why but I'm sure there must be a reason for it..hmmm....
  • Options
    But nothing has moved... I have a choice here, between: "http://domain.com/subdirectory" and "http://subdomain.domain.com" Both URLs point to the same exact place. Something, somewhere is clearly depending upon the FULL URL, which should be a big bad no-no. Or am I being dense here? The database appears to be fine, messages and comments show up fine, but in a very "html" format, rather than the much nicer frames one would expect. The only problem is the formatting, which seems to indicate that the css file(s) can't be found.
  • Options
    Nothing has moved, no, but from subdomain.domain.com the /subdirectory doesnt exist. Therefore the path (note the LUM_Style table) is leading to the wrong place as it's using /subdirectory/theme/whatever... It's not relying on the full URL, it's just that the relative path from the URL is actually different. I believe (though I could be wrong) that CSS files etc must be included using a web-accessible path and not a local file-system path therefore it's unavoidable..?
  • Options
    lechlech Chicagoland
    the /subdirectory/ is stored for each style within the LUM_Theme table. You'll want to edit each row you have listed in that table and remove the /subdirectory/ portion to get your themes back on track.
  • Options
    lechlech Chicagoland
    We need to convince mark to weed this little entry out in future versions as it's already become a headache for some when moving a Vanilla install around.
  • Options
    But that will break them for users not using the subdomain, surely?
  • Options
    No application needs to know the URL prefix by which it is reached, as it can use purely relative means to reach other parts of the code, data files, etc. This is clearly a bug, in my view.
  • Options
    lechlech Chicagoland
    OK, so I think I may have misunderstood. If I understand correctly now you've got 2 installations of Vanilla accessing the same database then?
  • Options
    Basically he just has one forum and he'd like two means of accessing it. Jfischer - vanilla IS using a relative path. The fact is that the relative path is DIFFERENT depending which address you use to access the forum. Try changing those paths in the database to a full URL and see if that works.
  • Options
    > The fact is that the relative path is DIFFERENT depending which address you use to access the forum.

    Huh? Clearly, either this is a new and highly speculative use of the term "relative" to which
    I have hitherto not been exposed, or I have gone all this time with a massively defective
    understanding of "relative" paths.

    Let me try again:

    1) Index.php lives in the topmost directory that vanilla can access, or needs to know about
    2) Everything else is BELOW the directory in which vanilla.php lives
    3) If vanilla were installed in the root directory of a webserver, it would work fine, so the "path" could be "/"
    4) Domains ain't paths. Domains get one to a specific directory in some cases, but this would be the "/" for that domain.
    5) Domains end in things like ".com", ".org", and so on. They are followed by a slash if the URL is specific to content.

    So what's the difference between two URLs that point to the SAME directory, given a single copy of vanilla, a single database,
    and the only difference being in the domain part of the URL:

    "http://domain.com/subdirectory"
    vs
    "http://subdomain.domain.com"

    Given that "http://subdomain.domain.com" points to "subdirectory" within "http://domain.com",
    and that "subdirectory" is where index.php lives, along with all the subdirectories one expects when
    running vanilla?
  • Options
    Because browsers know nothing of your internal server configuration. When you point your browser to subdomain.domain.com it provides that as a header in the request to your server - your server then interprets that and provides the browser with the contents of that directory 'subdirectory'. When you point your browser to domain.com/subdomain, that's passed in the request to your server, and the server provides the browser with the contents of that directory. Now, assuming one of those things has happened, the browser then finds in the code it has recieved that it also needs to make a request for '/subdirectory/theme/whatever/css' so it goes back to the server and asks for it. If you're browsing with subdomain.domain.com, the browser will request subdomain.domain.com/subdirectory/whatever because that's what it's been told to do relative to the url subdomain.domain.com. Your server will get that request, and look in 'subdirectory/subdirectory/whatever' and find that it doesnt exist. If you're browsing with domain.com/subdirectory and it makes a request for 'subdirectory/whatever' then it will request 'domain.com/subdirectory/whatever' relative to domain.com, the server will look for 'subdirectory/whatever' at which point it finds the information and passes it back. I'm having difficulty putting this into words without it being extremely confusing but I'm pretty sure that's the methodology behind it. Basically, regardless of what you use between the http:// and the /, the browser is told to request 'http://.../subdirectory/whatever'. If you're using a subdomain, your server is already looking in 'subdirectory' for the information anyway, and doesn't find a further 'subdirectory' in there so it fails. Does that make sense? I'll freely admit that i'm not 100% sure that's what's happening, but i am about 95% sure it is, and therefore it's difficult for vanilla to do anything about it unless you want it to work out how the user is accessing the forum and then provide the relative links differently. I think you can probably get round it by making vanilla provide the browser with a full URL of where to find the styles, because then it doesnt matter - in which case you'll need to change the path in the database to http://www.domain.com/subdir/.. OR http://sub.domain.com/... but i cant guarantee that will work. Have you tried it?
This discussion has been closed.