max length of username hardcoded on reg form

Logged In: YES
user_id=841117

OK, I'll take care of this one personally.

Logged In: YES
user_id=882380

I changed this. At the same time I corrected several
inconsistencies in some user-interface elements also (the
uname was hardcoded to 10 or 12 sometimes). Sent to 2.0.7
branch.

See note from Irmtfan:
http://xoops.org/modules/newbb/viewtopic.php?post_id=346883#forumpost346883

I think the registration process is ok now and at least these 2 lines should be corrected and the limited characters should be move to the configuration of profile module in xoops 2.6

in kernel/users.php line 61 and 62

    $this->initVar('uname', XOBJ_DTYPE_TXTBOX, null, true, 25);
    $this->initVar('email', XOBJ_DTYPE_TXTBOX, null, true, 60);

maybe also this line need attention (i dont know):

in modules\system\admin\users\users.php(125):
$form->addElement(new XoopsFormText(_AM_SYSTEM_USERS_NICKNAME, "username", 25, 25, $uname_value), true);

this code will solve the lost code in modules\system\admin\users\users.php(125)

$config_handler =& xoops_gethandler('config');
$maxuname = $config_handler->getconfig("maxuname");
$uname_size = $maxuname < 25 ? $maxuname : 25;
$form->addElement(new XoopsFormText(_AM_SYSTEM_USERS_NICKNAME, "username", $uname_size, $uname_size, $uname_value), true);

I think one of the reasons this issue has remained unsolved for so many years is that it has no simple solution. The current XOOPS codebase inherits a number of complications from its long history. There are several multi-byte stumbling blocks that keep XOOPS from providing proper support. Let me explain what I see.

First, multi-byte support in PHP is more of an artifact than a feature. PHP 6 was supposed to come along and fix a lot of things with standard UTF-8 support, but it isn't even on the radar any more. Adding Iconv as a standard feature was a good thing, but not nearly a solution. The mbstring extension is a huge step in the right direction, but it is still an optional feature. The lack of it means that PHP's basic character concept is a single 8 bit byte. UTF-8 strings can be passed through, but not really treated as characters.

Then there is MySQL, which if you are using a reasonably recent version does understand characters can potentially be composed of multiple bytes. But, for what it calls UTF-8 it only recognizes up to 3 byte forms, and a different encoding is required to use 4 byte forms, but the basics are there. It still has a bunch of potential issues. The server has a encoding, the connection has a encoding, a database has an encoding, tables have an encoding and even columns can have an encoding. If these all agree to use UTF-8 things are good -- at least to 3 bytes, sorry China :( -- but if they don't, strange and stupid things can happen.

Then there is the web server. Even if your page says it uses UTF-8, the headers can specify something else, and strange and stupid things happen.

A large part of the problem is that as XOOPS grew, it tried to embrace a whole bunch of incompatible solutions, resulting in long lists of confusing options, settings and patches in strange places. It tried to be everything for everybody with lots of options. Standards have emerged as best practice, but we still generously offer contradictory solutions where we just hope for the best. More options just lead to more problems.

For the uname field, it is defined at the database level as varchar(25) which could be 25 bytes, or up to 100 bytes depending on server version, and the definitions across the chain and the string. The core XoopsUser object defines it as having maxlength of 25, that will at present be measured as 25 bytes with strlen(), unless the PHP mbstring.func_overload is enabled, (yet another variable in the problem.) It does need to be an indexed column, so it can't be made arbitrarily large. Simply allowing larger lengths to accommodate multi-byte strings without increasing the database size would create additional issues. Despite all the options, we don't have a way to ensure a consistent multi-byte character path, from browser to database and back.

If you play with 2.6.0, you might notice, a lot of those options are disappearing. We are adopting a strategy that could be stated simply as "Unicode all the way." UTF-8 is quite capable of representing the breadth of human written language, and using it consistently throughout the entire tool chain will prevent lots of issues, and allow us to move past strange and stupid incompatibilities. The final piece of the foundations for this change has been put in place with the integration of a new package from https://github.com/nicolas-grekas/Patchwork-UTF8 to enable consistent checking of input conformance to the declared headers, Unicode normalization and fallbacks for the most critical mbstring functions when we must run on a poorly configured server that lacks them. With this in place, we can take steps to make sure that when we say 25 characters, it really is real characters, not an ambiguous run of 25 8 bit bytes that might or might not be interpreted correctly.

There have been a series of refinements made to 2.6.0 all leading to this goal, and there will still be significant work involved in identifying and implementing changes to string functions through out the code. To complete the work we will still need to address the MySQL utf8 / utf8mb4 CHARACTER SET issues. None of the steps can be left out without leaving potential strange and stupid thing issues.

Trying to implement changes of this magnitude in 2.5.7 greatly exceeds the scope established for this minor release. It also would be impossible to pursue with our current manpower. We may able to make a small patch that will improve this issue for some cases, but there are too many problems requiring fundamental changes to fix all of them at this point.