New field type for profile: taxonomy

please set issues to patch once they have been tested. the patch queue is not a place for changes which have known bugs. thanks.

+1 Works for me.

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.

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.

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.

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);
 

do you have a current patch against 4.6.3 I'm working down the same road at the moment...

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

patches must be against HEAD in order to enter the patch queue.

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).

Anyone updated these patches for 4.7?

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.

no new features for 4.7

- 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.

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?

would it be possible to have a patch of this working under 4.7.2?

thanks lot

i would be interested in a 4.7.2 patch as well!

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.

Lovehate.module, sponsored by lullabot, offers something like that for 4.7. Worth checking out.

Attached is my attempt to create a 4.7.2. patch, needs review.

No new feature will be added to 4.7.x
moving to cvs.

Patches don't seem to have the right paths... Are they from before modules got their own folders?

Needs rerolling at the very least....

Missed the feature freeze again... moving to D7.

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

Making this a module would be so very cool. If it happens I do hope it supports D5.

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.

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?

This is what I think would be sufficient for now:
Pick descriptions + TID from taxonomy, and store the selected TID back into a number field in the existing profile system, and when displaying the value in such a field, the contributed module would make sure that it is the term "name" that is displayed in place of the TID.

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?

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.

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 :)

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!)

Patch for Drupal 6.2

I can confirm that the patch in #32 works perfectly for Drupal 5.10.

I'm going to test the 5.9 version of the patch. Thanks btw.

Confirming a successful application of this patch for 6.9
Good work, you've made the project I'm working on that much better :)

Probably several field implementations should come before this one, but I think we should be able to pull this in when profile gets field-alized

I tried applying the patch to 6.10 and got this:

patching file profile.admin.inc
Hunk #3 FAILED at 303.
Hunk #4 succeeded at 428 (offset 1 line).
1 out of 4 hunks FAILED -- saving rejects to file profile.admin.inc.rej
patching file profile.install
patching file profile.module
patching file profile.pages.inc

I don't know if I did something wrong or if something's changed.

I changed the status back to "code needs review" because a lot of people aren't happy with Content Profile and I personally don't want to wait 2 or 3 years for D7 to be a realistic option.

EDIT: So far it seems to work just fine, even with the errors. I was hoping it would work with Heirarchical Select, but I'll take what I can get.

This is failing, do any one have solution for this ?? i need solution for this and any help will be appreciated.

Run patch #33 it will give you error dont worry about that .. replace my code with "profile.admin.inc" and create database.

regards
Abhishek sachdeva

Re-titling.

This will be fixed properly when #412518: Convert taxonomy_node_* related code to use field API + upgrade path gets in for Drupal 7.

It works!

Is it possible to use it with the Taxonomy VTN module, or use Hierarchical Select? That would solve thousands of problems.

add tag

This is now a duplicate of #301071: Remove profile module from core