CCT definition corrupted on upgrade form 0.9.3.3 to 0.9.4.1-pl

[GoogleCodeExporter]

What steps will reproduce the problem? (Be specific)
1. upgrade from 0.9.3.3 to 0.9.4.1-pl
2. edit 2 CCT's in a row to get them to show up again 
3.inspect the second cct, and all its associated fields will be ocne, & 
definitions replaced with fields from the first CCT

What is the expected output? What do you see instead?
I hope to have both cct's returned to me, but I don't

Does the problem continue if you disable all other plugins?
Haven't tried that yet, but since Simple Custom Taxonomy is sort of required I 
am not sure.

Please provide any additional information below (e.g. Browser, version,
OS):
Using wp 3.2.  Attaching recent cct definitions in case that helps with 
replicatoin.

Please copy and paste the system information from the CCTM WP dashboard
screen that appears in a yellow textarea (this includes the version of the
plugin, the version of PHP, the version of MySQL, a list of other active
plugins etc.):

Original issue reported on code.google.com by mopto...@gmail.com on 14 Oct 2011 at 4:42

Attachments:

• cctm_people_and_book_export.cctm.json

[GoogleCodeExporter]

Thanks for the detailed report.  Is the def from 0.9.3.3? Or is it in the 0.9.4 
format?  I'll figure that out shortly, but I thought I'd ask.

Original comment by fireproofsocks on 14 Oct 2011 at 4:58

• Changed state: InReview
• Added labels: Priority-Critical, Type-Defect

[GoogleCodeExporter]

Aha... finally was able to reproduce this.  Thanks for including the def file!

Original comment by fireproofsocks on 14 Oct 2011 at 8:00

• Changed state: InProgress

[GoogleCodeExporter]

On Fri, Oct 14, 2011 at 12:59 PM, <
wordpress-custom-content-type-manager@googlecode.com> wrote:

def is from 9.3.3.  I was able to get the old CCT fields back by manually
deleting the 0.9.4 plugin files and reinstalling from an 0.9.3.3 zip I had
lying around.  However, re-upgrading results in the same corruption.  Turns
out I didn't have a current db update, so if you can suggest manual db
modifications I'd be interested in those too :-( . In any case, thanks once
again, Everett!

Original comment by mopto...@gmail.com on 14 Oct 2011 at 8:08

[GoogleCodeExporter]

On Fri, Oct 14, 2011 at 4:01 PM, <
wordpress-custom-content-type-manager@googlecode.com> wrote:

awesome, clad I could help!

Original comment by mopto...@gmail.com on 14 Oct 2011 at 8:10

[GoogleCodeExporter]

Sorry the upgrade is problematic -- the "easy" solution here would be to do a 
complete uninstall and re-install, then redefine your post-types and custom 
fields, but that's no fun.  I wrote code to help transition the data 
structures, but the examples I tested with didn't exhibit this corruption, so 
I'm glad to have a repeatable case here.  Again, I'm sorry this is causing 
trouble... the last thing I want is my code to be causing problems instead of 
solving them.  Hopefully I can iron out the fix here shortly...

Original comment by fireproofsocks on 14 Oct 2011 at 8:20

[GoogleCodeExporter]

Ok, I finally found the problem.... it had to do with variable references.  
Sheesh. See the attached for the patch. Let me know if this doesn't upgrade 
correctly -- it's 0.9.4.4-dev

Committed revision 451238.

Original comment by fireproofsocks on 14 Oct 2011 at 10:15

• Changed state: Fixed

Attachments:

• custom-content-type-manager.zip

[GoogleCodeExporter]

Snap... you still have to edit and resave the defs to get custom content types 
to show up in the menus.  

Original comment by fireproofsocks on 14 Oct 2011 at 10:23

• Changed state: InProgress

[GoogleCodeExporter]

hmm, logged in as admin to this page:
/wp-admin/edit.php?page=cctm_fields
I get the message "You do not have sufficient permissions to access this page." 
when running 09.4.4-dev.  Do you see the same issue?

Original comment by mopto...@gmail.com on 15 Oct 2011 at 7:02

[GoogleCodeExporter]

I'm still trying to work around WP's wonky menu system.  The page SHOULD be 
admin.php with the url parameters, but sometimes the links get added to the 
edit.php page instead.  I've been weeding these out, but I guess I missed a 
couple still.  What steps did you take to get to that?  I.e. where did that 
link appear?

Original comment by fireproofsocks on 15 Oct 2011 at 7:38

[GoogleCodeExporter]

Still troubleshooting the fallout from this, if you have time to help.  The old 
fields are still kicking around in the database somewhere, as I can tell by the 
fact that the names I want to use are taken.  However, those fields are absent 
from the custom fields UI at this address:
/wp-admin/edit.php?page=cctm_fields (now loading again, for reasons I don't 
quite understand)
Anything I can do to make them visible again?  Once they're recognized by CCTM, 
I can presumably just use the 'manage associations' feature to recreate the old 
datatype.  

I should say that I've tried reloading the old .cctm.json definitions, but 
0.9.4 doesn't seem to recognize them (could I upgrade serially through an 
intermediate version tht can stil lrecognize the 0.9.3.3 formats, do you think? 
I'm reluctant to restart the site w/ an empty database as we've already done a 
significant amount of data migration I don't want to lose.  The lack of backup 
is my fault, though, so I'll go that route if I must.  

Thanks,
Matt

Original comment by mopto...@gmail.com on 15 Oct 2011 at 7:39

[GoogleCodeExporter]

... I meant to say: I can do some direct manipulations of the db if necessary, 
but don't quite know where the CCT definitions are stored.  presumably I should 
be able to manually associate the fields with the CCT somewhere, right?

sorry for the comment deluge. Kept forgetting to say everything, though...
matt

Original comment by mopto...@gmail.com on 15 Oct 2011 at 7:58

[GoogleCodeExporter]

Hmmm....

0.9.4 cannot import 0.9.3 definitions -- that might be possible once we get the 
conversion between data structures working.

0.9.4 forward, all data (including definitions) is stored in the wp_options 
table with the key "cctm_data" -- like all WP options, it gets stored as a 
serialized PHP array, so it's not very editable in the raw. 

Can you give me steps to reproduce?  Man, I never anticipated migrating data 
structures would be such a headache.

Original comment by fireproofsocks on 15 Oct 2011 at 8:09

[GoogleCodeExporter]

Oh, man, I see some of what's going on... ack.  I wish I had xDebug installed 
when I was working on 0.9.3.

Original comment by fireproofsocks on 17 Oct 2011 at 1:29

[GoogleCodeExporter]

It may be too late to fix your install, but I did find the edge case there and 
fixed it in the dev version (see attached).  The last-ditch fix here would be 
to:

1. completely uninstall and delete version 0.9.4.x (this should force the 
cctm_data option to be deleted from wp_options table)
2. re-install 0.9.3.3 (available @ 
http://wordpress.org/extend/plugins/custom-content-type-manager/download/)
3. import your content-type definition
4. Then do the upgrade to the attached 0.9.4.4 file

I'm baffled how the custom fields could be floating around in the db without 
you being able to see them, though, so I really hope the attached fixes the 
problem.  What a nutty nightmare this has been to fix!

Original comment by fireproofsocks on 17 Oct 2011 at 2:08

• Changed state: Fixed

Attachments:

• custom-content-type-manager.zip

[GoogleCodeExporter]

ok, Everett, you rock.  The suggested fix worked for me:
- deactivate & delete CCTM 0.9.4; 
- install 0.9.3.3 manually (for me, that's unzip; chown; chmod, in case other 
people need to do this & run into difficulties); 
- import the 0.9.3.3 datatypes; 
-manually re-upgrade to the current dev version (following the same unzip, 
chown, chmod procedure as above)

All fields now show up properly in your lovely new UI -- it really is so easy 
to use, thank you! -- and I'm looking forward to getting back to working on the 
site.  

VERY glad to have this up and running; making a backup right now before going 
any further!! thanks again, this is really great.  

Original comment by mopto...@gmail.com on 17 Oct 2011 at 2:17

[GoogleCodeExporter]

So glad that worked.  Thanks so much for following through with such a detailed 
bug report -- I never would have run across that edge case with the tests I was 
doing on my own.  I had a bug in the field sorting function that caused the 
0.9.3.x data structure to be "somewhat" corrupted -- the plugin recovered from 
this minor corruption, but the data ended up being in a format that I didn't 
expect, so the upgrade script didn't do what I thought it would be doing.  
Anyhow, that's for your patience!

Original comment by fireproofsocks on 17 Oct 2011 at 4:26