[FIX] - Users can't logout

[Overgrow]

How many times have you heard that a vB user cannot properly logout? They'll hit logout, go back to the index, and still be logged in with their old username. The solution listed here is to have them manually delete their cookies-- which makes it seem like there is something wrong with the code. Obviously there is not, but I don't think it is constantly the "corrupted cookie" excuse that is quoted. Kier mentioned it before in previous posts on this matter, but the problem often stems from which domain has sent the user cookies.

www.overgrow.com (http://www.overgrow.com)
and often they will have a bblastvisit cookie from
overgrow.com without the www

When they go to clear cookies, they will clear from whichever domain they are currently on. But if the other domain's cookie still exists, they will not be able to logout. Kier's answer consisted of having the user block the other domain in their browser but I think I have a more elegant solution.

In global, add:

if ( !preg_match("/^www/i",$_SERVER[HTTP_HOST]) ) {
header("location:http://www.overgrow.com$PHP_SELF?$_SERVER[QUERY_STRING]");
exit;
}


Which will stop people from going to the domain without the www. Or you could reverse it and only have them use the domain without it.

Then in member.php change:

eval("standarderror(\"".gettemplate("error_cookieclear")."\");");

to:

if ($fwd!="yes") {
if ( preg_match("/^www/i",$_SERVER[HTTP_HOST]) ) {
header("location:http://overgrow.com/edge/member.php?action=logout&fwd=yes");
exit;
} else {
header("location:http://www.overgrow.com/edge/member.php?action=logout&fwd=yes");
exit;
}
} else {
eval("standarderror(\"".gettemplate("error_cookieclear")."\");");
}


The member code will determine which domain they are on, then forward them to the other domain and clear those cookies as well. Works like a charm, my users are no longer complaining about being stuck logged in.

[eva2000]

reminds me, my members use to have that problem last year so

http://prodtn.cafepress.com/8/525818_B_tn.jpg

http://zoom.cafepress.com/3/513513_zoom.jpg

LOL

[eva2000]

for me all i did was add to bottom of headinclude template


<base href="$bburl">

[Overgrow]

LOL.. I'm gonna have to link over here to show them that shirt. Most people respond to the questions "Why would you ever want to log out??"

So how did you fix the problem G?

ps. a friend of ours recently helped me with the forum speed.. site is flying, had 960 on yesterday, same servers as before

[eva2000]

may i ask what ya changed for the forum speed ?

edit: i see mysql 4 with fulltext search and innodb tables :cool:

is this mysql 4.1 that was just released

[Overgrow]

I guess we did it a few days early as it is mySQL 4.0.9-gamma. After seeing what he could do on his site with nearly 2 million posts, I wanted to try it. He upgraded PHP, Apache, and the mySQL.. changed to innoDB then we selectively kept somethings in MyISAM. Session was actually better as an InnoDB over a HEAP.

Then he added a few indices I should've had.. my main problem was site hang when more than a few people would search (15 million record searchindex was only a fraction of our full post database).

[nuno]

:cool:

All tables except for post and thread [fulltext MyISAM] were changed to InnoDB for the row-level-locking.)

Heh, how do i change them to InnoDB?
Like this?

ALTER TABLE blahblah TYPE = InnoDB;

[nuno]

What about the search table?
From mysql.com

As of Version 3.23.23, MySQL has support for full-text indexing and searching. Full-text indexes in MySQL are an index of type FULLTEXT. FULLTEXT indexes are used with MyISAM tables.....

[Overgrow]

I'm not recommending this and I can't troubleshoot it as someone else did almost all of the work. There are no "set instructions" for converting your vB this way. However..

search table is also Innodb, it is used for storing queries.
I no longer have searchindex or words tables. :)

This requires a new search.php of course, but I did not write it. I'm selectively changing certain tables back to MyISAM if they are primarily read-only, then they have no benefit as InnoDB. I have a few sections (non-VB but tied in) that are 99% read only so they have been put back to MyISAM.

[nuno]

Thanks Overgrow. :)
Fulltext uses MyISAM, when i try to add a new table with fulltext and InnoDB i get a message saying FULLTEXT does not support InnoDB.
I guess it would require a new search table, and adding WHERE MATCH blahblah to SELECT queries right?
Paul, where are you? :D

[Overgrow]

Last thing I want to do is create any more work for the person kind enough to do this for me ;)

The solution there is that post is kept as MyISAM and fulltext searches are done directly on that table.

[nuno]

Oh, i see.
Then you add fulltext(field1,field2) to post?
No changes were made to search table?

[Overgrow]

The search table doesn't appear any different but I can't say for sure on that or on adding fulltext fields to post.. I'm not sure if that means changing the field type? Because title is still varchar100 and pagetext is still mediumtext.

[nuno]

Maybe Paul will release it as a hack, i hope so. :p

[alexi]

Originally posted by nuno
Maybe Paul will release it as a hack, i hope so. :p

Make that 2 of us! I would love to try this :)

[Paul]

This is facinating. Keep us updated if a hack gets released :)

[fastforward]

Originally posted by nuno
Maybe Paul will release it as a hack, i hope so. :p
It's pretty simple and I'll be happy to provide instructions.

The trouble is that the search.php really needs to be replaced. Jelsoft would probably get upset if I posted the entire file. If somebody wants to get the approval for me, I'll release it. :)

Basically, the changes I made are:

Convert all tables except post, to InnoDB. (This includes session)
Apply a hack to maintain user, post and thread counts. This simply involves creating a table and making a few changes in index.php. The only count(*)'s we have to worry about are ones that have no WHERE clause.
Create fulltext indexes on the post table
Replace the search.php with the fulltext version
Change the search templates to reflect the new syntax.
Truncate the word and searchindex tables... yayy!

If you don't want or need the InnoDB tables, it's even easier. Or you may want to convert only the tables that would benefit most from InnoDB. These are THREAD, USER and SESSION.

You should be aware that switching to fulltext will not save disk space. The indexes will be big. The biggest benefit is managability and flexibilty of searches. For example, you can allow 2 letter searches with minimal impact on size and performance and also search for phrases.

Some searches will be faster than the serchindex method, but others will be slower. It all depends on the number/length of the words in the search phrase.

You should also note that non-boolean fulltext searches are only suitable for large post tables. It needs a lot of posts to figure out relevency. Boolean searches work well with any size table.

[nuno]

Originally posted by fastforward
It's pretty simple and I'll be happy to provide instructions.

The trouble is that the search.php really needs to be replaced. Jelsoft would probably get upset if I posted the entire file. If somebody wants to get the approval for me, I'll release it. :)

Basically, the changes I made are:

Convert all tables except post, to InnoDB. (This includes session)
Apply a hack to maintain user, post and thread counts. This simply involves creating a table and making a few changes in index.php. The only count(*)'s we have to worry about are ones that have no WHERE clause.
Create fulltext indexes on the post table
Replace the search.php with the fulltext version
Change the search templates to reflect the new syntax.
Truncate the word and searchindex tables... yayy!

If you don't want or need the InnoDB tables, it's even easier. Or you may want to convert only the tables that would benefit most from InnoDB. These are THREAD, USER and SESSION.

You should be aware that switching to fulltext will not save disk space. The indexes will be big. The biggest benefit is managability and flexibilty of searches. For example, you can allow 2 letter searches with minimal impact on size and performance and also search for phrases.

Some searches will be faster than the serchindex method, but others will be slower. It all depends on the number/length of the words in the search phrase.

You should also note that non-boolean fulltext searches are only suitable for large post tables. It needs a lot of posts to figure out relevency. Boolean searches work well with any size table.
This is very valuable info Paul, thanks for sharing it with us. :)

[Overgrow]

>>Truncate the word and searchindex tables... yayy!

I don't think I've ever had more joy running a mySQL command than when I dropped the searchindex table.




ps. a mod might want to split these posts off to a new thread as this has nothing to do with users not being able to logout (which btw works beautifully now!)

[nuno]

Originally posted by Overgrow

ps. a mod might want to split these posts off to a new thread as this has nothing to do with users not being able to logout (which btw works beautifully now!)

LOL :D
Yeah, can a mod move this thread to the Server Config or MySQL forum?
TIA :)

[KrON]

LOL :D
Yeah, can a mod move this thread to the Server Config or MySQL forum?
TIA :)

So.. is vbulletin okay with the release of the "full version" of the search.php? If its more or less a total rewrite except for snippets, is it a big deal?

[KrON]

So.. is vbulletin okay with the release of the "full version" of the search.php? If its more or less a total rewrite except for snippets, is it a big deal?

Hmm, also can you elaborate further on the thing about the count(*) hack on the post, thread and user tables? Does innodb not allow you to do count(*) on it? If thats just a hack, and not a major replacement, can you provide us with that, even if you can't give out the search.php?

I'd like to get most everything switched over to innodb, and functional, even if it means that i don't benefit from the full text search..

[Overgrow]

The search.php isn't mine so I can't answer that.

Count(*) on whole tables is kind of slow with InnoDB.. so instead of letting the index count them each time, it's more efficient to put those queries in an external file and cron it every once in a while. Mine goes every 5 minutes. I have it doing some other caching things too, but here are the essential parts:

[nuno]

*bump*
Update: http://www.vbulletin.org/forum/showthread.php?s=&threadid=51716 :)