if not unicode then what!

I am trying to convert my utf-8 (alfa state)-site to be in iso-8859-2 for the following reasons:
- WebloginPE doesn’t accept special characters in username (my old phpBB forum in latin-2 does). In fact it stops with error, if it’s getting an unicode-ID which I made in the Manager.
- AjaxSearch doesn’t find words containing unicode chars. (this is my smallest issue)

Now that I’m testing my site with iso-8859-2 I get the followings:
- WebloginPE behaves the same with accent characters in username (after changing the name to 8859-2 in the Manager)
- AjaxSearch doesn’t stop searching any word (maybe for some different reason, but I do care it the less)
- A new case when trying to open an existing document to edit in NewsEditor (but it seems like the error is laying in the modx-core):
Error: htmlentities() [function.htmlentities]: charset `iso-8859-2’ not supported, assuming iso-8859-1
Error type/ Nr.: Warning - 2
File: /var/www/html/drago.hu/test/manager/includes/tmplvars.format.inc.php
Line: 329
Line 329 source: $o = htmlentities($value, ENT_NOQUOTES, $modx->config[’modx_charset’]);

"Erre varrjál gombot!" as we used to say in hungarian. (A good translation on this, anyone?)

Quote from: vhollo at Apr 22, 2008, 05:39 PM

"Erre varrjál gombot!" as we used to say in hungarian. (A good translation on this, anyone?)

"This way stitches buttons"? I’m sure that’s too literal, but perhaps someone can help clarify...

The unfortunate truth is that many essential PHP functions do support ISO-8859-2 and end up translating your content to ISO-8859-1 in many cases. You’re better off working with UTF-8 to avoid the expense of translating between charsets anyway, but in your case, there doesn’t appear to be much other choice.

"Stitch a button on this (if you can)!" the translation may be I think, but thanks for your response, Jason!
I did turn back to utf-8 immediately!

My scenario is that ’Users’ (webgroup) are handled by WebLogin/Websignup (login/register) - they may have accent chars in their usernames.
The ’Players’ and ’Coaches’ (webgroups) of our ice hockey team are handled by WebLoginPE (managed by ’Coaches’/’Admins’ on the frontend) and I can make sure they don’t have any accent chars in the username. I also use these "users" in certain listings sorted by fullname or age.

So my task is to let WebLoginPE not read any webusername with accents. The rest is filtered by WLPE’s &usersList.

My idea was that I make a copy of the variable ’$allUsers’ replaced any accented chars with none:
$badUsernames = str_replace($illegals, ’’, $allUsers); //$illegals is the array of accent chars
and then make
$allUsers = array_intersect($allUsers,$badUsernames);
which is leaving only the non-accented usernames in the array. This way WebloginPE should have done it’s job with sorting, because I know that no one ’Player’ or ’Coach’ will be dropped. (WebLoginPE lets me filter webusers by webgroup anyway.)

That’s for theory.
Unfortunately it turned out that $allUsers is not an array, so it is not acceptable as an argument in ’array_intersect’...

"Erre varrjál gombot!"

I know my idea was to be a specific workaround, not an ultimate one for the issue of WebLoginPE. But If anyone could serve a few lines of code that filters the wrong usernames from $allUsers I would be really happy (and it served my learning php).

$allUsers was generated this way in webloginpe.class.php:
global $modx;
$web_users = $modx->getFullTableName(’web_users’);
$fetchUsers = $modx->db->query("SELECT `username` FROM ".$web_users);
$allUsers = $this->FetchAll($fetchUsers)->unicodeText;

Thank you!
Sorry - a few typos and bad ideas...