TranceAddict Forums (www.tranceaddict.com/forums)
- Site Suggestions
-- Ignore feature.
Pages (2): « 1 [2]

quote:

Originally posted by paranoik0 both cases shouldn't be a problem i think? most users should have very few people (none even) in their ignore list, so the aditional stress to the database wouldn't be big. also it isn't a huge thing that less threads would show up. maybe the best solution should be some message like "ignored thread" in the place of it

yes, that is what i want.

quote:

Originally posted by Arbiter I don't think it should be that hard. Every time a thread or group of threads is retrieved from the database it must retrieve the username of the thread starter of each thread in order to display that column on the forum table. So the each "row" result of the query probably contains a field like 'thread_starter.' It would be pretty easy to simply compare that field to the contents of the logged in user's ignore list and not echo the row of information if a match is found. The only problem I see is that the algorithm probably retrieves a constant number of threads and displays them, so if you had ignored threads in the bunch it might display fewer threads on a page than it otherwise would. This could be avoided by repeating the querying process until threadsperpage threads have been displayed, but this would place additional stress on the database which may not be worth it.

Actually come to think of it, it's probably very easy to implement without putting any stress on the database.

If it's a SQL database, the threads are probably retrieved using an sproc that doesn't and can't take any user-specific parameters (just generic ones like forum ID and how far back to retrieve posts from), so changing the database itself to handle the issue would be nearly impossible. That's what I was originally thinking about but then I realized that there's no need to change the database at all.

Since the PHP script has to parse through all the returned records anyway to display them, all Del would have to do is stick an extra 2 or 3 lines in the PHP script with an "if" statement that checks against the ignore list and just doesn't display the record if the user is ignored. So we're not trying to modify the query's result set, just ignore some of the records inside it. I think that's essentially what the "in-thread" viewer script already does, it's just not implemented in the thread "list" script.

The thread count might end up being wrong, but in that case you could just add one more line to the if statement that decrements it for every record that gets ignored.

That should be pretty simple, right Del? I know you're a busy guy but I think this is actually a lot more straightforward than it seemed at first.

he is back!!!


bastard.


anyways, yes, please change the whole site just for me Del. I won't care how many threads per page.

why god?? why??

Im with margs on this one.

quote:

Originally posted by j_spot Im with margs on this one.

it has been really bad this past week, eh?

ok well this is what we gonna have to do. we as a community have to flame the fuck out of him till he runs away on fire. since im on his ignore list and rod rico is as well we need a team effort. since me and rod are the ones that flame him the hardest and he has us on ignore i say whenever we flame him you people should quote us so he can read it. disguise it too. when u quote us just add a lol so he doesnt think ur quoting on purpose. we need help from everyone tho. stp digi lkd, whoever

quote:

Originally posted by DigiNut That should be pretty simple, right Del? I know you're a busy guy but I think this is actually a lot more straightforward than it seemed at first.

it's simple to code... i can even tell what the code is (or what i'd write) but when you think that this additional database query will be run each(!) time every(!) user reloads a forumdisplay page, it adds yet another considerable bunch of load on the server.
but then again, ta has the "thread preview" thing, which is, i must say, the biggest rape of servers and waste of bandwidth seen from vb - or any php script for that matter - yet

as for flaming the shit out of or banning someone just because somebody else is annoyed by his posts, i think, is rather immature and discriminatory.

quote:

Originally posted by Vivid Boy ok well this is what we gonna have to do. we as a community have to flame the fuck out of him till he runs away on fire. since im on his ignore list and rod rico is as well we need a team effort. since me and rod are the ones that flame him the hardest and he has us on ignore i say whenever we flame him you people should quote us so he can read it. disguise it too. when u quote us just add a lol so he doesnt think ur quoting on purpose. we need help from everyone tho. stp digi lkd, whoever

dude, we tried that with you but you just got stronger. we have to think, what would get you to leave, and do that.

quote:

Originally posted by Jocker it's simple to code... i can even tell what the code is (or what i'd write) but when you think that this additional database query will be run each(!) time every(!) user reloads a forumdisplay page, it adds yet another considerable bunch of load on the server. but then again, ta has the "thread preview" thing, which is, i must say, the biggest rape of servers and waste of bandwidth seen from vb - or any php script for that matter - yet

Thread Preview (surprisingly) seems intensive but isn't, when you retrieve all the thread info from the thread table there is also a left join on the icon table to obtain icons (if any) for that particular thread (within the same query) - a left join is also done on the post table to obtain the preview text of the first post (whose postid is already within the thread table). In order to handle the ignoring of users I would have to throw the user table into the fray and check that as well - it may slow things down a bit - and - I would try it, but, to handle the 0.0000001% of cases when it would matter - seems pointless to me.

quote:

Originally posted by Swamper Thread Preview (surprisingly) seems intensive but isn't, when you retrieve all the thread info from the thread table there is also a left join on the icon table to obtain icons (if any) for that particular thread (within the same query) - a left join is also done on the post table to obtain the preview text of the first post (whose postid is already within the thread table). In order to handle the ignoring of users I would have to throw the user table into the fray and check that as well - it may slow things down a bit - and - I would try it, but, to handle the 0.0000001% of cases when it would matter - seems pointless to me.

yeah, i'm definitely suprised that the preview is not intensive... well, mysql is the fastest dbms out there, and we have to give it to it. still, though, the previews sound like a big bandwidth-consumption issue. it's up to you, of course.

as for bandwith economy, i would also suggest substituting the text properties which are entered for every post (like font face=blabla color=blabla) for stylesheet entry (like font class=nf)... it is said to provide a great economy without any usage impairment.

more on that here:
http://www.vbulletin.com/forum/showthread.php?s=&threadid=17943

and a more generic discussion of the ways to save bandwidth here:
http://www.vbulletin.com/forum/show...&threadid=29446

I know all about CSS and bandwidth saving measures - which is why the download pages went javascript a long time ago

However.. in reality.. the forums consume about 1/18th of the 7000+GB that gets used on the site monthly, so it is not an issue.

Besides, most of the people with large forums who whine about bandwidth are doing so because they don't have mod_gzip enabled (mod_deflate in apache 2.x) which compresses pages to 1/6th its original size anyways (even at its most basic compression level).

thanks for explanations. gzip is a wonderful thing, i know
since you are following this thread, just wanted to let you know that the in-forums or in-thread search (the field on the bottom right) always gives an error... i guess it's due to all the changes that you did to search. could you also, if you have time, explain what you've done to search. i assume, you brought it to a separate database? i just like to know, might i do this for my own forum (very small one). thanks.

quote:

Originally posted by Swamper Thread Preview (surprisingly) seems intensive but isn't, when you retrieve all the thread info from the thread table there is also a left join on the icon table to obtain icons (if any) for that particular thread (within the same query) - a left join is also done on the post table to obtain the preview text of the first post (whose postid is already within the thread table). In order to handle the ignoring of users I would have to throw the user table into the fray and check that as well - it may slow things down a bit - and - I would try it, but, to handle the 0.0000001% of cases when it would matter - seems pointless to me.

Del, can't you just load the ignore list once when the session starts (or when the ignore list is changed), store it in a session variable, and write the filtering code in the PHP script instead of the SQL query?

There's no need to do another join - just query the ignore table by itself and use PHP to do the real work. That's basically one query per login, doesn't seem like a big slowdown. Most people don't have more than 10 or 20 users on ignore so it wouldn't be that memory-intensive either (300 users * 20 names * 30 char string ~ 180k).

Hell, I'll write the code for you if you want (assuming I can figure out vB).

Powered by: vBulletin
Copyright © 2000-2021, Jelsoft Enterprises Ltd.