Upgrading from B2 of the Professional Pack to RC1 i've lost all the values entered into Custom Fields. The Custom Fields are still defined-- but the content added to them with each entry has disappeared.
Add a Reply
Forum Groups
4.1 Beta
9 17
Last Topic: Some questions raised after reading Hacking Movable Type by rxmatt on Oct 10, 2008
4.2 Beta
78 269
Last Topic: Lost database - How to recover from 3.2 created PHP files ? by taurianthebull on Nov 3, 2008
Design, Templates, & Tags
106 356
Last Topic: Scrollbar missing - Fixed positions by aliceaddict on Nov 9, 2008
Product Ideas
9 38
Last Topic: MT module for authentication with JA-SIG CAS by Subhashish on Oct 25, 2008
code.sixapart.com
Action Streams
62 226
Last Topic: Callback after blog publishing. by Tomato Interactive on Oct 27, 2008

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.
The good news is that I don't think your data is lost. My hunch is that it was not fully upgraded/migrated to the new custom field storage system. There are fixes in RC2 (in development) that should address this. We are aware that some issues exist and we are working to move the release of RC2 up in the schedule to get these fixes out to the community as soon as possible. You might consider one of the nightly MTOS builds - it contains the upgrade routines you need and you should be able to drop it in over MT 4.2 RC2.
I must admit to a slight confusion on just where to get the nightly build. All of these http://www.movabletype.org/opensource/downloads/nightlies/ seem to be somewhat older than what I was expecting.
Michael - I am terribly sorry, you are right - there seems to be a problem with our nightly build script. It will take me some time to look into that.
In the meantime, let me recommend an article about SVN tips.
Michael - I am terribly sorry, you are right - there seems to be a problem with our nightly build script. It will take me some time to look into that.
In the meantime, let me recommend an article about SVN tips.
I must admit to a slight confusion on just where to get the nightly build. All of these http://www.movabletype.org/opensource/downloads/nightlies/ seem to be somewhat older than what I was expecting.
The good news is that I don't think your data is lost. My hunch is that it was not fully upgraded/migrated to the new custom field storage system. There are fixes in RC2 (in development) that should address this. We are aware that some issues exist and we are working to move the release of RC2 up in the schedule to get these fixes out to the community as soon as possible. You might consider one of the nightly MTOS builds - it contains the upgrade routines you need and you should be able to drop it in over MT 4.2 RC2.
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
It should fix it! If not, please let us know so that we can redouble our efforts and get the fix out there.
Has this been fixed in RC3? There's no release notes or change log. Thanks.
Has this been fixed in RC3? There's no release notes or change log. Thanks.
It should fix it! If not, please let us know so that we can redouble our efforts and get the fix out there.
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?
You are not the only one. :(
You are not the only one. :(
I hadn't been keeping up but when I saw RC4 was out I gave it a shot. Exact same problem as RC1. I am more than a little bewildered than a final RC would still have such a major issue.
Michael: Byrne has sort of addressed this elsewhere. Have a look at his suggestions.
Hudson: Try to restrict support issues to the forum? Or at least one location.
Su,
I read Brad's reply and followed the link to the FogBugz entry. But I still wasn't sure what I was looking for. Since Brad had posted a portion of his code as "non-destructive" and for MySQL I decided to give that a shot.
Unfortunately, I got the following error message: #1054 - Unknown column 'authormetavchar_indexed' in 'field list'
Unfortunately, I am not sure what to try next.
Su,
I read Brad's reply and followed the link to the FogBugz entry. But I still wasn't sure what I was looking for. Since Brad had posted a portion of his code as "non-destructive" and for MySQL I decided to give that a shot.
Unfortunately, I got the following error message: #1054 - Unknown column 'authormetavchar_indexed' in 'field list'
Unfortunately, I am not sure what to try next.
Michael: Byrne has sort of addressed this elsewhere. Have a look at his suggestions.
Hudson: Try to restrict support issues to the forum? Or at least one location.
I hadn't been keeping up but when I saw RC4 was out I gave it a shot. Exact same problem as RC1. I am more than a little bewildered than a final RC would still have such a major issue.
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.
Hudson, the reason is the same one I give every time someone does what you're doing: It dilutes the information and ultimately makes it harder to find.
If no one has responded to your question that sucks, but it's cause to complain that you haven't been responded to, not to start spamming your issue everywhere possible.
The blog, furthermore, is not the venue for support requests. If you're going to trot out that nobody answers anything in the forums, be aware that I am one of the very few who currently does respond to forum posts, and explicitly ignore such requests over there, again because it's easier for everyone if such information is contained. It's your choice whether to help that or not.
I believe you and I had this same discussion in the Six apart Forums when Six Apart took over Custom Fields--- and no one could answer any questions regarding the missing functionality in the code. After 3 months of * not complaining * I posted elsewhere -- and got an answer... that flipped you out and got you flaming. It appears it's happened again here. After 2.5 months of not complaining... there is still nothing in the support thread above. The acceptable routes to get support don't always provide support... and Six Apart has diluted the communication paths with too many venues to seek out help... this forum, the six apart forum, the beta blog and paid support. Both times my inquiries sat for months unanswered in the forums, however they were answered immediately when posted on the blog.
I believe you and I had this same discussion in the Six apart Forums when Six Apart took over Custom Fields--- and no one could answer any questions regarding the missing functionality in the code. After 3 months of * not complaining * I posted elsewhere -- and got an answer... that flipped you out and got you flaming. It appears it's happened again here. After 2.5 months of not complaining... there is still nothing in the support thread above. The acceptable routes to get support don't always provide support... and Six Apart has diluted the communication paths with too many venues to seek out help... this forum, the six apart forum, the beta blog and paid support. Both times my inquiries sat for months unanswered in the forums, however they were answered immediately when posted on the blog.
Hudson, the reason is the same one I give every time someone does what you're doing: It dilutes the information and ultimately makes it harder to find.
If no one has responded to your question that sucks, but it's cause to complain that you haven't been responded to, not to start spamming your issue everywhere possible.
The blog, furthermore, is not the venue for support requests. If you're going to trot out that nobody answers anything in the forums, be aware that I am one of the very few who currently does respond to forum posts, and explicitly ignore such requests over there, again because it's easier for everyone if such information is contained. It's your choice whether to help that or not.
To clarify one thing, the problem I have is the actual transfer of the information to a new venue. If you want to post a reference back to the original forum thread someplace, go nuts. Links themselves make things easier to find.
Isn't your complaint then with Byrne, who responded and "transfered" the information to the new venue?
Do whatever you want. I can't be arsed with this anymore.
Do whatever you want. I can't be arsed with this anymore.
Isn't your complaint then with Byrne, who responded and "transfered" the information to the new venue?
To clarify one thing, the problem I have is the actual transfer of the information to a new venue. If you want to post a reference back to the original forum thread someplace, go nuts. Links themselves make things easier to find.
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.