I tried on my staging server to upgrade from 2.2.23 to 3.0.1. First time it only went to 2.3.2. Had to do it again to go to 3.0.1.
Go to Relationships.
It correctly identifies I have legacy relationships (actually just 1).
Click "Run the migration" button.
It correctly identifies the 1 relationship.
Custom legacy code check took a very long time where I thought it failed the first few times. I do know there is some code in functions.php that may need updating. I let it wait and it finally came back with messages and errors.
According to what I have read in the forum and Toolset blog comments, I should not have to update my child posts using get_posts and the get_post_meta. But after the migration, the PHP code didn't find the correct child posts. So now I'll have to figure out how to change the code.
But the problem I am reporting now is the error messages from the migration. I had previously deleted post types, views, content templates, etc. from the live site to prepare for the upgrade to 3.x because I had other relationships that I no longer needed, except for the one remaining one.
The error messages from migration still showed them so I need to determine how they are still in the database and how I didn't delete them from either the UI or phpAdmin.
I even went back to production and deleted more from Toolset that could have caused these errors. Unfortunately nothing I tried did.
Can you please help me identify how I can delete these relationships so when I do the migration on my live site, everything will work fine?
> Unable to migrate an association from post #9572 to #9573 to a relationship "vineyard_contact": Relationship definition "vineyard_contact" not found.
> Unable to migrate an association from post #11170 to #11438 to a relationship "vineyard_twitter-account": Relationship definition "vineyard_twitter-account" not found.
> Unable to migrate an association from post #8983 to #9899 to a relationship "winery_twitter-account": Relationship definition "winery_twitter-account" not found.
> Unable to migrate an association from post #11066 to #11067 to a relationship "winetrail_twitter-account": Relationship definition "winetrail_twitter-account" not found.
> Unable to migrate an association from post #6848 to #10329 to a relationship "winery_wine-trail-member": Relationship definition "winery_wine-trail-member" not found.
> Unable to migrate an association from post #10486 to #10490 to a relationship "wine-trail_wine-trail-member": Relationship definition "wine-trail_wine-trail-member" not found.
Hi, I'll be glad to take a look. First, do you have a backup from before the migration? It's difficult for me to know what happened without being able to compare to the previous state of the site. Here are the migration error messages you saw:
1. #9572 to #9573
Post 9572 has been deleted. Post 9573 says "Invalid Post Type". Neither post seems to exist any longer, so you can probably disregard this error message. There's no need to migrate a relationship between non-existent posts.
2. #11170 to #11438
Post 11438 shows error 500 in wp-admin: hidden link
Any idea what's going on with this one? If the post should exist, we need to explore why there is a server error 500 in wp-admin. If the post should not exist, you can probably disregard this migration message. No need to migrate a relationship to a non-existent post.
3. #8983 to #9899
Post 9899 cannot be loaded in wp-admin: hidden link
Any idea what's going on with this one?
4. #11066 to #11067
Both of these posts are showing error 500: hidden link
hidden link
5. #6848 to #10329
Post 10329 shows error 500: hidden link
6. #10486 to #10490
Both of these posts are showing error 500:
hidden link
hidden link
But after the migration, the PHP code didn't find the correct child posts.
Feel free to create a separate ticket so we can investigate this in more detail if necessary.
Thanks for the reply. The only "backup" would be the actual production site. I can pull another copy of the production database to staging if you are interested in comparison before migration.
I had previously deleted every existence of twitter or wine-trail from Toolset whether it be post type, view, content template, etc., so I am surprised that they may still exist in the database somewhere with all those "unable to migrate" error messages. If you don't think there will be a problem with the 500 and other errors, then I'll just have to live with any db bloat.
Regarding the PHP code didn't find the correct child posts, I worked this afternoon on that and thankfully on my first change of the PHP code, it worked. So, I should be good when I update the production site. Please let me know if you want me to pull the production code to staging again for any investigation.
If you don't think there will be a problem with the 500 and other errors, then I'll just have to live with any db bloat.
To be clear, the 500 errors we discussed will not be resolved. Anyone who attempts to load these posts on the front-end of the site may see the same errors I experienced. I suspect these errors are being triggered by trying to access posts that do not exist in the database any more, but I'm not sure because I don't really know what these posts were, if they were supposed to have been deleted, etc. Can you tell more by looking in production and comparing post IDs?
Please let me know if you want me to pull the production code to staging again for any investigation.
It's up to you, if you feel the issue is resolved then no additional investigation is required.
I had previously deleted every existence of twitter or wine-trail from Toolset whether it be post type, view, content template, etc., so I am surprised that they may still exist in the database somewhere with all those "unable to migrate" error messages.
In the old system, post relationships were defined by postmeta entries in the database. Deleting a post does not necessarily delete its postmeta entries from the database, so if you deleted a post that was the parent of another post, then its postmeta entries would have been maintained. When the migration process looked through the postmeta table for parent assignments, it would have found this information and assumed the parent post exists and this relationship link needs to be migrated.
Can you tell more by looking in production and comparing post IDs?
All the 500 error links show Invalid Post Type on production.
Okay so the migration process did not cause the error 500s I noticed. The errors already existed on your site. I assume you have database access? Go into the posts table and research the posts causing errors in wp-admin. Search by post ID if necessary. Inspect the post titles and post types, and see if you recognize the posts, or have any idea why they would be causing errors in wp-admin.
If you're not sure why there is a problem with these posts, you can turn on server logs and try to get more information about the error. If you are not familiar with server logs, I can show you how to temporarily enable them. Go in your wp-config.php file and look for define(‘WP_DEBUG’, false);. Change it to:
define('WP_DEBUG', true);
Then add these lines, just before it says 'stop editing here':
ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');
Then refresh one of the pages in wp-admin. If any server-side errors are logged, this will create an error_log.txt file in your site's root directory. Please send me its contents. Once that is done, you can revert the changes you made to wp-config.php.
Sorry for the delay. I went through the database as you suggested. The post types that were identified were all that I supposedly deleted from the database via the Toolset UI like the twitter and wine-trail ones. So while I was there I deleted those post types from the database. Then I did the upgrade and migration.
All the lines in the log that were migration lines before now came as:
> Cannot return the number of found rows because the query was not instructed to obtain them.
It correctly identified the one legacy relationship and created the new tables, but nothing was migrated into the new tables.
So now I'm restoring the database. Unless you can think why migration didn't work, I'll probably just live with the previous behavior and sometime in the future clean up the database.
Well, this has not gone well. I had the database restored and then did the migration. It should have gone back to my initial run which had these lines:
> The toolset_associations, toolset_relationships and toolset_post_type_sets tables have been created.
> Relationship "vineyard_address-with-gps" between post types "vineyard" and "address-with-gps" was created.
> Connected #11181 (B-Happy Ranch) and #11491 (address-with-gps 11491) in the relationship "vineyard_address-with-gps".
Now instead of the Connected messages, all of those are still like the previous one with:
> Cannot return the number of found rows because the query was not instructed to obtain them.
So nothing has been migrated from the legacy format to the new tables. I cannot determine a way now to get it back to the state where it did the migration. Hopefully you have a suggestion on how to do the migration, otherwise I am going to have to somehow manually do all those connections myself.
Continuing since I can't seem to edit my previous post.
If it can't be determined why migration does not work, I do still have the log from when it actually did work. So like the Connected message I previously gave, that gives me the two IDs. Supposedly the tables toolset_associations, toolset_relationships and toolset_post_type_sets tables were created. I don't have toolset_post_type_sets, only toolset_type_sets. Maybe it is just a typo in the message?
Since I have the two IDs, if I can be told how to do an insert into the right table(s) with those 2 IDs, it will be a lot faster for me to do that instead of trying to use the UI to connect the data into the new tables.
I'm a bit lost because of the manual database manipulation. It sounds like you're saying you reverted to the previous database state, and now the migration process produces different results? If you'd like to provide me with a copy of the production database, I will be glad to run the migration on my own local environment, then investigate any error messages with my 2nd tier support team. If you'd prefer to continue direct database manipulation on your own, you can find the Post Relationships API documentation here:
https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/
Okay thank you, I was able to install the database dump locally and run the migration tool. My migration log is identical to your original file: migration messages_2018-06-16.txt, so let's start there. Are any of the failure messages in this log not caused by:
- "Post not found" because you manually deleted the post from the database before migration
- "Relationship definition not found" because the post type(s) were manually deleted from the database before migration
Hi Christian,
The database dump you have from production is before I deleted anything manually from the database. All of my migrations were done on my staging site after I pulled the current production db to staging. I am surprised to hear yours was like my first one since theoretically my last should have been the same as my first one too.
The deletions I did were just before the 06-22 log and then after seeing those "Cannot return the number of found rows" errors, I restored the database. Pulled again to staging and the migration at that point produced the 06-24 log which had those same errors.
Okay I see, I was assuming these messages were all related to the manual database manipulation but I was mistaken. It appears that these posts were deleted in the past. For example, the first two problems logged:
> Unable to migrate an association from post #9572 to #9573 to a relationship "vineyard_contact": Relationship definition "vineyard_contact" not found.
> Unable to migrate an association from post #9572 to #9575 to a relationship "vineyard_contact": Relationship definition "vineyard_contact" not found.
These two lines are logged because there is no post ID 9572 in the posts table. However you can also see that at one point, there was a post with ID 9572 because in postmeta for post ID 9573, the vineyard 9572 was assigned as its parent. The meta key _wpcf_belongs_vineyard_id = 9572, which was the legacy parent child relationship system. See the attachment.
The migration script goes through the postmeta table and finds all these parent post references, and tries to migrate those connections. However, post 9572 has been deleted, hence the log statements. There is nothing to be concerned about here, these can safely be ignored.
So let me rephrase my question. Are there any warning messages in the 06-16 log that are not caused by:
- "Unable to load posts" because one or both of the posts no longer exists in the database
- "Relationship definition...not found" because one or both of the posts no longer exists in the database
Please allow me to hopefully make this a lot easier to understand. At one time because Toolset was cool because you could have relationships, I had 4-5 what are today called Legacy relationships. I knew the new relationship way was being introduced, so I went through what I had and determined to make migration easier, that I didn't need any of those old Legacy relationships except ONE: vineyard to address-with-gps. As a result, I deleted via the Toolset UI post types, views, content templates, etc. that were of those old unneeded legacy relationships.
So any warning/error messages other than that one legacy relationship are not needed.
