Hmm. Some how I've managed to post this in the wrong forum-- or not in a forum at all?? I meant to post this in 4.2 Beta. My apologies.

I can second that this is an issue. And what is more... When I tried to re-enter the missing data into the entry fields, it appears to save but then vanishes again when I leave and return. So at this point, Custom Fields seems to be completely broken.

Yes i too! when i was upgrade to RC1 and made a field in custom fields, receive an error in my Activity Logs that said: "Unnamed plugin died with: Invalid metadata type '3' for field MT::Entry field.email at lib/MT/Object.pm line 458"

I don't have a plugin error, just lost data.

Any update to this? I rolled my database back to an earlier version and went back to Beta 2.

Byrne, Thanks for the update. I'll try nightly build today.

The custom date fields don't seem to take the format attribute at all. You can't specify the output date format. It just spits out the default format and ignores the attribute, like so:

<mt:MyCustomDateFieldTag format="format="%A, %B %e, %Y">

only generates the %B %e, %Y format.

Does RC2 have the fix for this? It's not listed in the change log. Thanks

I get this error when trying to upgrade to MT-4.2rc2 from 4.1 ...

"Error during upgrade: Undefined subroutine &CustomFields::Upgrade::customfieldsmovemeta called at lib/MT/Upgrade.pm line 1037."

This problem still has not been fixed. Custom Field values are still lost during the upgrade to RC2. Nighties do not appear to include the Commercial MT version with Custom Fields. I've filled out a bug report for RC1. Does it need to be filled out again for RC2?

I've already done that. It was my first time on the bugtracker and I didn't see it in RC2 so I figured it needed to be there.

Still no sign of the RC3 change log. Is there anywhere to go to find out if this has been fixed?

two months and can't get any status on when this bug will get fixed. If Custom Fields are a big selling point for the commercial version-- surely someone has to be working on fixing this. If every upgrade wipes out your Custom Fields data, there's going to be a lot of angry commercial users.

forth release candidate and custom fields are still wiped out during the upgrade. when is this going to get fixed? am I the only one using custom fields?

SU...

I've been posting this problem in this thread since May. Why shouldn't I try another avenue to get support? No one answers the post here.

A different questions than above and, I think, a more important one: Does the Professional Pack work properly in a new install with 4.2 RC4 or not?

And, if not, will the Professional Pack work properly in a new install with 4.2?

Losing data is very frustrating. We all need to keep that in mind in this thread. People want and deserve resolution, and we are committed to providing it. There are a number of reasons this could be the wrong venue for working through this issue, but I want all of us to set that aside for now and focus on what is important - getting closure to this issue.

@Michael - The Professional Pack most certainly works with a new install. We have tested and retested custom fields for this release.

I still suspect that the problem people have been experiencing is related to the fact that we completely overhauled how custom field data was stored during the course of the beta. We felt justified in making this change midstream because the benefits far out weighted the challenges users may be faced with.

In any event, while making the switch from storing custom field data in a blob, to storing it in a separate table we uncovered bugs in an automated upgrade process that was designed to move people seamlessly. These bugs did not occur in our own testing unfortunately, but that is why we have a beta. I myself encountered problems which the bug I mentioned in the comments of the blog post mentioned above helped me to resolve. It is entirely possible that what worked for me, would not work for you.

@hudson - The best way for us to get closure to this issue is for us to attempt to reproduce it internally, and for us to analyze your database structure directly. Only then can we get to the root cause of what is happening. Again, I assert that this is not a functional issue with the app per-se, but a data issue resulting from a failed upgrade process.

So let me suggest those of you having problems, please log a bug and an engineer will be assigned to help get you up and running. We must make sure that your problem is not symptomatic of a greater problem.

Thanks again for everyone's patience. Remember, we are all trying to help one another here. Frustration may very well be warranted, and I take the blame for that. But a smidgen of gratitude to those who dedicate themselves to helping others may also help.