Ah, I bet that you are running into the dreaded Elgg metadata bug.

Elgg metadata confuses case.

Try replacing line 564 of mod/form/models/model.php

It is currently

        } else if (in_array($field_type,array('email','url','aim','msn','skype','icq'))) {

replace it with

        } else if (in_array(strtolower($field_type),array('email','url','aim','msn','skype','icq'))) {

charismeki,

As the calendar issue you mention is not addressed by this release, could you post a more detailed bug report in a separate thread?

Then I can make sure that it gets proper attention.

The calendar field is just a kludge in any case - my plan is to replace it completely with the same jQuery date picker used by the event_calendar plugin.

Actually, a better change would be to just add

// circumvent Elgg metadata bug
    $field_type = strtolower($field_type);

to the top of the form_field_type_to_view function.

bingo ; ) just added your last suggestion and voila, it is working.

Many thanks! Does this metadata issue take other known effects on other functions as well?

I'll add a new thread for the calendar.

ps: calendar issue solved automatically. calendar seems to depend on the medatdata as well.

Curverider is aware of the problem (the case of metadata is not preserved) and there are some plans to fix it once and for all in a future core release. In the meantime, I will look to see if there are other places where this problem might arise.

The truth is that this problem could come up anywhere metadata is being used as case matters a lot.

This problem affects any plugin that stores metadata.

Just for reference, I have found that setting the collation of the metastrings table (and the "string" field within it) to utf8_bin can help. The default  collation utf8_general_ci is case insensitive and seems to make the Elgg metadata bug worse.

But really, the only good solution would be to recode Elgg metadata handling so that case is preserved when extracting specific values (but ignored for searches). As I said, I know Curverider is looking into that.

Dear Kevin,

sorry bothering you but i am still facing problems. Until now i have not recognized  that i get this output at the extended profile:

Any idea? It seems that the calendar issue still exists as well. i will test that tomorrow.

Looks like something is printing debugging output. But I can find nothing in the latest code (0.8.1) that could produce this.

Is it possible that you took some core code from SVN that has a debugging statement left in it?

Actually when I look at this again, this shows a structure that looks like:

$obj->tag and $obj->total

and there appears to be nothing in core or my plugins that creates anything like this.

Perhaps another plugin?