Post Type change issue! Help!

[turnkeydigital]

Hello, I’m opening a new ticket after finding another one of our sites with this same issue. Here is the original thread, and Charlie mentioned the Post Type change issue coming from Pro5 to Pro6 Layout Builder archives layout completely gone

This time, the error occurs on turnkeydigital.com, which is our agency site. The layouts being used were on this page: https://turnkeydigital.com/our-work/precision-vision/

Just to confirm, according to this: https://theme.co/docs/pro5-to-pro6-migration I need to rollback my database to use Pro version 5? What about the Wordpress version 6.2 compatibility error? This seems like a mouse wheel of issues… rolling back to Pro5 will cause errors with my WordPress 6.2, but not doing this rollback will completely wipe out all of my layouts. Help!

[tristup]

Hi @turnkeydigital,

I have checked and found that you are using the Pro version 6.2.6, I would suggest you update it to 6.2.7 and check if that resolves your problem or not. If not, please provide login credentials for your site in a secure note to examine it further, including:

– WordPress Site URL & Login URL
– WordPress Admin username/password

To create a secure note, click the key icon underneath any of your posts.

Thanks

[turnkeydigital]

Hi there,

I have updated to the latest version and that did not solve the issue. I believe this issue occurred after updating from Pro5 to Pro6. Please see last post for reference.

I’ve included a secure note with credentials in my last post. I’d like to mention that this is our agency site and is quite a high priority. We also have about 100+ sites using Pro and I’m concerned with running into this issue again using this theme and updating.

[charlie]

If the site is already on WordPress 6.2 it might be a little dicier. Try the following.

• add the part about CS_MIGRATE_UNTYPED_USE_RAW_UPDATE to your wp-config.php
• Rollback to your Pro5 database. Keeping the Pro6 files as your theme though (so your site doesn’t crash).
• Next page view you see should run the migration. After that you should have layout data back.

Let me know if that helps.

[turnkeydigital]

Thanks for the quick reply, Charlie.

Yes, the site is already on Wordpress 6.2, which is where my concern was with rolling back the Pro database.

Whats the best way to do this while keeping the Pro6 files, rolling back to Pro5 database, and not disturbing the Wordpress version? Should I replace only certain folders?

[charlie]

If you are already running Pro6 don’t change any folders. Rolling back will get your Pro5 data there, but will still have Pro6 running which will not crash in WordPress 6.2. And then when you load Cornerstone or you homepage the migration will run. Adding the wp-config.php part first is the important part so that you don’t run the migration that didn’t work for you.

If your backup contains theme files, then you might just have to be ready to replace the themes/pro folder with Pro 6.2+ when you do the backup.

It attempts to run the migration every time the app loads. You might get lucky and adding the wp-config.php part and then going to the App fixes the issue too.

Let me know if this helps.

[turnkeydigital]

Okay cool. I’ll try your approach.

Follow up question… I created a stg environment from an older backup of the site that is running Pro5 and WordPress 6.1.1. Obviously I would like to update this to all current versions, but I’m wondering if I can get around this whole thing by adding that to the config file before I update? Would that work?

[turnkeydigital]

I should add - the STG environment is all back to normal, so this definitely tells me it’s the pro5 to pro6 migration issue. Since we have a ton of sites using Pro, many of them needing updates from Pro5 to Pro 6, can I get ahead of this by simply adding in the line in wp-config file before I attempt any manual updates or we run some auto updates?

[turnkeydigital]

UPDATE:

I created a staging environment from a backup that was running Pro5 and Wordpress 6.1.1. I added the suggested definition to the wp-config file, then ran the Theme update followed by the WordPress update. This has fixed the issue! I then pushed my STG back up to our live site and we are good to go.

Do I need to keep that definition in the wp-config file or can I remove it now? Also, do you suggest we add this definition for any site currently using Layouts in Pro5 needing to update to Pro6?

[charlie]

Awesome glad this worked. Once the migration has ran, you can remove the definition from you config. If you had the issue on one of your environments I would just add that definition everywhere to be safe. I have a feeling I will be setting that migration strategy as the default in the close future anyway.