New field type for profile: taxonomy
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | profile.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
A new type of field in the profile: taxonomy, useful for a field to select zero or more terms from a vocabulary. This works like the type "selection" but multiple selection is possible, and the list of choices comes from a taxonomy. Unfortunately there is no field in the table profile_fields to store single/multiple selection - which would be nice for the type "selection", too.
The selection is stored in a new table (profile_values_term) additionally to the column profile_values.value. This allows for easy processing of the selection the user made. I have not defined any indexes on this new table, which possibly would be required for large data sets.
It has a small bug: when nothing is selected, it will automatically select the first entry. The fix would probably have to modify _taxonomy_term_select in taxonomy.module.
| Attachment | Size |
|---|---|
| profile-taxonomy.patch | 3.87 KB |
#1
please set issues to patch once they have been tested. the patch queue is not a place for changes which have known bugs. thanks.
#2
ok thanks for the hint ;) my third post...
#3
Updated patch with the following fixes:
I don't see any bugs left at the moment.
#4
+1 Works for me.
#5
From the patch I noticed some issues:
(1) When viewing a users profile, the profile_view_field() function does not support 'taxonomy' $field->type so nothing is displayed on the ?q=user/2 page.
(2) When editing a users profile which has a taxonomy field, the term selection is always showing as a scrollable HTML select list. This happens even if the vocabulary is not set to 'multiple select'. A scrollable list takes up much more page space than a drop down select menu so i think it should be changed to operate based on the vocabulary setting. This can be achieved with taxonomy_form() rather than going directly to _taxonomy_term_select(()
(3) There is no suport for browsing profile's by clicking on the taxonomy. profile_browse() needs to support the $field->type 'taxonomy' still.
(4) More generally I also noticed that profile.module 4.6.3 and HEAD both uses same hacked up query building rather than passing everything through as printf() style parameters.
I've fixed all of the above in my profile.module now. I'll compile a patch against HEAD soon and submt it.
#6
Attached is my patch against profile.module in HEAD as of today (14/09/2005).
As I have developed the changes against a live 4.6.3 website I've not got any way to test the changes against a Drupal HEAD install.
The patch includes all code changes originally submitted by wiz. However it doesn't include the changes/additions to the database definition files (they can be found in http://drupal.org/files/issues/profile-taxonomy-2.patch).
First patch against Drupal core code. Hopefully it wont be too shabby.
#7
Added code to profile_save_profile() to save selected taxonomy terms in to the additional db table 'profile_values_term'. The data stored in this table is not actually used by the profile.module - it keeps a duplicate of the data as a serialized array in the profile_values.value field.
This was in the original patch by wiz, but didn't work correctly and i missed it out from the patch yesterday.
#8
I expanded the functionality to work with vocabularies that allow multiple selects. This makes use of the new dbase table which was specified in the original patch by Wiz.
The code to build the correct profile query is now getting a little more varied, as the taxonomy performs a JOIN on a new table. Feel free to suggest a better way to implement the query building.
I'm not currently working with Drupal HEAD so cannot produce the very latest changes against profile.module in HEAD. The changes to the patch in my previous comment are as follows:
// Determine what query to use:
$fid = 'WHERE v.fid = $field->fid';
$qsql = 'AND v.value =';
switch ($field->type) {
case 'checkbox':
$query = '1';
break;
case 'selection':
$query = db_escape_string($value);
break;
case 'list':
$qsql = 'AND v.value LIKE';
$query = "%%". db_escape_string($value) ."%%";
break;
case 'taxonomy':
$fid = 'AND v.fid = t.fid';
$qsql = sprintf('INNER JOIN profile_values_term t ON u.uid = t.uid WHERE t.fid = %d AND t.tid = ', $field->fid);
$terms = taxonomy_get_term_by_name($value);
$query = $terms[0]->tid;
break;
default:
drupal_not_found();
return;
}
// Extract the affected users:
$result = pager_query("SELECT u.uid FROM {users} u INNER JOIN {profile_values} v ON u.uid = v.uid %s %s '%s' ORDER BY u.changed DESC", 20, 0, NULL, $fid, $qsql, $query);
#9
do you have a current patch against 4.6.3 I'm working down the same road at the moment...
#10
You can find a working 4.6.x module with this patch (and search patch) applied from http://www.ixis.co.uk/drupal-modules/profile
#11
patches must be against HEAD in order to enter the patch queue.
#12
Rewritten patch against HEAD for profile.module attached.
I've made a couple of changes to the way it's implemented from budda's last version, but I think I've covered all the same functionality.
For changes/additions to the database definition files please use Wiz's earlier patch http://drupal.org/files/issues/profile-taxonomy-2.patch).
#13
Anyone updated these patches for 4.7?
#14
I just upgraded to 4.7, and i'm interested in a patch for this profile module as well. I'm using two custom taxonomy fields in my user profiles.
#15
no new features for 4.7
#16
- Use standard comment formatting (// unless it is function documentation).
- It looks like the new field may be serialized. No new serialized data should be added.
- It looks like a new table added, but the patchfile doesn't included changes for database.*sql and updates.inc.
#17
I have just got this to work with drupal 4.7, by manually editing profile.module.
I am wondering now: would it be possible to present the taxonomy terms selected as hyperlinks to the list of users that have selected the same term? Just like a freeform field does?
#18
would it be possible to have a patch of this working under 4.7.2?
thanks lot
#19
i would be interested in a 4.7.2 patch as well!
#20
Yes, this feature would be very practical for 4.7.2+.
Seems to deserve to become part of the core distribution of the profile module. Important feature.
#21
Lovehate.module, sponsored by lullabot, offers something like that for 4.7. Worth checking out.
#22
Attached is my attempt to create a 4.7.2. patch, needs review.
#23
No new feature will be added to 4.7.x
moving to cvs.
#24
Patches don't seem to have the right paths... Are they from before modules got their own folders?
Needs rerolling at the very least....
#25
Missed the feature freeze again... moving to D7.
#26
fyi - some related information in the following issue, which I just marked as a duplicate of this one:
(assuming that THIS issue is the most practical to move onwards)
"Profile module should use existing taxonomy functions to extend the user profile"
http://drupal.org/node/29259
BTW: how much work is it for a coder to place this functionality in a small contributed module until it has been included in core?
As far as I can see, we only need a way to look up values in a vocabulary and store their TIDs in a normal profile number field.
Related threads: (others asking for this)
Taxonomy Tags/Categories field type in User Profile
http://drupal.org/node/154198
Tagging profiles with Taxonomy Fields?
http://drupal.org/node/163012
Taxonomy verses free-form list in profiles
http://drupal.org/node/275374
#27
Making this a module would be so very cool. If it happens I do hope it supports D5.
#28
Isn't the real problem here that the profile module isn't extensible? Shouldn't there be some hook that allows you to add new kinds of fields?
But then again, it might be smarter to wait until "Fields in core" is a reality (especially because Taxonomy is likely to be rewritten as a CCK field?), in which a full rewrite of the profile module would be smarter. However, will CCK fields be able to relate to anything else than a node?
Just thinking aloud, because I'm not sure it'd be smart to put much effort in this if it's going to be redone anyway.
#29
I think the perspectives in practise suggest a temporary solution, as this whole process may take 1-2 years, for core plus all related modules to update and be adjusted (and the sites to be upgraded to use the new system, etc.)...
Even if I may be somewhat wrong about that time frame, many sites would benefit from a simple temporary solution, even if that may mean that they will have an extra concern later as the new system might not support upgrading that field in a manner that retains the taxonomy lookup function.
I have not studied the existing code, but my guess is that we have most of what is needed for such a small contributed module already, and it is only a matter of piecing it together maybe as a minimodule?
Are there (many?) others reading this who disagree with my guess that this would be sufficient as a temporary solution?
Where is the best place to continue discussing a temporary module for this?
#30
Temporary solutions for the general issue of not being able to attach different types of fields to profile.module are the various 'profile as node' solutions - bio, nodeprofile (and content_profile in D6), along with advanced_profile module.
I'd rather see efforts put on fields in core and a rewrite of profile.module for D7 using that, rather than tacking new stuff onto what's already there, so tentatively marking postponed.
#31
I agree with catch.
DanielTheViking: this won't get into Drupal 5 or 6: new features only go into new Drupal versions. And "fields in core" *will* happen for Drupal 7, so your duration statement is a non-issue :)
#32
Needed this for a site, so updated this patch to Drupal 5.9 (simplified and cleaned up somewhat - use form_alter if you need to modify the form style!)
#33
Patch for Drupal 6.2
#34
I can confirm that the patch in #32 works perfectly for Drupal 5.10.