The Elgg Community: Custom Profile Fields
By bthjcommunity.elgg.org - Kevin says: @Sim2K - one of my clients has just approved the funding necessary to add registration form support to the form and related plugin family. So that should be out in September. I see Jeroen's plugin as a quick option for people needing...
- bthj commented on a bookmark Redirect to profile with htaccess
- bthj bookmarked Redirect to profile with htaccess
A plugin for elgg that offers this functionality would be nice, something like Pretty Link for Wordpress.
- bthj joined the group Plugin Development
- bthj added a new discussion topic Group bookmarks visible at group's start page - widget? in the group Elgg Technical Support
- bthj joined the group Elgg Technical Support
- bthj replied on the discussion topic Tags with non-ascii (international) characters don't work after upgrade to version 1.6 in the group Elgg Technical Support
@Kevin
MySQL should do this all by default
No... MySQL can do it, but not should or must. Just because MYSQL-UTF8 server is overhead of "less than other configs" usable selection:
* In "Pax English" - customer will not see any differences in site functionality with any defined or even without
[mysql]
...
default-character-set=utf8[mysqld]
...
default-character-set=utf8* in some countries usage of UTF8 in web-app is new and only fashion, and most of (bilingual) hosting-clients are happy with "default historical encoding" and hosters are well informed about this situation
In short - we cannot require the presence of correct (from our point of view) settings and even we do not have a possibility to expect their presence - we must create this environment
2Brett: You can disagee freely with everybody and anybody, sure, but... Modern browsers+DB+PHP have less of nothing problems in this area. Mbstring P)HP-extension isn't a big problem also - you can just extent current Prereq. list with "Mbsting must be supported in PHP" line or, as it was done in Dokuwiki: have UTF-aware functions, which work with or without mbstring (inc\utf8.php)
/**
* UTF8 helper functions
*
* @license LGPL (http://www.gnu.org/copyleft/lesser.html)
* @author Andreas Gohr <andi@splitbrain.org>
*/MySQL defaults are not completely worthwhile for non-English alphabets
Pls, RTFM :-), namely
- set names
- set character_set_client
- set character_set_results
- set collation_connection
This way I can handle and fight (more or less succesfull) not only with badly (from my POV) configured hoster's MYSQL, but in some form even with badly created tables and their content. At least I know Elgg (polished) installation, which work on russian hosters servers with Win-1251 MySQL default encoding without problems for russian UTF8-texts
@Alexander -
"MySQL defaults are not completely worthwhile for non-English alphabets
Pls, RTFM :-), namely
- set names
- set character_set_client
- set character_set_results
- set collation_connection"
You've misunderstood what I'm saying. I know of these functions, but the default settings for MySQL are independent of these options--these options change those defaults.
Regardless, if you could post any patches to trac relating to encoding it would help this along...
A solution is in SVN at http://code.elgg.org/elgg/releases/core/elgg1.6.2 This will be released as soon as I can get some feedback from users that this 1) fixes UTF8 issues and 2) fixes data path storage issues.
Note: Please run this on a test site! If you've manually changed core or your database settings this will probably break the UTF8 strings.
- bthj replied on the discussion topic Tags with non-ascii (international) characters don't work after upgrade to version 1.6 in the group Elgg Technical Support
@Kevin
MySQL should do this all by default
No... MySQL can do it, but not should or must. Just because MYSQL-UTF8 server is overhead of "less than other configs" usable selection:
* In "Pax English" - customer will not see any differences in site functionality with any defined or even without
[mysql]
...
default-character-set=utf8[mysqld]
...
default-character-set=utf8* in some countries usage of UTF8 in web-app is new and only fashion, and most of (bilingual) hosting-clients are happy with "default historical encoding" and hosters are well informed about this situation
In short - we cannot require the presence of correct (from our point of view) settings and even we do not have a possibility to expect their presence - we must create this environment
2Brett: You can disagee freely with everybody and anybody, sure, but... Modern browsers+DB+PHP have less of nothing problems in this area. Mbstring P)HP-extension isn't a big problem also - you can just extent current Prereq. list with "Mbsting must be supported in PHP" line or, as it was done in Dokuwiki: have UTF-aware functions, which work with or without mbstring (inc\utf8.php)
/**
* UTF8 helper functions
*
* @license LGPL (http://www.gnu.org/copyleft/lesser.html)
* @author Andreas Gohr <andi@splitbrain.org>
*/MySQL defaults are not completely worthwhile for non-English alphabets
Pls, RTFM :-), namely
- set names
- set character_set_client
- set character_set_results
- set collation_connection
This way I can handle and fight (more or less succesfull) not only with badly (from my POV) configured hoster's MYSQL, but in some form even with badly created tables and their content. At least I know Elgg (polished) installation, which work on russian hosters servers with Win-1251 MySQL default encoding without problems for russian UTF8-texts
@Alexander -
"MySQL defaults are not completely worthwhile for non-English alphabets
Pls, RTFM :-), namely
- set names
- set character_set_client
- set character_set_results
- set collation_connection"
You've misunderstood what I'm saying. I know of these functions, but the default settings for MySQL are independent of these options--these options change those defaults.
Regardless, if you could post any patches to trac relating to encoding it would help this along...
A solution is in SVN at http://code.elgg.org/elgg/releases/core/elgg1.6.2 This will be released as soon as I can get some feedback from users that this 1) fixes UTF8 issues and 2) fixes data path storage issues.
Note: Please run this on a test site! If you've manually changed core or your database settings this will probably break the UTF8 strings.
- bthj replied on the discussion topic Tags with non-ascii (international) characters don't work after upgrade to version 1.6 in the group Elgg Technical Support
@Kevin
MySQL should do this all by default
No... MySQL can do it, but not should or must. Just because MYSQL-UTF8 server is overhead of "less than other configs" usable selection:
* In "Pax English" - customer will not see any differences in site functionality with any defined or even without
[mysql]
...
default-character-set=utf8[mysqld]
...
default-character-set=utf8* in some countries usage of UTF8 in web-app is new and only fashion, and most of (bilingual) hosting-clients are happy with "default historical encoding" and hosters are well informed about this situation
In short - we cannot require the presence of correct (from our point of view) settings and even we do not have a possibility to expect their presence - we must create this environment
2Brett: You can disagee freely with everybody and anybody, sure, but... Modern browsers+DB+PHP have less of nothing problems in this area. Mbstring P)HP-extension isn't a big problem also - you can just extent current Prereq. list with "Mbsting must be supported in PHP" line or, as it was done in Dokuwiki: have UTF-aware functions, which work with or without mbstring (inc\utf8.php)
/**
* UTF8 helper functions
*
* @license LGPL (http://www.gnu.org/copyleft/lesser.html)
* @author Andreas Gohr <andi@splitbrain.org>
*/MySQL defaults are not completely worthwhile for non-English alphabets
Pls, RTFM :-), namely
- set names
- set character_set_client
- set character_set_results
- set collation_connection
This way I can handle and fight (more or less succesfull) not only with badly (from my POV) configured hoster's MYSQL, but in some form even with badly created tables and their content. At least I know Elgg (polished) installation, which work on russian hosters servers with Win-1251 MySQL default encoding without problems for russian UTF8-texts
@Alexander -
"MySQL defaults are not completely worthwhile for non-English alphabets
Pls, RTFM :-), namely
- set names
- set character_set_client
- set character_set_results
- set collation_connection"
You've misunderstood what I'm saying. I know of these functions, but the default settings for MySQL are independent of these options--these options change those defaults.
Regardless, if you could post any patches to trac relating to encoding it would help this along...
A solution is in SVN at http://code.elgg.org/elgg/releases/core/elgg1.6.2 This will be released as soon as I can get some feedback from users that this 1) fixes UTF8 issues and 2) fixes data path storage issues.
Note: Please run this on a test site! If you've manually changed core or your database settings this will probably break the UTF8 strings.
- bthj replied on the discussion topic Tags with non-ascii (international) characters don't work after upgrade to version 1.6 in the group Elgg Technical Support
@Kevin
MySQL should do this all by default
No... MySQL can do it, but not should or must. Just because MYSQL-UTF8 server is overhead of "less than other configs" usable selection:
* In "Pax English" - customer will not see any differences in site functionality with any defined or even without
[mysql]
...
default-character-set=utf8[mysqld]
...
default-character-set=utf8* in some countries usage of UTF8 in web-app is new and only fashion, and most of (bilingual) hosting-clients are happy with "default historical encoding" and hosters are well informed about this situation
In short - we cannot require the presence of correct (from our point of view) settings and even we do not have a possibility to expect their presence - we must create this environment
2Brett: You can disagee freely with everybody and anybody, sure, but... Modern browsers+DB+PHP have less of nothing problems in this area. Mbstring P)HP-extension isn't a big problem also - you can just extent current Prereq. list with "Mbsting must be supported in PHP" line or, as it was done in Dokuwiki: have UTF-aware functions, which work with or without mbstring (inc\utf8.php)
/**
* UTF8 helper functions
*
* @license LGPL (http://www.gnu.org/copyleft/lesser.html)
* @author Andreas Gohr <andi@splitbrain.org>
*/MySQL defaults are not completely worthwhile for non-English alphabets
Pls, RTFM :-), namely
- set names
- set character_set_client
- set character_set_results
- set collation_connection
This way I can handle and fight (more or less succesfull) not only with badly (from my POV) configured hoster's MYSQL, but in some form even with badly created tables and their content. At least I know Elgg (polished) installation, which work on russian hosters servers with Win-1251 MySQL default encoding without problems for russian UTF8-texts
@Alexander -
"MySQL defaults are not completely worthwhile for non-English alphabets
Pls, RTFM :-), namely
- set names
- set character_set_client
- set character_set_results
- set collation_connection"
You've misunderstood what I'm saying. I know of these functions, but the default settings for MySQL are independent of these options--these options change those defaults.
Regardless, if you could post any patches to trac relating to encoding it would help this along...
A solution is in SVN at http://code.elgg.org/elgg/releases/core/elgg1.6.2 This will be released as soon as I can get some feedback from users that this 1) fixes UTF8 issues and 2) fixes data path storage issues.
Note: Please run this on a test site! If you've manually changed core or your database settings this will probably break the UTF8 strings.
- bthj replied on the discussion topic registration form support in the group Form and related plugins
Another addition will be hooks for validation functions throughout the form plugin. As validation can be complex, I doubt that there will be a UI for specifying validation but there will a clear example of how to add validation functions to the different field types.
So a function might be:
function validate_aboutme(value) {
if (strlen(value) < 20) {
return false;
} else {
return true;
}
}
You could add that as a trivial plugin.
That would be great, to have an example (plugin) to base a custom validation on : )
- bthj has updated their profile
Another addition will be hooks for validation functions throughout the form plugin. As validation can be complex, I doubt that there will be a UI for specifying validation but there will a clear example of how to add validation functions to the different field types.
So a function might be:
function validate_aboutme(value) {
if (strlen(value) < 20) {
return false;
} else {
return true;
}
}
You could add that as a trivial plugin.
That would be great, to have an example (plugin) to base a custom validation on : )
- bthj joined the group Form and related plugins
- bthj bookmarked The Elgg Community: Custom Profile Fields