Right now, profile categories are stored as plain text for each profile field. This is not a very good data model and also causes some more important problems when trying to build on profile categories.

This patch:
- Creates a new table for profile categories, which will be linked to profile fields by a 'cid' (category id) field
- When creating profile fields, replaces the category text field by a drop-down
- Allows weights and some more description text for profile categories on user forms.
- Adds a category 'name', same idea as 'field' name that will be used in forms and when passing profile data to user module. This improves data handling internally by Drupal and other modules by using a fixed 'category' name that won't be visible to the users. This will allow more efficient form rewriting and theming for user pages

Also, this is related to the multilingual features we are coding, and will allow translation of category titles and descriptions later while with the current implementation this is just not possible.

Notes:
- Most of the code is just about adding the forms and reworking the tabs for profile administration pages
- This patch doesn't change anything on user.module and its user profile handling, but that may be improved later, allowing much better themeability for user pages, now we have 'manageable' category names.
- Update scripts not included yet, but it will work with a clean install of profile module

To-do: update scripts, waiting for some feedback before...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Jose, good work! Some notes by reviewing the code:

- Yes, update path is missing, but you already mentioned that. Should be fine later.
- PostgreSQL code is not changed.
- _profile_add_field_access() does not check for admin permissions (the other menu items rely on that being inherited from the upper menu item I guess)
- I am not sure that we need a menu_rebuild() when we save a profile category, or could it possibly affect the menu?

It is important to point out the rationale to people clearly. Now profile modules stores categorie names on all profile fields. When you add a new field, you need to enter the exact same category name used before to get the field into the same category. If you would like to change a category name, you need to go through all fields in that category. This is not usable, so people introduced an AJAX autocomplete feature to support typing in the same category title. This was a hackish workaround of the problem. This patch tries to address the problem by factoring categories out to being standalone objects.

This patch is also crucial for localization, because we need standalone objects to translate. If we have profile fields with category names in each, we would need to provide this category name for translation every time, for every field. Even if we would somehow manage to handle that, the previous version of profile module used the category name as a key to the form array, which makes it impossible to alter if you have the category name translated to different languages on different page views.

Boris Mann’s picture

Let's not do ANY more work on alternate data structures. This should be taxonomy based.

Same goes for anyone trying to touch the "categories" in aggregator module....

Gábor Hojtsy’s picture

Boris, you mean like how forum module reuses categories, settings forum module as the handler module for the forum vocabulary?

Jose Reyero’s picture

Boris, unless we provide some generic mechanism to extend taxonomy fields, we'll still be needing some other tables, like here, to provide a low level name for these categories so they can be handled in forms, or you can add fields to other category name provided by other module.

So either we build on taxonomy categories architecture to make it more extendable or I'd stick to this solution. If we need to add tables and fields anyway, I don't see how it is better than having all the fields in the same new table. Taxonomy really doesn't add too much here.

It is different for the aggregator though, as it could be really used to categorize content...

Dries’s picture

Let's move ahead with this patch and worry about the taxonomy system migration later. With only a couple weeks to the code freeze, I'm not comfortable with turning this into another mega-patch.

Wim Leers’s picture

Subscribing.

cboshuizen’s picture

Definitely all modules that do anything at all with the word "category" should use taxonomy to provide the categories. There'd be no need then for a proprietary module to manage them if this were the case. I for one would support proper taxonomy support in a future release.

webchick’s picture

Status: Needs review » Needs work

patching file modules/profile/profile.install
Hunk #1 FAILED at 8.
Hunk #2 FAILED at 31.
Hunk #3 FAILED at 80.
3 out of 3 hunks FAILED -- saving rejects to file modules/profile/profile.install.rej
patching file modules/profile/profile.module
Hunk #3 succeeded at 233 with fuzz 1.
Hunk #6 FAILED at 477.
Hunk #8 FAILED at 500.
Hunk #9 succeeded at 518 with fuzz 1 (offset 1 line).
Hunk #10 FAILED at 592.
Hunk #11 FAILED at 809.
Hunk #12 FAILED at 828.
Hunk #13 succeeded at 864 with fuzz 2 (offset 12 lines).
Hunk #14 succeeded at 883 (offset 12 lines).
Hunk #15 succeeded at 891 (offset 12 lines).
Hunk #16 succeeded at 899 (offset 12 lines).
Hunk #17 succeeded at 914 (offset 12 lines).
Hunk #18 succeeded at 923 (offset 12 lines).
Hunk #19 succeeded at 979 (offset 11 lines).
Hunk #20 succeeded at 1022 (offset 11 lines).
Hunk #21 succeeded at 1048 (offset 11 lines).
5 out of 21 hunks FAILED -- saving rejects to file modules/profile/profile.module.rej

mlncn’s picture

Subscribing *way* after the fact.

When this or a similar issue gets opened for Drupal 7, I'd like to push hard for (that is, actually help code) a CCK field + Taxonomy solution. Which probably puts this in the uber-mega-patch category, but it seems the right thing to do.

(As a use case: we found to this page trying to add an autocomplete taxonomy field to a user profile that they can access when registering.)

Gábor Hojtsy’s picture

Version: 6.x-dev » 7.x-dev

Recategorizing for Drupal 7.

rkendall’s picture

subscribe

I think it's important to have weighted profile categories, and also I think that this issue doesn't need to be linked with taxonomy - that would just over-complicate things

stella’s picture

subscribing

jtnatoli’s picture

Version: 7.x-dev » 6.4

I am very novice to Drupal and I'm looking for a way to weight profile categories in 6.x
Can I use this patch to do so?
Thanks.

Pasqualle’s picture

Version: 6.4 » 7.x-dev

I am very novice

hmm.. no

Gábor Hojtsy’s picture

Well, whether this needs a reroll or not depends highly on whether fields in core gets into core and the bio as node concept gets stronghold in core. If it does, then profile module can die a slow/quick death, and node bios can take over.

jsaints’s picture

@gabor

I could work to make this patch happen for 7.0. Do you have an update on whether you think its still needed?

Thanks
Jon

Boris Mann’s picture

Yes, a similar patch to evolve profile.module and/or make it die a quick death is still needed. Are fields in core for D7? If yes, then enabling a new profile.module could create a profile content type.

This is theoretically concerned with categories -- is there another, better issue to cover "replace custom profile module data model with nodes / fields"?

moshe weitzman’s picture

Fields is in, but still no migration of profile to fields system.

If profile fields turn in to core fields, then categories could be vocabulary fields that are applied to a field instance. Is that reasonable? Too complex? These vocabulary fields would probably be system managed with no UI.

RobLoach’s picture

Damien Tournoud’s picture

Status: Needs work » Closed (won't fix)

The profile module is obsolete. Won't fix.