1
irmtfan
Profile Module (Was: xlanguage will not work with profiles)
  • 2013/1/11 3:21

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Quote:

it is pretty surprising that nobody has found it earlier.

i was noticed that a long time ago but i was sure it is not a bug but an intentional change by the "profile module" Author.
Still im sure it is not a bug.

As you can see the title of user profile core fields (_users table) is changeable and editable in profile module.
It means for example i have "ICQ" in the installation but i have the chance to change it to "Your Cell Number". I consider it as a feature.

Quote:

Seems profile should be saving the constant keys instead of the translations

Now It can accept constant keys too and it would be very easy. eg: change "ICQ" by "_US_ICQ"

So Mamba and Trabis:
If you think an editable title of core field in the current profile module is in conflict with constants inside language/LANG/user.php then we can consider it as a long long bug in front of everyone eyes.

Then you have only 1 way
- should make those titles not editable. and just make " brand new fields" editable.

honestly this profile module is completely different from all other xoops modules because with this module we change/edit/add/delete fields in database.
It seems we should think about some ways to make these fields in related to each other and also could be accessible and readable by other modules. eg: when i build a "Gender field" ( which is vital for my websites" i need to show it in other modules like "newbb", "news", ...
when i said this module needs a complete rewrite i meant to think about all the ways that make it a powerful module.

@kroewing:

As i said this is not a bug and you can solve your issue by editing those fields one by one and change the title.
you have 2 way:

1- change the titles with language contant located in language/LANG/user.php

eg: "Extra Info" with "_US_EXTRAINFO"

2- change the titles with your own desired bilingual writing like this:

eg: in english/persian "Extra Info" with [en]Other information[/en][fa]اطلاعات اضافی[/fa]

2
irmtfan
Profile Module (Was: xlanguage will not work with profiles)
  • 2013/1/11 4:51

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


@Mamba:
I take a look and as Trabis said it was easy fix.(If we consider it a bug)
open profile/include/install.php and find all profile_install_addField
and add a quotation mark. eg '_US_RANK' instead of _US_RANK
at least it will affect new installations.
profile_install_addField('name''_US_REALNAME'''1'textbox'111, array(), 2255);
    
profile_install_addField('user_from''_US_LOCATION'''1'textbox'121, array(), 2255);
    
profile_install_addField('timezone_offset''_US_TIMEZONE'''1'timezone'131, array(), 20);
    
profile_install_addField('user_occ''_US_OCCUPATION'''1'textbox'141, array(), 2255);
    
profile_install_addField('user_intrest''_US_INTEREST'''1'textbox'151, array(), 2255);
    
profile_install_addField('bio''_US_EXTRAINFO'''1'textarea'261, array(), 20);
    
profile_install_addField('user_regdate''_US_MEMBERSINCE'''1'datetime'370, array(), 010);

    
profile_install_addField('user_icq''_US_ICQ'''2'textbox'111, array(), 2255);
    
profile_install_addField('user_aim''_US_AIM'''2'textbox'121, array(), 2255);
    
profile_install_addField('user_yim''_US_YIM'''2'textbox'131, array(), 2255);
    
profile_install_addField('user_msnm''_US_MSNM'''2'textbox'141, array(), 2255);

    
profile_install_addField('user_viewemail''_US_ALLOWVIEWEMAIL'''3'yesno'311, array(), 21false);
    
profile_install_addField('attachsig''_US_SHOWSIG'''3'yesno'321, array(), 01false);
    
profile_install_addField('user_mailok''_US_MAILOK'''3'yesno'331, array(), 21false);
    
profile_install_addField('theme''_PROFILE_MA_THEME'''3'theme'141, array(), 00false);
    
profile_install_addField('umode''_US_CDISPLAYMODE'''3'select'151$umode_options00false);
    
profile_install_addField('uorder''_US_CSORTORDER'''3'select'361$uorder_options00false);
    
profile_install_addField('notify_mode''_NOT_NOTIFYMODE'''3'select'371$notify_mode_options00false);
    
profile_install_addField('notify_method''_NOT_NOTIFYMETHOD'''3'select'381$notify_method_options00false);

    
profile_install_addField('url''_PROFILE_MI_URL_TITLE'''4'textbox'111, array(), 2255);
    
profile_install_addField('posts''_US_POSTS'''4'textbox'320, array(), 0255);
    
profile_install_addField('rank''_US_RANK'''4'rank'332, array(), 00);
    
profile_install_addField('last_login''_US_LASTLOGIN'''4'datetime'340, array(), 010);
    
profile_install_addField('user_sig''_US_SIGNATURE'''4'textarea'151, array(), 00);


But i still think it is not good because a 1 language user will see strange and weird constants instead of real titles in his own language.

IMO the better way is to remove edit title feature as i said before. so nobody can see and change them.

3
Mamba
Re: xlanguage will not work with profiles
  • 2013/1/11 11:17

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Quote:
But i still think it is not good because a 1 language user will see strange and weird constants instead of real titles in his own language.

Yes, that wouldn't be good!

So we need to find a solution that guarantees that the language will be changed with xLanguage, and fields can be edited, when needed.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

4
trabis
Re: xlanguage will not work with profiles
  • 2013/1/11 13:40

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

irmtfan wrote:

But i still think it is not good because a 1 language user will see strange and weird constants instead of real titles in his own language.

IMO the better way is to remove edit title feature as i said before. so nobody can see and change them.


You can use constant('_US_OCCUPATION') to display the translation and not "strange and weird constants". We can also look to see if a given field is holding a constant or not when displaying in the front side, but...

I did not realized that fields were editable so now I think there is no bug. The developer is excused! Creating different routine to solve the legacy fields is not good solution because it does not fix the custom fields.
Since we are talking about xlanguage, the best approach would be to use xlanguage tags in the fields titles as irmtfan proposes.

5
irmtfan
Re: xlanguage will not work with profiles
  • 2013/1/12 6:23

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


the issue in this profile module is it copied some of the core fields (located in _users table) to a profile table (_profile_field table) and work on them on an isolated and abandoned area.
I mean in this profile module fields can not be in relation with each other and also all fields just are accessible in profile module itself and not any other module. Other modules read user data only from _users table and not profile module. even profile module itself read the data from _users table. IMO it is the main issue.
In an idealistic profile module:
1- all other modules should read all users data from profile module and should find the newly added fields too.
2- Also fields should be in some kind of relation to each other. i mean some functions will happen based on the changes of fields.
example:
I want to change group based on the number of posts.
after registration users are belong to "registered users " group but when the "posts" for uid=1 reach to 1000 it will assigned to "super users" group automatically.

example 2:
i create a custom field named "age" have 2 values "under 18" and "above 18". then i make it required in registration page. i want to dont allow users select "under 18" to register. ( Or i want to assign them to "limited users" group)

we can have many opportunities.

I think now the core 2.6.0 have 2 content module (page as simple module and publisher as a professional one) so it is the time for an advance, powerful and full functional profile module. It is the most important module to work on by the core team.

6
trabis
Re: xlanguage will not work with profiles
  • 2013/1/12 14:43

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


@irmtfan,
Perhaps we should make profile a required module and not uninstallable (like system module). All other modules should use the profile api to get user data.
On upgrade, users table would be renamed to profile_profile and all none required fields would become editable/removable. For unremovable fields we can look at facebook and many other sites:

Facebook: firstname, lastname, email, password, birthdate and gender
Linkedin: firstname, lastname, email, password
hi5: firstname, lastname, email, password, country, city, language, birthdate, gender
Myspace: firstname, lastname, email, password, birthdate, gender, others
Tumblr : username, email, password
Twitter: fullname, email, password
Delicious: Displayname, username, email, password
Stackexchange: email, password, displayname(optional)
reddit: username, email, password

This way we could remove duplicate code for registration/login/user activity/avatar upload and have a unique api for profiles.

7
irmtfan
Re: xlanguage will not work with profiles
  • 2013/1/13 5:47

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


good i was thinking about these too.
Quote:

All other modules should use the profile api to get user data.

Yes i also think we should drop the legacy fields.
but you know some of those fields are unique and are used widely in core/modules.
eg: posts, theme, umode, uorder
so the new profile module should care about them too. is that possible to make other modules be aware of these unique fields?
some fields are useless now. eg:user_msnm, user_icq are dead.

IMO only uname, email and pass are vital for a website that dont need any profile system.

hope i could help more.



8
trabis
Re: xlanguage will not work with profiles
  • 2013/1/13 12:35

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Quote:

irmtfan wrote:
Yes i also think we should drop the legacy fields.
but you know some of those fields are unique and are used widely in core/modules.
eg: posts, theme, umode, uorder
so the new profile module should care about them too. is that possible to make other modules be aware of these unique fields?
some fields are useless now. eg:user_msnm, user_icq are dead.

There is already a userconfigs module in 2.6.0 that will be used to hold configs by user. For example, the comments module will be using userconfigs table instead of user table. All configs that are not supposed to be displayed on profile pages (no visibility/ no permissions) can be moved into userconfigs (theme, receive emails, show email, etc)

I think 'posts' could be managed by other module, perhaps a refactored 'mypoints' could do it.

9
irmtfan
Profile Module (Was: xlanguage will not work with profiles)
  • 2013/1/14 6:48

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


Quote:

All configs that are not supposed to be displayed on profile pages (no visibility/ no permissions) can be moved into userconfigs (theme, receive emails, show email, etc)


It is very good approach.
So we deal with legacy fields one by one. It means we think about the right place for each field in the future.
here is my proposal include some features that i saw in sourceforge tracker.

fields moved to profile module:
- uid: not editable/unremovable
- uname: not editable/unremovable - requested featuires: varchar(25) is not enough at all . It should be changed to varchar(60). ability to have spaces(spaces between words. should be aware of bad spaces)
- email: not editable/unremovable - ability to login with email (a very very long wish - just needs 2 lines of codes)
- pass: not editable/unremovable
- name: editable/unremovable - better to be unremovable becuase it is widely used in core and modules
- url: editable/removable
- user_avatar: editable/removable
- user_from: editable/removable
- user_sig: editable/removable - tinytext is not enough - should be changed to text
- user_occ: editable/removable
- bio: editable/removable - tinytext is not enough - should be changed to text
- user_intrest: editable/removable
- user_icq: editable/removable - drop or not? keep just for legacy purposes?
- user_aim: editable/removable - drop or not? keep just for legacy purposes?
- user_yim: editable/removable - huum even drop?
- user_msnm: editable/removable - drop or not? keep just for legacy purposes?

fields moved to logger module
- user_regdate
- actkey: logger or profile?
- last_login: therte is a long wish for a login history and not only last login. easily can be implemented in logger module.

fields moved to userconfigs module:
- user_viewemail
- attachsig
- theme
- timezone_offset: userconfigs or profile module? nobody need to be known my timezone?
- umode: flat, nested, threaded. I wish to also see hybrid=(flat+threaded) it is in Vbullletin
- uorder: ASC or DESC
- user_mailok

fields moved to mypoints module:
- posts
- level
Previously i think we must have a Like module too. just the same as FB Like. It can also have "dislike" in addition to like/unlike features.
Now i think it can be in mypoints? or we still need a separate like module.

fields moved to userrank module:
- rank: features:ability to have more than 1 rank per user. also text ranks

fields moved to notifications module:
- notify_method
- notify_mode


@forum moderators:
This topic goes off-topic already. please create a new topic (name: proposals for a new profile module in 2.6) and moved all posts after number 14 or 15

10
sabahan
Re: Profile Module (Was: xlanguage will not work with profiles)
  • 2013/1/21 14:29

  • sabahan

  • Quite a regular

  • Posts: 317

  • Since: 2006/3/4 5


Quote:

irmtfan wrote:
[quote]

@forum moderators:
This topic goes off-topic already. please create a new topic (name: proposals for a new profile module in 2.6) and moved all posts after number 14 or 15



moderators ?

topic name maybe should be change to "proposals for a new profile module in 2.6" like suggested by irmtfan


Login

Who's Online

158 user(s) are online (100 user(s) are browsing Support Forums)


Members: 0


Guests: 158


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits