|
|
| Re: virtual hosts support [message #5240 is a reply to message #5238] |
Sat, 24 August 2002 12:07   |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
add to buddy list
ignore all messages by this user
|
|
Well, what you are actually asking for is to have 1 forum work across many domains. That is problematic for numerous reasons and while various hacks may be a perfect solution as a whole I do not think they are a goo idea.
For example, since cookies can only be set for a domain you are currently on, if I am logged it at forum.domain1.com and I go to
http://domain2.com/forum/, which happens to be the very same forum I'd still need to login again.
This is just one problem, there are others.
FUDforum Core Developer
|
|
|
|
|
|
| Re: virtual hosts support [message #5249 is a reply to message #5246] |
Sat, 24 August 2002 14:42 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
add to buddy list
ignore all messages by this user
|
|
| venus wrote on Sat, 24 August 2002 14:03 |
i think that logging to different domains is no problem, single user uses single domain usually.
|
That may be true in your situation, which is solved by the hack you've posted, but such an assumption cannot be made in a software that would be used by different people.
| Quote: |
but why do you prefer to have absolute links including server name and full path for all forum pages? such links make forum less flexible and make pages bigger.
|
Page size difference is negible, and if you use compressions like mod_gzip the difference is virtually non existant.
FUDforum Core Developer
|
|
|
|
|
|
|
|
| Re: virtual hosts support [message #26459 is a reply to message #5238] |
Thu, 21 July 2005 18:51 |
|
|
I'd like to see virtual support as well. I don't know if my concept of virtual support is the same as what has been mentioned already. I would like to run the same fudforum code from many virtual sites with independent forums between each site.
At the most basic level, if the GLOBALS.php file existed in a directory called 'sites', then a different GLOBALS.php file could be created for each site. Different databases, and file storage directories could be defined in each unique GLOBALS.php file (which would probably be renamed to say mysite_GOBALS.php or something).
All fudforum needs is a little more code up front to either parse the URL directly, and/or pass a domain variable with the URL, and select the appropriate GLOBALS.php for that site.
The admin tool for each site would have to be stripped down to dis-allow site owners from messing with the database names/directories and what not. A 'super' super user admin tool could be created to manage settings for all sites.
Of course, I've only just started exploring fudforum, so maybe I'm just blowing air out my lips 
|
|
|
|
|
|
| Re: virtual hosts support [message #26464 is a reply to message #26461] |
Thu, 21 July 2005 21:25 |
|
|
Ya, that sounds about like what I was thinking
I'm still a little confused about the differences between $WWW_ROOT_DISK and $DATA_DIR. $DATA_DIR appears to contain most of the dynamic data (errors, messages, tmp, files, cache), but there's also plenty of stuff in that directory that appear to be static (scripts, sql, etc). To tweak FUDforum down the lines of a multi-site configuration, there would have to be a clear seperation between what is owned by the individual site and what is owned by the host.
And sort of along those lines I'm curious, why does GLOBALS.php define the initial settings repetitiously?
for example:
$DATA_DIR = "/var/www/html/FUDforum/";
$ERROR_PATH = "/var/www/html/FUDforum/errors/";
$MSG_STORE_DIR = "/var/www/html/FUDforum/messages/";
$TMP = "/var/www/html/FUDforum/tmp/";
$FILE_STORE = "/var/www/html/FUDforum/files/";
$FORUM_SETTINGS_PATH = "/var/www/html/FUDforum/cache/";
Why not (sorry if my PHP is a little off):
$DATA_DIR = "/var/www/html/FUDforum/";
$ERROR_PATH = $DATA_DIR."/errors/";
$MSG_STORE_DIR = $DATA_DIR."/messages/";
$TMP = $DATA_DIR."/tmp/";
$FILE_STORE = $DATA_DIR."/files/";
$FORUM_SETTINGS_PATH = $DATA_DIR."/cache/";
This makes it a little clearer in the code as to the purpose of $DATA_DIR without limiting the operator's ability to customize it later.
|
|
|
|
|
|
| Re: virtual hosts support [message #26540 is a reply to message #5238] |
Tue, 26 July 2005 16:06 |
|
|
OK, this is frustrating....
Why is the URL hard coded into the themes????
I tried to relocate my FUDforum into a different directory location, but now it's un-usable because all the theme code keeps trying to run it from the old location.
What's the point of a GLOBALS.php if those values are just going to be hard copied into the themes?
|
|
|
|
| Re: virtual hosts support [message #26541 is a reply to message #26540] |
Tue, 26 July 2005 16:16 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
add to buddy list
ignore all messages by this user
|
|
The few values that are hard-coded by the template compiler are done for performance reasons. GLOBALS.php is the main configuration file allowing the admin panels to be used even if the URL had changed.
A simple theme rebuild would update the templates with the new value.
If you want GLOBALS.php to be always used, you need to do a simple modification to compiler.inc in the hadling of the FULL_ROOT template element.
FUDforum Core Developer
|
|
|
|
| Re: virtual hosts support [message #26543 is a reply to message #5238] |
Tue, 26 July 2005 16:41 |
|
|
Thanks for the tip, but as I've just discovered, it's far to easy to completely toast your theme with a slip in compiler.inc. Admin login won't save it now 
Guess I'll re-install and try again....
|
|
|
|
| Re: virtual hosts support [message #26544 is a reply to message #5238] |
Tue, 26 July 2005 17:14 |
|
|
Ah, I see the problem now.
You can't just tweak compiler.inc. Templates are using various flavours of quoting with FULL_ROOT. It's just not possible to replace it without breaking something along the way.
|
|
|
|
|
|
| Re: virtual hosts support [message #26549 is a reply to message #5238] |
Tue, 26 July 2005 18:10 |
|
|
??
That works for theme/default/login.php.
The main index on the other hand uses double quotes. Line 388 becomes:
header("Location: '.$GLOBALS['WWW_ROOT'].'index.php/l/"._rsidl);
Which ends in the expected parse error. Same in theme/default/cookies.inc, which then makes admin login broken.
The exisitng templates just aren't setup to allow substituting all global variables.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: virtual hosts support [message #26585 is a reply to message #26583] |
Wed, 27 July 2005 18:46 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
add to buddy list
ignore all messages by this user
|
|
The SQL schema for the tables is found inside the sql/* directory of the forum. You simply need to replace the table prefix token with the desired value and pipe them to the database.
Easiest way to remove admin options is to modify usercp template to not show them and then in include/adm.inc always deny access.
FUDforum Core Developer
|
|
|
|
| Re: virtual hosts support [message #28066 is a reply to message #26585] |
Mon, 10 October 2005 00:47 |
|
|
Yeh! Finally found more time to look at this.
Ok, so I have a modified GLOBALS.php that includes a new var $SITES_DIR. I have a modified core.inc that checks for the new global, and includes a GLOBALS over-ride file from the $SITES_DIR using some magic on the $_SERVER['HTTP_HOST'] to determine a domain name. This is good. I have one domain setup this way and FUD appears to be working OK.
So now I'm trying to re-create the FUD tables in a new database for a second domain. In sql/ I've created the 'create_virtual_site.php' script attached. Things are still a bit hard coded for the moment, but basically, given a site name (domain) and a password (SQL database password), it:
(a) sets DBHOST_USER, DBHOST_PASSWORD and DBHOST_DBNAME according to the site name and password (this DB, User and pass were previousely setup in MYSQL)
(b) Generates a new GLOBALS file in the $SITES_DIR for the domain using a reference template
(c) Finally, connects to the database and runs through every .tbl and .sql file in the sql/ directory to create and default the tables.
So far so good, with a few caveats:
- Running the .tbl and .sql files using PHP seems to get tripped up on the query end ';'. Is this a PHP thing or did I just code this wrong? I ended up coding it ot split the queries, strip the ending ';' and feed the queries on at a time.
- UNIX_TIMESTAMP (in def_forum.sql) needs to be specified as 'UNIX_TIMESTAMP()'. Again, is this a PHP thing or is this file incorrect?
So I've got all the tables created and defaulted. But when I attempt to run this forum it duffs with a 'Fatal error: SQL Error has occurred'. The same config file for the new domain can be made to work with an existing FUD database, so I'm pretty sure the initial config setup is correct. The new domain DB is setup exactly the same as the working DB setup, except that this DB was created and loaded from my script, and not from the standard FUD init script.
I don't know what the SQL error is. The sql_errors log file contains dated entries of the failure, but the error message is just garbage. In fact it's the exact same garbage for every line . Looking at my error file for the working forum domain, they are garbage as well. Very frustrating...
How do I find the real error messages?
Why are the error files reporting garbage?
Are the .tbl and .sql files in the sql directory correct or have they been lapsing in the development?
What must be done to correctly build the required tables from scratch for a working forum?
|
|
|
|
|
|
| Re: virtual hosts support [message #28084 is a reply to message #28075] |
Mon, 10 October 2005 12:00 |
|
|
How do I decode the error messages?
The *.sql files are not 100% PHP compatible (see note about UNIX_TIMESTAMP).
Ran all the queries inside *.tbl and *.sql. This does not create a functioning forum
|
|
|
|
| Re: virtual hosts support [message #28085 is a reply to message #28084] |
Mon, 10 October 2005 12:51 |
|
|
Ok, wrote a hack to decode the error files. Personally, I feel it's bad form to obscure error messages for ANY reason 
Here's the resulting error:
(/var/www/apps/FUDforum/index.php:126
/var/www/apps/FUDforum/index.php:360
/var/www/apps/FUDforum/theme/default/index.php:80
/var/www/apps/FUDforum/index.php:1197
) 1064: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
Query: UPDATE fud26_ses SET sys_id='120ba2075a610e6fa760f06a4bacc4d7', forum_id=0, time_sec=1128916891, action='Browsing the <a href=\"index.php?t=index\">forum list</a>', returnto='' WHERE id=
Server Version: 4.0.20
Seems the $ses_id passed into ses_update_status() is empty.
Guess I'll start picking apart the init script...
|
|
|
|
| Re: virtual hosts support [message #28101 is a reply to message #28085] |
Tue, 11 October 2005 10:44 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
add to buddy list
ignore all messages by this user
|
|
The errors are not obscured, base64 is a common way to make thing 7 bit safe. The reason forum encodes them is to ensure that 1 error message == 1 line to simplify parsing.
Decoding the file is trivial.
<?php
foreach (file("error_log") as $e) {
echo base64_decode($e);
}
?>
FUDforum Core Developer
|
|
|
|
| Re: virtual hosts support [message #28116 is a reply to message #28101] |
Tue, 11 October 2005 12:17 |
|
|
I agree base64 is a common way to make data 7 bit safe.
I also agree that it ensures 1 error = 1 line.
I totally disagree that this is an appropriate place to use it.
First the error messages contain printable data and in no way requires it to be 7 bit safe in the first place.
Second, these are ERROR messages. These should not be happening unless there's a problem with FUD. If there's a problem it should be fixed so error messages don't persist. There's no benefit to simplifying the parsing of theses messages. This isn't some kind of minutely status report which can make good use of some clever optimising.
Third, when an error occurs you can't always just bring up the admin page to see what it is. As I've found more often than not, many errors make the forum totally un-usable and the only way to find out why is through the error files. A simple database permission problem can be solved from the error files.
And finally, decoding the file is NOT trivial. It requires knowlege of PHP coding, or some other language. It also assumes you even know that the log files are encoded this way in the first place, which if you don't also requires knowlege of how FUDforum works so you can find the code that creates log entries. These are not things 90% of the users are going to have. These are not things 90% of the users should have to know to use your excellent forum.
Of all the applications I have running on my system, web based or otherwise, I can count exactly ONE that encodes log files and we're talking about it now.
Coming up with a text based log format is also trivial. To do anything else is just plain bad programming practice.
|
|
|
|
| Re: virtual hosts support [message #28117 is a reply to message #28085] |
Tue, 11 October 2005 13:05 |
|
|
The init script proved to be useful. Turns out my initial table creation script did not create an entry in the themes table. Without this entry, the anonymous login (or any login for that matter) fails to find the session after it's created.
Suggestion: UNIX_TIMESTAMP in file def_forum.sql should be {UNIX_TIMESTAMP} to make it clear that this is going to be substituted. It's far to similar to the MYSQL UNIX_TIMESTAMP() function, which technically does the same job if the '()' are included.
Here's my latest crack at virtual support:
Patch core.inc - look for a $SITES_DIR global variable. Load an alternate site file to over-ride GLOBAL values. This is totally compatible with all past/existing/future FUDforum installations.
Patch compiler.inc - Again, looking for a $SITES_DIR global variable, use either the original 'FULL_ROOT' hard coded substitutions in pages, or substitute the $GLOBALS['WWW_ROOT'] string. This should be totally compatible with all past/existing/future FUDforum installations. I can't say if it's 100% virtual site compatible (I don't know if all the templates will properly include the format). Seems there are still some css file issues that need looking at.
create-virtual-site.php - This can be run from the command line, hopefully to be someday incorporated into an interactive the FUD admin page option. Creates the necessary files and tables for a virtual site forum.
It's still sketchy. There's no admin page support of any kind, and things will probably break if there's any attempt to update the $GLOBALS from the admin page. But at least it opens the option to hosting multiple domains off the same FUD code base.
Question: I know you've cited performance reasons for hard coding the FULL_ROOT in theme pages. But the way I see it, you're already committed on every page that includes at least one PHP script on it. Does hard coding the FULL_ROOT by default really buy you that much more performance?
Question: I still have trouble seeing the distinction between the various directories declared in GLOBALS. In a multi-site environment, there are really only two distinctions: Dirs/Files which will be updated by the forum and Dirs/Files that will be shared by all but not updated. I'm using $DATA_DIR for the updatable forum stuff. Any paths which are also modifyable by the forum are based off this, errors/, messages/, tmp/, files/, cache/. $DATA_DIR can be easily switched for each site. I'm using $WWW_ROOT_DISK for all the common forum stuff (include/). Everything under $WWW_ROOT_DISK can be made world readable and only root writable. This totally protects the code base from any kind of external influence. Everything under $DATA_DIR can be made apache read/write. I have loose ends to look into regarding avatars and what not, but themes are looking to be a problem. Why are themes organised under $DATA_DIR and not $WWW_ROOT_DISK?
|
|
|
|
| Re: virtual hosts support [message #28121 is a reply to message #28116] |
Tue, 11 October 2005 16:45 |
|
|
Here are patches to admerr.php, core.inc and err.inc.t
First, I replace all (both) direct calls to error_log with a function __error_log. Now you have a single point of log formating. __error_log formats the time and message body. Instead of base64 encoding, newlines (and html '<br />') are replaced with the literal '\n', so each log entry goes on one line (in plain text). It's not pretty, but it's entirely readable under any circumstance and at least as fool proof as base64 encoding.
Next I introduce a new function __error_log_explode() which takes a formatted log line text string and returns the $time and $msg. $msg gets the htmlspecialchars() treatment and literal '\n' replaced with html '<br />'. Now you have a common 'decode' function.
The rest of the patch just changes code to use the new functions.
With __error_log() and _error_log_explode() FUD no longer needs to know or care what format the log files are stored as. As far as I can tell, text based logs will appear exactly the same. If you want to be really tricky, you could even mod __error_log_explode() to check for an old format base64 encoded log entry and handle it differently to be compatible with existing FUD log files. Since these are only used for logging errors and displaying them on the admin page, there really isn't any concern for processing overhead.
Encoding log files is never a good idea...
|
|
|
|
| Re: virtual hosts support [message #28124 is a reply to message #28121] |
Tue, 11 October 2005 19:09 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
add to buddy list
ignore all messages by this user
|
|
As far as CSS goes the reason it does not work is because a css file is a static file, so putting PHP vars into it will not work. You will need to patch forum.css.tmpl so that the image paths in there do not use the full path. It should be as simple as removing {FULL_ROOT} from the template.
Re: FULL_ROOT
The hardcoding probably does not buy a whole lot of performance, but every little bit counts... Plus as you've found out it is not that difficult to make it not hardcode the data, by tweaking compiler.inc.
Re: Directories
The compiled theme templates are placed in WWW_ROOT_DISK/theme directory so this needs to remain web server writable. The reason there many vars is to allow high traffic installs to split data storage across many locations. For most installs, they are just short-cuts to particular dirs. Things like uploaded avatars also go into WWW_ROOT_DISK.
FUDforum Core Developer
[Updated on: Tue, 11 October 2005 19:12] Report message to a moderator |
|
|
|
|
|
| Re: virtual hosts support [message #28127 is a reply to message #28126] |
Tue, 11 October 2005 20:34 |
|
|
The css could be incorporated into the pages themselves. I mean, it only really makes sense to include it as a separate file if you're hand coding the web pages. As long as everything is generated from templates, does it make any difference? You'd probably gain some speed increase by having it compressed with the original page instead of fetched separately.
Or alternately, the CSS could be located in the FULL_ROOT and created uniquely for each site?
Sure, it's easy enough to tweak compiler.inc, but not being part of the official code, it's an upgrade risk. Besides, the compiler.inc tweak is always going to be land mine for future breakage. I hope you'll consider including a virtual site enhancement some day.
Theme templates in WWW_ROOT_DISK is cool, updated avatars in WWW_ROOT_DISK is not. In a multi-site environment what there really needs to be is gobal default dir, extended with the site personal additions. So say pre-installed avatars come from WWW_ROOT_DISK and 'extra' site installed avatars come from {FULL_ROOT} with the two directories seemlessly blended together. Something I'm sure FUD was never designed for, so it's probably going to be a bear.
Silly question #1:
What's the point of having the 'Database Settings' section (DBHOST values) on the admin page? If these values aren't correct you can't get to the admin page. If you change them on the admin page, you'll never be able to go back and fix them if they're entered wrong. Just seems kind of odd to set them up on the admin page when really, your only option to change them is to edit the GLOBALS.php.
Silly question #2:
Perhaps this relates to your comment about splitting storage, but why link GOBALS.php in many places? Would it not be just as easy to leave it in one place and adjust references accordingly?
Thank you
Thank you or the error log patch. I like mine better  but hey, as long as it gets the job done. You don't know how many times I've had to look at the sql_errors while debugging my mods.
|
|
|
|
| Re: virtual hosts support [message #28128 is a reply to message #28127] |
Tue, 11 October 2005 20:46 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
add to buddy list
ignore all messages by this user
|
|
Keeping CSS in a separate file makes a LOT of sense, since the browser is then able to cache this information once and not fetch it again. By embeding into pages you make each page larger for no reason.
CSS cannot be inside the FULL_ROOT, since each theme can have its own stylesheet file, therefor they need to be in separate directories.
For avatars I'd wager you best bet would be intoroduce AVATAR_DISK_DIR and AVATAR_WWW_DIR variables into GLOBAS.php and use the to allow each site to specify their own avatar storage placeholder.
Re: Question #1
Several reasons, #1 to see what those settings are. Suppose you need to do some manual SQL work and forgot the forum's settings and what not. As far as adjusting the settings you can do that prior to manual data dump to another server so that the forum can start working in the new location instantly.
Re: Question #2
The file is linked in just 2 places, WWW_ROOT_DISK and adm/, which allows the forum to know precisely where it is without hardcoding its path with a full path.
FUDforum Core Developer
|
|
|
|
| Re: virtual hosts support [message #28129 is a reply to message #28128] |
Tue, 11 October 2005 21:22 |
|
|
Ok, I see your point about the CSS. Looking at the CSS template, I see 2 easy solutions here.
1) remove the two offending styles '.CatDesc' and 'th' from template and place these on every page so they can be modified by PHP
or
2) Change the template to use relative links in the first place (as easy as removing the {FULL_ROOT} from the template)
From past experience I can tell you that I never use a full URL when a relative reference will do. I have two servers running as mirrors with DNS doing round robin on the websites. When the URLs are relative, browsers will stick to which ever server they hit with the first domain lookup. When the URLS are full, browsers can and often do flip flop between the servers. Makes for messy browsing when you're trying to check out changes on the master before syncing the slave. Not that you could run FUD under these conditions anyway, but someday it would be nice to run it on both servers redundantly (give or take a few huge technical hurdles).
Besides, the pages themselves must already be served under WWW_ROOT, so a relative link can't possible break anything can it?
|
|
|
|
| Re: virtual hosts support [message #28130 is a reply to message #28129] |
Tue, 11 October 2005 21:51 |
|
|
hmm... why do you use a full path URL in the CSS anyway? Just looking at the resulting source for any page (like this one say) it would appear that all images are relative, and all are coming from the theme directory, so why should the CSS be any different?
Question:
In my create_virtual_site.php script, I check the DBHOST_DBTYPE just as the init script does to load the *.tbl files. In my GOBALS.php file, the $DBHOST_DBTYPE is empty. Somewhere FUD appears to default this to 'mysql' if no value is given. But in my create_virtual_site.php script, DBHOST_DBTYPE is not defaulted and if I don't specifically set it in the virtual site globals, then the table load breaks. Where in the regular fud code is $DBHOST_DBTYPE being defaulted to 'mysql'?
|
|
|
|
| Re: virtual hosts support [message #28131 is a reply to message #28130] |
Tue, 11 October 2005 23:38 |
|
|
Ok, still very confused about directories (sorry).
But first, compiler.inc there are a couple of instances of:
$GLOBALS['DATA_DIR'] . 'include/theme
These should be:
$GLOBALS['INCLUDE'] . 'theme
And second, I included three patches admforumicons.php, admsmiley.php and forum.css.tmpl. All to make image URLs relative (and remove any problems with CSS and FULL_ROOT).
Now I'm forever running into problems with the $GLOBALS['DATA_DIR'] '/sql /src /thm' trio. Compiling a theme as no site is fine (DATA_DIR is default), but compiling a theme online (not that a virtual site should) is a mess because DATA_DIR has been changed to the site data directory. As I'm using DATA_DIR for the virtual site directory, the trio doesn't fit. All three are static and should not be under the control of the virtual site (ie apache write). Yet at the same time they also don't fit the description of WWW_ROOT_DISK either. Looks to me there needs to be three main directories:
1) web viewable sources - adm,images,theme,main (WWW_ROOT_DISK)
2) user data - errors, messages,files,cache,etc (DATA_DIR)
3) non-web sources - include,scripts,sql,src,thm (SOURCES_DIR?)
OR user data goes to a new definition (FORUM_DIR?) and #3 above remaind the existing DATA_DIR.
Either that or don't stop with $INCLUDE in GLOBALS.php. Maybe add $SQL, $SRC and $THM as configurable directories as well?
On the one hand I realize that I'm asking these questions out of my drive to use virtual sites and they in no way impact a single site install. On the other hand I think asking these questions will help FUD become more future proof and easier to maintain.
Maybe I'll just sleep on it for a day or two
|
|
|
|
| Re: virtual hosts support [message #28136 is a reply to message #28131] |
Wed, 12 October 2005 09:25 |
Ilia
Messages: 13241
Registered: January 2002
Karma: 0
|
Senior Member
Administrator
Core Developer |
add to buddy list
ignore all messages by this user
|
|
No, it should be $GLOBALS['DATA_DIR'] . 'include/theme reason being that inside include/ we have non-theme specific includes like core.inc and inside theme/[theme name]/ includes that are theme specific.
User data and sources are both in DATA_DIR you want some sources to be accessible so that people can create their own themes and customize existing ones. Otherwise you prevent all means of adjusting the forum's layout for the users.
FUDforum Core Developer
|
|
|
|
| Re: virtual hosts support [message #28161 is a reply to message #28136] |
Wed, 12 October 2005 14:34 |
|
|
"inside include/ we have non-theme specific includes like core.inc" - 100% with that idea.
"inside theme/[theme name]/ includes that are theme specific"
Well why didn't you put them in 'theme/[theme name]/incudes' then?
As it is in the default install, $GLOBALS['DATA_DIR'].'include/theme' is under the exact same path as $GLOBALS['INCLUDE'].
So I've got a FUD install with a 'themes' directory in my main 'include' directory which makes no sense. I should have an 'include' directory under my 'theme/[theme name]' directory were it belongs. Wouldn't that make more sense??
A good directory layout should be obvious at a glance...
|
|
|
|
|
|
| Re: virtual hosts support [message #28168 is a reply to message #28167] |
Wed, 12 October 2005 16:34 |
|
|
Ah, I mis-interpreted your earlier comment about "theme/[theme name]/ includes".
So then $GLOBALS['DATA_DIR'] . 'include/theme' DOES EQUAL $GLOBALS['INCLUDE'] . 'theme'.
You can't have it both ways?
|
|
|
|
Members
Calendar
Search
Help
Control Panel
Logout [ CommonCrawl [Bot] ]
Home
]