Looked in the extensions but didn't see it.

I'm sure it's easy: is there an extension to simply pop in a "Home" tab up top to go to the front of a website?

so if i wanted to add a Home tab, it would be:

/*if (in_array($Context->SelfUrl, array("index.php", "categories.php", "comments.php", "search.php", "post.php", "account.php", "settings.php"))) {

$Menu->AddTab("Home", "Home", "../index.php", "HomeTab", $Attributes = "", $Position = "0", $ForcePosition = "1");

}

got it.. setting it to position 0 puts it before Discussion.

or you could just edit the forum banner to break up the links (ie lussumo points to the main domain and community points here).

that sounds fun. doesnt *need* a db, could use basic files.
i'm up for anything that induces and encourages lazyness!

i'll point out that the extensions script rewrites a doc when extensions are added and works fine.
as for permissions, no reason why it should complain?

I would rather it was kept in a flat file. It is *far* quicker to include a PHP file with a list of variables and values in it, than it is to access your database for *every single page hit*.

Unless I misunderstood you of course...

I think the idea to keep the settings in a flat file, is just simply for portability. If for any reason you do decide to hose and resurect your Vanilla installation by hand, do you really want to bothing resetting ALL of your options you had set before? I think the obvious answer here is no, and at the moment, it really doesn't seem to impact any of the performance. Either way, these calls have to all come from somewhere, and php is totally able to make all kinds of read and write moves with hardly a hit in speed for small tasks like this.

The only time it would really matter is if you're pulling that data from a 5.25 floppy drive, on a 8086 over a 20 year old serial cable and running it over a 9600 baud model before running it back to the php box on the rest of the network. Otherwise flatfiles work great for data that remains static :D

Minisweeper doesn't quite see what relevance lechs last comment on the rest of the discussion.
As for flat files; isnt one of the other major benefits of using them to hold the extensions that you can include() that file and it does all the rest?
In any case, as i said first, i think nathans idea is cool. someone make it by monday or i might have a (pretty poor) go at it

oh, i didn't realise you were actually planning on making it; i'll leave it to you then since mine would probably suck. If i can help with any basic stuff then gimme a shout.-

I know this, but... I ddon't really like this. I woul rather keep it all in a database. It is going to be stored somewhere, so why not put it in a place where 'data' is supposed to be kept.

The absolute BIGGEST performance hit any web application takes is when it connects to the database. Lech is correct that part of the reason for keeping all of those settings in flat files is for portability, but more than that I wanted to have as few queries to the database as possible.

Let me give you an example of a time when I saw a massive slowdown with the code of Vanilla - and required me to make a big change:

I wanted to set up custom user preferences for extension authors. Originally I had each of the preferences on the user table - one column per preference. But I wanted extension authors to be able to add new extensions without altering the user table.

So, my idea was that there would be a separate LUM_UserPreference table that contained Name & Value pairs where the Name is the name of the preference, and the value is the value of the preference.

I actually set up the application to work this way, and I made it so that on every single page load when I would query the database for information about the current user, I would also query the database for these preferences. This was ONE extra query that returned multiple records that were then transformed into an associative array on the user object.

When I implemented the change, I noticed an INSTANT slowdown. As a test, I set up a script and ran it against the site watching for slowdown and failures. The application practically ground to a halt under this stress testing.

I was pretty pissed for a few minutes. Then I thought of the method that I ended up using: just serializing the associative preference array and saving to a single field in the user table. Which was great because I only have to run a single query as I was before. I ran *that* under stress testing and it flew.

But yeah - all of those extra queries are just awful for speed of an application. If ever possible you should keep it to flat files and include them with php's include statement. That's one of the big reasons why Vanilla is so fast.

yeah and i also hate the idea of extentions who need tables in the db...or even extentions that alter table structures and such things

thats one big point why most extentionsystems of other boards do suck in my opinion..and thats one thing that causes incompatibility issues