UBB.threads PHP Forum Software Community Forums UBB.threads Bug Reports Fixed Bugs Shout box is hanging

I emptied the shout box by deleting the single messages by clicking on their individual close boxes.

When I try to "shout" now, a remark keeps telling me "Sending..." but nothing happens.

What browser are you using and what version of UBBT ?

I get this on here with IE7 but not with Firefox, the whole forum freezes. I have opted to hide the left column that contains the shoutbox and the problem has gone.

Note: I don't use the shoutbox on my own site.

Yes it has been semi-problematic for some reason with IE7 for some users. Others don't seem to have this issue. I seem to be able to run IE7 just fine on this site.

This site also runs many other sites and customized beta software as well, it's possible that the site was just slow for a few minutes when you noticed it.

.

I'm using IE6 and 7.1.beta4

When I open the forum and I'm not yet logged in, I see the shouts, even my own from the last session! After login, the shout-box is empty and a new posted shout is freezing with "Sending".

Problem found (and solved)

A special German character (Umlaut) was, once again, the cause.
In file /languages/german/portal_islands.php line 37 reads:

$ubbt_lang['DELETE_SHOUT'] = "Lösche Shout ID:";

Replacing "ö" with "oe" solved the problem. It seems that this is the text for a hint and this kind of text shouldn't contain special characters (or should be entered in a special way that I don't know).

Using special characters in other texts (e.g. window captions) doesn't seem to be a problem.

You should try using the ASCII varient of this character vs using it raw and it should function:

BTW, for anyone needs a decent ASCII map, I use this

This is a special case bacause the java function of the shout box. Using ASCII encoding dont work too in browser popup windows. The browser show the encoding itself.

All strings in Threads7 related to any kind of java coding should be without encodet chars or you run in trouble.

This is a point for a bigger review how to handle non-us chars. Actual I use 3 versions of one char in the language file according to the function where it is used to force the correct output. Plain, 'benannte Zeichen' and ascII encodet

interesting enough

I think in the end this is another reason why we might need to look at changing everything to UTF-8 encoding which will probably eliminate these types of problems.

I've been doing a bit of testing and haven't found any issues with doing so yet, but it definitely needs to be tested for awhile. Maybe something we can look at for the next release.

Would it be possible for the brave to change it prior to 7.2? I think it's what's causing some occasional errors on my site as well.

All I can say is you can try it Basically all you have to do is change the encoding in the generic.php language string.

Thats an bad idea on sites running non english chars. If you do it all previous entered special chars are displayd in wrong encoding. I have such a try while playing with language files on my old 6.5 board.

Would this be related?

https://www.ubbdev.com/forums/ubbthreads.php/ubb/showflat/Number/312791

I check my old V6.5 database and this runs in: latin1_swedish_ci
The new V7.0.2 runs in latin1_swedish_ci too. I dont have any utf formats in my database.