FUDforum: FUDforum Suggestions » virtual hosts support

Home » FUDforum » FUDforum Suggestions » virtual hosts support

Show: Today's Messages :: Polls :: Message Navigator

virtual hosts support [message #5238]

Sat, 24 August 2002 12:10

venus

Messages: 30
Registered: August 2002
Location: Urals, Russia

Karma: 0

Member

current version of FUDforum doesn't support virtual hosts, where absolute url can be either http://www.domain.com/forum/ or http://forum.domain.com/ or http://forum.intranet.domain/.

i think there are no important reasons for this limit and not to hard to add virtual domain support to FUDforum:

1. do not hardly configure cookie domain in GLOBALS.php but set it from HTTP_HOST environment variable.
right now i use hacked root_index.php.t, with $GLOBALS['COOKIE_DOMAIN'] = $_SERVER['HTTP_HOST'];
right after include_once "GLOBALS.php";

2. do not make all links absolute (http://domain/root/path/file) after theme rebuilding but use relative (path/file) instead. now i use msg file converted by this sed script:
s%{ROOT}%http://'.\$_SERVER['HTTP_HOST'].\$_SERVER['PHP_SELF'].'%g
s%{VAR: url}%http://'.\$_SERVER['HTTP_HOST'].'{VAR: url}%g

i know my hacks is not best solution but it works fo me.

correct me if too hard to add virtual domain support.

[Updated on: Sat, 24 August 2002 12:12]

Report message to a moderator

Re: virtual hosts support [message #5240 is a reply to message #5238]

Sat, 24 August 2002 16:07

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

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

Report message to a moderator

Re: virtual hosts support [message #5246 is a reply to message #5240]

Sat, 24 August 2002 18:03

venus

Messages: 30
Registered: August 2002
Location: Urals, Russia

Karma: 0

Member

prottoss wrote on Sat, 24 August 2002 22:07

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.

i think that logging to different domains is no problem, single user uses single domain usually.

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.

Report message to a moderator

Re: virtual hosts support [message #5249 is a reply to message #5246]

Sat, 24 August 2002 18:42

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

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

Report message to a moderator

Re: virtual hosts support [message #5262 is a reply to message #5249]

Sun, 25 August 2002 11:00

venus

Messages: 30
Registered: August 2002
Location: Urals, Russia

Karma: 0

Member

if dynamic cookies domains and relative links can be useful in situation with many virtual hosts and not harmful in other situations - this features must be implemented. Smile

Smile

Report message to a moderator

Re: virtual hosts support [message #5264 is a reply to message #5262]

Sun, 25 August 2002 16:01

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

venus wrote on Sun, 25 August 2002 07:00

if dynamic cookies domains and relative links can be useful in situation with many virtual hosts and not harmful in other situations - this features must be implemented. Smile

Smile

If you want it so much, you are more then welcome to implement it Wink

Wink

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #26459 is a reply to message #5238]

Thu, 21 July 2005 22:51

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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 Smile

Smile

Report message to a moderator

Re: virtual hosts support [message #26461 is a reply to message #26459]

Thu, 21 July 2005 22:58

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

It seems to me that the simplest solution would be to modify the GLOBALS.php to retrieve the "core" settings like paths and database values from some data store based on the domain.

It seems like a trivial hack anyone interested could easily add.

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #26464 is a reply to message #26461]

Fri, 22 July 2005 01:25

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

Ya, that sounds about like what I was thinking Smile

Smile

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.

Report message to a moderator

Re: virtual hosts support [message #26466 is a reply to message #26464]

Fri, 22 July 2005 02:00

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

DATA_DIR and WWW_ROOT_DISK will differ if during 1st stage of the install you specified different values for those two.

Other settings are listed in full to allow on advanced installs to have those directories be located elsewhere...

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #26540 is a reply to message #5238]

Tue, 26 July 2005 20:06

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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?

Report message to a moderator

Re: virtual hosts support [message #26541 is a reply to message #26540]

Tue, 26 July 2005 20:16

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

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

Report message to a moderator

Re: virtual hosts support [message #26543 is a reply to message #5238]

Tue, 26 July 2005 20:41

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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 Crying or Very Sad

Crying or Very Sad

Guess I'll re-install and try again....

Report message to a moderator

Re: virtual hosts support [message #26544 is a reply to message #5238]

Tue, 26 July 2005 21:14

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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.

Report message to a moderator

Re: virtual hosts support [message #26547 is a reply to message #26544] Tue, 26 July 2005 21:44

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

Not entirely correct,


<?php
case 'FULL_ROOT':

                                $ret .= '\'.$GLOBALS[\'WWW_ROOT\'].\'';   

                                break;
?>

Will do the trick.

The only other thing you will need to do is alter forum.css.tmpl not to use FULL_ROOT, since css file cannot contain any PHP code inside it Smile

Smile

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #26549 is a reply to message #5238]

Tue, 26 July 2005 22:10

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

??

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.

Report message to a moderator

Re: virtual hosts support [message #26551 is a reply to message #26549]

Tue, 26 July 2005 22:18

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

Existing templates primarily use this value for redirect so grep for header() lines in the code and convert them to use single quotes as needed.

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #26554 is a reply to message #26549]

Tue, 26 July 2005 22:35

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

I've added a patch for FUDforum (it ended up occuring in very few place) that should make the FULL_ROOT coversion safe to do.

http://cvs.prohost.org/c/index.cgi/FUDforum/chngview?cn=7155
http://cvs.prohost.org/c/index.cgi/FUDforum/chngview?cn=7156

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #26583 is a reply to message #5238]

Wed, 27 July 2005 21:45

Anonymous

OK, cool. Those are the same files I modified.

I added this to the beginning of core.inc:

/* virtual support */
if (isset($_SERVER['HTTP_HOST'])) {
....$domain = explode('.', $_SERVER['HTTP_HOST']);
....$count = count($domain) - 1;
# strip the dot name
....$GOBALS['FORUM_SITE'] = stripslashes($domain[$count-1] . '.' . $domain[$count]);
....require($DATA_DIR."sites/".$GOBALS['FORUM_SITE']);
}

Actually, I think it would be smarter to add a $GLOBALS['VIRTUAL_SITESDIR'] variable to $GLOBALS.php, then have this core.inc snippet check to see if the variable is set before deciding to do anything special. compiler.inc could check the same VIRTUAL_SITESDIR and decide whether to automatically build themes with FULL_ROOT static or dynamic.

In the sites directory, for each virtual site I created a $GLOBALS replacement file containing something like this:

<?php
$GLOBALS['WWW_ROOT'] = "http://forum.mysite.com/";
$GLOBALS['DATA_DIR'] = "/var/www/mysite.com/FUDforum/";
$GLOBALS['ERROR_PATH'] = $GLOBALS['DATA_DIR'] . "errors/";
$GLOBALS['MSG_STORE_DIR'] = $GLOBALS['DATA_DIR'] . "messages/";
$GLOBALS['TMP'] = $GLOBALS['DATA_DIR'] . "tmp/";
$GLOBALS['FILE_STORE'] = $GLOBALS['DATA_DIR'] . "files/";
$GLOBALS['FORUM_SETTINGS_PATH'] = $GLOBALS['DATA_DIR'] . "cache/";

$GLOBALS['COOKIE_DOMAIN'] = "forum.mysite.com";

$GLOBALS['DBHOST_USER'] = "xxxx";
$GLOBALS['DBHOST_PASSWORD'] = "xxxx";
$GLOBALS['DBHOST_DBNAME'] = "mysite.com";
etc...
?>

I can redirect the MYSQL to a different DB for each site. Including the compiler.inc tweak, this makes the forum work across virtual sites. With caveats. I still haven't crossed the avatar/smileys bridge yet. For now I'm happy to just leave these non-modify for the virtual forums.

I have to create the individual virtual site directories, and virtual site DBs. Is there an easy way to regenerate the default tables in a new database without writing new code?

The admin tool updates the main GLOBALS.php file directly. This would be far easier to deal with if some or all of this information were stored in a table as well, but for now I'll settle with some kind of control over what the admin tool can do. For instance I don't want virtual site admins to be messing with Database Settings. What's the easiest way to remove admin options? Are they dynamically included or is the admin page set in stone?

Report message to a moderator

Re: virtual hosts support [message #26584 is a reply to message #26583]

Wed, 27 July 2005 21:49

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

Sorry, forgot to login....

Report message to a moderator

Re: virtual hosts support [message #26585 is a reply to message #26583]

Wed, 27 July 2005 22:46

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

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

Report message to a moderator

Re: virtual hosts support [message #28066 is a reply to message #26585]

Mon, 10 October 2005 04:47

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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?

Attachment: create_virtual_site.php
(Size: 3.30KB, Downloaded 1092 times)

Report message to a moderator

Re: virtual hosts support [message #28075 is a reply to message #28066]

Mon, 10 October 2005 15:04

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

The "garbage" is actually the entire error with additional debug information that has been base64 encoded.

The *.sql files are always up to date.

You need to run the queries found inside *.tbl and *.sql files

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #28084 is a reply to message #28075]

Mon, 10 October 2005 16:00

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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 Crying or Very Sad

Crying or Very Sad

Report message to a moderator

Re: virtual hosts support [message #28085 is a reply to message #28084]

Mon, 10 October 2005 16:51

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

Ok, wrote a hack to decode the error files. Personally, I feel it's bad form to obscure error messages for ANY reason Mad

Mad

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

Report message to a moderator

Re: virtual hosts support [message #28101 is a reply to message #28085] Tue, 11 October 2005 14:44

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

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

Report message to a moderator

Re: virtual hosts support [message #28116 is a reply to message #28101]

Tue, 11 October 2005 16:17

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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.

Report message to a moderator

Re: virtual hosts support [message #28117 is a reply to message #28085]

Tue, 11 October 2005 17:05

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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?

Attachment: patch-compiler.inc.txt
(Size: 2.06KB, Downloaded 970 times)
Attachment: patch-core.inc.txt
(Size: 0.55KB, Downloaded 946 times)
Attachment: create_virtual_site.php
(Size: 5.76KB, Downloaded 1035 times)

Report message to a moderator

Re: virtual hosts support [message #28121 is a reply to message #28116]

Tue, 11 October 2005 20:45

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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

Attachment: patch-admerr.php.txt
(Size: 1.37KB, Downloaded 1001 times)
Attachment: patch-core.inc.txt
(Size: 4.55KB, Downloaded 998 times)
Attachment: patch-err.inc.t.txt
(Size: 1.75KB, Downloaded 979 times)

Report message to a moderator

Re: virtual hosts support [message #28124 is a reply to message #28121]

Tue, 11 October 2005 23:09

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

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 23:12]

Report message to a moderator

Re: virtual hosts support [message #28126 is a reply to message #28121]

Tue, 11 October 2005 23:38

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

Error log reporting format has been changed to a non-encoded form. You can find the patch here:
http://cvs.prohost.org/c/index.cgi/FUDforum/chngview?cn=7375

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #28127 is a reply to message #28126]

Wed, 12 October 2005 00:34

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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 Wink

Wink

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.

Report message to a moderator

Re: virtual hosts support [message #28128 is a reply to message #28127]

Wed, 12 October 2005 00:46

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

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

Report message to a moderator

Re: virtual hosts support [message #28129 is a reply to message #28128]

Wed, 12 October 2005 01:22

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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?

Report message to a moderator

Re: virtual hosts support [message #28130 is a reply to message #28129]

Wed, 12 October 2005 01:51

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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'?

Report message to a moderator

Re: virtual hosts support [message #28131 is a reply to message #28130]

Wed, 12 October 2005 03:38

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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 Smile

Smile

Attachment: patch-admforumicons.php.txt
(Size: 1.15KB, Downloaded 929 times)
Attachment: patch-admsmiley.php.txt
(Size: 1.04KB, Downloaded 948 times)
Attachment: patch-forum.css.tmpl.txt
(Size: 0.91KB, Downloaded 954 times)

Report message to a moderator

Re: virtual hosts support [message #28136 is a reply to message #28131]

Wed, 12 October 2005 13:25

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

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

Report message to a moderator

Re: virtual hosts support [message #28161 is a reply to message #28136]

Wed, 12 October 2005 18:34

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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

Report message to a moderator

Re: virtual hosts support [message #28167 is a reply to message #28161]

Wed, 12 October 2005 20:26

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

Because in theme/ we have compiled *.php files in include we have function/class defenitions. Hence the breakdown.

FUDforum Core Developer

Report message to a moderator

Re: virtual hosts support [message #28168 is a reply to message #28167]

Wed, 12 October 2005 20:34

ruzam

Messages: 44
Registered: July 2005

Karma: 0

Member

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?

Report message to a moderator

Pages (2): [1 2 › »]

Previous Topic:	dont show catagories if they are invisible
Next Topic:	default forum

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun Dec 22 04:06:59 GMT 2024

Total time taken to generate the page: 0.03500 seconds