Profile lists don't work properly when accessed with a path alias

Actually, I think this might be a more general problem. Here's what I have found so far:

Under 'settings >> profiles' I created a new list selection field with the following selection options:

FOO BAR
BAZ BAT

Under 'my account' I chose the item 'FOO BAR' from the list selection field. The value 'FOO BAR' is stored in the profile_values table.

When I view the 'my account' page, the text 'FOO BAR' links to http://www.drupal.local/?q=profile/profile_test/FOO+BAR.

I create a path alias 'test' pointing at the part after ?q= of the above URL: test => profile/profile_test/FOO+BAR. Now, when I go to http://www.drupal.local/?q=profile/profile_test/FOO+BAR I get the expected result (a link to my account is displayed), but when I go to http://www.drupal.local/?q=test I am presented with an empty page.

Adding a print_r statement after the switch ($field->type) block in profile_browse gives the following results.

On http://www.drupal.local/?q=profile/profile_test/FOO+BAR:

Array
(
    [0] => 2
    [1] => FOO BAR
)

On http://www.drupal.local/?q=test:

Array
(
    [0] => 2
    [1] => FOO+BAR
)

In the second case, this means that 'FOO+BAR' is plugged into the select query; this returns an empty set since the string stored in the database is 'FOO BAR'

A quick fix is to do a preg_replace('/\+/', ' ', $value) in the beginning of profile_browse (similar to what is done in taxonomy_term_page).

This is a non-critical issue in a non-critical module. Please explain why you believe this is critical, if you want to reset it back.

Critical = A critical bug in Drupal... not a bug critical in importance to you :)

Thanks :)
-K

This is certainly not critical.

Anyway, here's a patch which needs testing.

This is a path aliasing issue and I'm working on it. Patch coming for review shortly.

We need to decide how dst aliases should be stored: urlencoded or urldecoded. That's the main dilemma.

When saving a path alias, the system accepts urlencoded or urldecoded paths so no standard was in place. That was the problem. I've changed this so we only store urldecoded paths since the url() function encodes paths already.

On a different note, I changed the help text in profile module becuase fields marked "public" can create their own view page, not just "public fields that are listed on the member page".

Code looks good to me.

The patch needs to be rerolled.

Re-rolled and committed. Thanks.