Support profile.module fields in Drupal 6

I think it's largely that it hasn't been done, but also that profile.module isn't very easy to configure through code.

Support for profile.module in Features (module), is a feature (enhancement) I would like and use now were it available.

The Drupal 7 version of this feature request is at #873122: Exportable user fields.

I wrote some code to add and partially-manage Drupal 6 profile.module fields for Redmine API and Toggl API modules. That code, together with the documentation on "Integrating your module with the Features API" (last 2 sections of API.txt) is most of what a developer would need to complete support for Drupal 6 profile.module fields in Features.

Here's a patch for this. It allows selecting profile fields individually.

It would probably be nice to allow also selecting by category (so all fields in a category are included, and if a field is deleted from a category this can be replicated on a site being updated), but I probably won't implement that any time soon...

Nice!

profile.module categories are rather meaningless from a structure point of view, and are just meta data attached to fields. I think it's best if the features support reflects that.

Tried this out, and we are having trouble importing fields - They export and show up in the feature code just fine, but when we enable the feature on another site, no profile fields.

Turns out it was a buggy feature, this patch works fine for us now

Testing this today, will report back if it works.

Worked for me, so it has my vote.

@yhahn @jmiccolis @adrian: if you want some stuff committed to 6.x but are short of time, contact me...I've got module maintaining experience.

This patch didn't use a relative path and created a features.user.new.inc file rather than patching the features.user.inc patch as it should.

It also needed some coding standards corrections (spaces instead of tabs, comment spacing).

Here is a re-roll with the above and a minor code comment clarification.

In my testing this successfully creates profile fields, detects when fields are deleted and reverts them.

Seems RTBC to me!

+++ includes/features.user.inc	31 Dec 2010 19:20:47 -0000
@@ -222,6 +228,77 @@ function user_role_features_rebuild($mod
+	$code = array();
+  $code[] = '  $profile_fields = array();';
+  $code[] = '';
+  ¶

Odd spacing
Powered by Dreditor.

Here you go with that last spacing issue fixed.

Hey features maintainers, what are the odds of getting this into the module?!

When exporting profile fields to a site where those fields already exist, duplicate fields are created, but apparently only for some fields. Setting back to NR since I'm not sure whether this issue is specific to the site I'm working on, so it would be good to try to reproduce with a fresh install.

subscribe

Although accessing the database for retrieving the profile field info is a quick way, it neglects modules (and its configurations) which are built on top of the profile module, e. g.:

- http://drupal.org/project/profile_checkboxes
- http://drupal.org/project/profile_taxonomy

I know this is a shortcoming of the profile module itself. Therefore I'd recommend to use some kind of hook, e. g. hook_features_profile_field_info_alter(), after the SQL query providing the possibility to alter or add profile field settings. In case of the 2 mentioned modules the data is stored within different database tables. It would be nice if the modules can provide their configurations by hooks.

@gnindl If modules like the ones you've listed extend user profiles, the burden is on them to store their extra data in an exportable way, not on the core profile module.

Making Features' profile support accomodate these extra modules seems like a separate feature request after this patch gets in, rather than a requirement.

Therefore, setting back to "needs review".

Also, is there a reason that hook_features_export_alter() is insufficient for these addon modules, and why a new hook is necessary?

@ezra-g: The problem is that these modules extend a specific profile field with additional attributes. The hook hook_features_export_alter() is not enough, as the the output generated in user_profile_field_features_export_render() should be changed, i. e. rendering additional profile field attributes.

You are right, it is not the responsibility of this issue. Storing the related additional information separately doesn't make much sense either. Therefore it would be great to provide the possibility to extend the loading of a profile field. A direct function call would be enough as well.

features-profile-fields-912716-11.patch worked for me. Thanks very much @sfyn

@gnindl - probably too late for you, but Profile is a very, very, basic user-attributes module. If you are using additional modules to give it quasi-CCK-like features - e.g. profile_checkboxes & profile_taxonomy - then, if you haven't discovered it already, you might consider using the Content Profile (http://drupal.org/project/content_profile) module - which treats profiles as user nodes? Using this the standard features module will work on the content profile CCK fields...

I'm using the patch in #11 successfully. Looking forward to it being committed.

I hope I am not jumping the gun here by setting this to RTBC based on comments 19 and 20.

It'll show up when the profile module is not enabled via putting it in .user.inc. This should all be in a new features.profile.inc.

Tiny winy bit of white space (look at dr editor and can see it). One of the comments end in "...", which seems a bit too... sarcastic to me.

@hefox: Attached is a revised version of the patch on #11. Changes:

• splits the profile.module support into a separate includes/features.profile.inc file
• removes two of the three dots in the ellipsis you mentioned
• removes all trailing whitespace

RTBC.

Thanks for the work,

I generally prefer a a few more reviews on any new patch, but as this is adding new functionality, it's unlikely to break anything at least, so committed away .

No need to upport it cause it's profile.