Partners sadtime

gistfile1.md

Day 2 begins! Day 1 notes here

https://technonaturalist.net/blog/2011/01/drupal-7-notes-dealing-ghost-fields

https://technonaturalist.net/comment/reply/43/1223 -- Comment from Jen Lampton Nov 2013 Running cron once doesn’t always do the trick. If it doesn’t work the first time, you may need to run cron 10 or 20 times to get the fields to actually be deleted. Its faster to just manually delete the two tables (field_data and field_revision) as well as the two records from field_instance and field_instance_config. Still not resolved as of the latest version of D7.

https://drupal.org/comment/5865292#comment-5865292

• Delete the records from field_config / field_config_instance

Fuck. Was it just this the whole time?

https://drupal.org/node/1239946

someone says here is the answer https://drupal.org/node/1498746#comment-6734208 -- which says both modules should be updated to latest. and, now realizing we need to upgrade entity from 1.2 to 1.3.

so. next test is to see if i remove video_id from the partners_fc field collection, should i be able to successfully save without a ghost entity id value in field_partners_fc ?

either way we'll want to delete field_partners because it's full of bogus data now. so, all of that work around deleting a field_collectoin field is still relevant. (tell yourself that)

Removing video from the field_partners_fc field collection. It'd make sense if this fixes it, we probably haven't used any FC's with default values set.

The field Video has been deleted from the Field collection field_partners_fc content type.

Ok lets try this again. node/add/campaign

No I still get this shit

EntityMetadataWrapperException: Invalid data value given. Be sure it matches the required data type and format. in EntityDrupalWrapper->set() (line 736 of /vagrant/html/profiles/dosomething/modules/contrib/entity/includes/entity.wrapper.inc).

Lets try to upgrade entity and just grab the latest version of field collection. Fuck!

Attempted build on same db with updating to Entity 1.3 and the latest commit on field collection.

Updating database...
 Field_collection  7004  Add index on {$field_collection_field}_revision_id 
                         column for all tables.
Do you wish to run all pending updates? (y/n): y
Performed update: field_collection_update_7004                       [ok]
'all' cache was cleared.                                             [success]
Finished performing updates.                                         [ok]
Clearing caches...

no, nothing. still get a false entity upon creating a new campaign.

new plan. just remove the field_partners for good. try to rebuild the field collection over again but WTF.

i suppose i need to now test to see what happens just deleting the whole thing and never adding the partners_fc in.

Testing remove_partners branch with staging db. Upgraded entity to 1.3 and field_collection to latest dev commit.

Plan is to updb and then see if at least all is well with completely removing this guy. Tackle the incorrect default entity another day.

This is what's crazy. I just grabbed the latest stage db and now there are no field_deleted tables present. This is while drush updb is runnig but I haven't answered yes yet. This is where I seem to be magically manipulating the database on staging by doing all this stuff locally.

Do you really want to continue? (y/n): y
vagrant@dev:/vagrant$ cd /vagrant/html
vagrant@dev:/vagrant/html$ drush updb
 Field_collection  7003  Update field_collection_field_schema columns for all 
                         tables.                                              
 Field_collection  7004  Add index on {$field_collection_field}_revision_id   
                         column for all tables.                               
 Dosomething_taxo  7001  Remove field_partners.                               
 nomy
Do you wish to run all pending updates? (y/n): y

Proof. The update hasn't run yet. Maybe it's cron running on staging that's purging. But.. I don't know. I still have my mystery partners_fc table which exists and still hasn't been committed into dev.

^^ Should have tested on deleting the is_sponsored field too. That could be the one that's providing the default value that's creating the false entity. (only tried deleting the video_id field)

http://dev.dosomething.org:8888/node/43 works. seeing no deleted tables. lets try the add a few campaigns trick

here we go, update from stage then disable apachesolr. let's also test a record on staging db to maek sure deleted tables don't exist. Aaron Test 1010

ds update-db

Actually just looking at a node 591 created and there's a "Learn more about " link... meaning there's probably a bogus entity for "More Facts" too. Already did a ds update-db but worth looking into. Might be happening on a few different nodes?

Confirmed no more field_deleted tables in new db pull, and updated campaign title is Aaron Test 1010" . All partners tables exist in the db, including partners_fc

drush -y dis apachesolr

drush -y en devel

drush updb

Took a lonnnng time to ask if i really want to continue. YES

Pretty sure that this guy is a separate issue https://drupal.org/node/1239946 that started the whole thing.

vagrant@dev:/vagrant/html$ drush updb
Field_collection 7003 Update field_collection_field_schema columns for all
tables.
Field_collection 7004 Add index on {$field_collection_field}_revision_id
column for all tables.
Dosomething_taxo 7001 Remove field_partners.
nomy
Do you wish to run all pending updates? (y/n): y
Performed update: field_collection_update_7003 [ok]
Performed update: dosomething_taxonomy_update_7001 [ok]
Performed update: field_collection_update_7004 [ok]
'all' cache was cleared.

drush -y fra

array_merge(): Argument #1 is not an array image.module:586          [warning]
The following modules will be reverted: dosomething_taxonomy, dosomething_image, dosomething_campaign, dosomething_static_content
Do you really want to continue? (y/n): y
Reverted dosomething_taxonomy.user_permission.                       [ok]
Reverted dosomething_image.image.                                    [ok]
Reverted dosomething_campaign.variable.                              [ok]
Reverted dosomething_static_content.user_permission.                 [ok]
Reverted dosomething_static_content.variable.                        [ok]
vagrant@dev:/vagrant/html$ 

Multiple ndoe creation seems ok. Going to try save existing.

the deleted tables are back!

vagrant@dev:/vagrant/html$ drush -y dis apachesolr
The following extensions will be disabled: apachesolr, apachesolr_search, dosomething_search
Do you really want to continue? (y/n): y
apachesolr was disabled successfully.                                [ok]
apachesolr_search was disabled successfully.                         [ok]
dosomething_search was disabled successfully.                        [ok]
vagrant@dev:/vagrant/html$ drush -y updb
Killed
vagrant@dev:/vagrant/html$ drush -y updb
 Field_collection  7003  Update field_collection_field_schema columns for all 
                         tables.                                              
 Field_collection  7004  Add index on {$field_collection_field}_revision_id   
                         column for all tables.                               
 Dosomething_taxo  7001  Remove field_partners.                               
 nomy
Do you wish to run all pending updates? (y/n): y
Performed update: field_collection_update_7003                       [ok]
Cannot rename <em class="placeholder">field_data_field_partners</em> [error]
to <em class="placeholder">field_deleted_data_87</em>: table <em
class="placeholder">field_deleted_data_87</em> already exists.
Performed update: dosomething_taxonomy_update_7001   

this is fun.

maybe the shitty fix is just that when you check to see if partners exist, you have to actually check and see if the term tid is set. and accept that it just creates empty field_collection_item id's for every single node.