"Home" tab

lament

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?

jsanders

this sounds suspiciously like the "add your own tab" extension from a few days ago. i'll go find it. http://lussumo.com/community/comments.php?DiscussionID=447

lament

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.

jsanders

you rock, man, you *rock*

lech

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

nathan

I don't think we need any more individual extensions to manage manage tabs etc. I think we need an extension to allow the user to make them. the extension creates a form for adding new tabs. the tabs are saved and presented like the catagories page (take note... it could be built off the current catagories code). The ajax used on the catagories page can be re-used, so that the user can order the tabs by clicking a button (can we get drag and drop by the way?). We may need an extra table for this though, a row at least, in order to save the tabs. Save priciple could be applied to the panel. We canadd anything in there. So why not let the user do this through the admin interface, and not through direct coding? Thoughts?

Minisweeper

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

nathan

I think the table would be best. It would be costly for the server if we had the script re-write a document everythime we changed the order of the tabs/ added a tab. If we do it properly the fisr time, we won't have any problems later on. If it created the required database structure when it was first enabled, it would be the best way, but, I am not sure if there would b epermission issues with remote scripts created tables in the db? Anyone confirm/ disprove this?

Minisweeper

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?

nathan

>> i'll point out that the extensions script rewrites a doc when extensions are added and works fine. 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. This is just my thoughts. I have not benchmarked this so, I can't say what, if any improvements this would have, but to me, it seems like more work to invent a system to track changes, than using a pre-exiting system to hold htis data.

dom

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

nathan

Not for every page hit (load), just is the admin page, in which the configuration of the tabs is taking place.

lech

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

lech

But in all seriousness, the easiest way you can make this a fully functional self-contained extension without adding any extra flat files or database tables is simply pulling out the vanilla web path in your global application settings, and rewriting it down to include the preceeding http:// and cutting out the location. Not a difficult task :D

Minisweeper

/me 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

nathan

Mini, I would appreciate your help, but I can't start it until Wednesday. I am going to be away (with no internet connection Ahhhhh!!!!) until tues lunchtime (my time). Whisper me, or start a private discussion if you want to work with me on it.

Minisweeper

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

nathan

well. I thought (assumed) you were asking me to lend a hand. I will give it a go, but I WILL require assistance. So any help would be much appreciated. Since this might me a core feature (or a least core worthy), MArk might be willing to lend a hand also.

Mark

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.

nathan

@Mark: Roger that. * Don't make any new tables (check) * Keep data in a flat file (check)

ichigo

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