profile field values that should be browse-able (clickable) are not displayed as such [#69228]

In the profile.module, the function profile_browse contains two queries at lines 419 and 472 to fetch fields to be displayed. Because the 'page' field (for the page title) is NOT selected, the $field->page property will be false, and the $browse variable in the profile_view_field will evaluate to FALSE. This means that field values that should be browseable are displayed 'plain' instead clickable.

Comment	File	Size	Author
#7	profile.module.patch.3	1.35 KB	jpulles
#4	profile.module.patch.2	1.35 KB	jpulles
#3	profile.module_22.patch	1.37 KB	jpulles
#3

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

jpulles CreditAttribution: jpulles commented 19 June 2006 at 13:06

Title:	field values that should be browse-able (clickable) are not displayed as such	» profile field values that should be browse-able (clickable) are not displayed as such
Priority:	Normal	» Critical

'profile' added to title to indicate profile module

Comment #2

beginner CreditAttribution: beginner commented 6 July 2006 at 14:00

Priority:

Critical

» Normal

Patch?
http://drupal.org/patch

Comment #3

jpulles CreditAttribution: jpulles commented 31 July 2006 at 09:32

Status:

Active

» Needs review

File	Size
profile.module_22.patch	1.37 KB

Patch added. To test the change, add e.g. a free form list field and a text field with both having a page title and both fields to be displayed on member pages. When requesting the browse list for the second field, the free form field will display without clickable links before applying the path, and with links afterwards.

Comment #4

jpulles CreditAttribution: jpulles commented 31 July 2006 at 11:50

File	Size
profile.module.patch.2	1.35 KB

I'm certain if it is required, but this patch has unix line endings.

Comment #5

jpulles CreditAttribution: jpulles commented 31 July 2006 at 11:54

Sorry, in previous comment NOT was missing: I'm not certain etc. etc.

Comment #6

beginner CreditAttribution: beginner commented 17 August 2006 at 17:12

first, I wouldn't be able to test a patch without unix line endings. I think it is required.

You have both:
single-line textfield
multi-line textfield
the second one does not have a a title page, so I assume you mean the former.

I have tested the patch, but really, I cannot see the difference whether I'm browsing ?q=user/1 or ?q=profile/profile_freeform/banana .

Can you test yourself again, with a fresh cvs head, whether your patch is necessary?
If you are sure it is, explain a bit more how to test the difference.

Comment #7

jpulles CreditAttribution: jpulles commented 17 August 2006 at 20:40

File	Size
profile.module.patch.3	1.35 KB

I just created a new patch for the current cvs head and it is still necessary...
To test it, you can define 2 fields of type 'freeform list', with names e.g. profile_freeform1 and profile_freeform2, as 'Public field, content shown on profile page and on member list pages' and with a page title to be used on the member list pages.
Before the patch is applied, an url as http://localhost/drupal-cvs/?q=profile/profile_freeform1/banana will show a member list with value(s) for the other profile_freeform2 attribute.
After the patch is applied, the values will be clickable links with an url as http://localhost/drupal-cvs/?q=profile/profile_freeform2/coconut.
The difference of applying the patch will only become apparent when having multiple profile fields, so that the other fields are displayed in the member lists.