map_meta_cap was called incorrectly error?

[Michael Cropper]

This is a very odd error that I haven't been able to find the underlying cause of or the solution yet. 

Errors showing in various places within the WP Admin;

-----

Notice: map_meta_cap was called incorrectly. The post type shop_order is not registered, so it may not be reliable to check the capability "read_post" against a post of that type. Please see Debugging in WordPress for more information. (This message was added in version 4.4.0.) in /public_html/wp-includes/functions.phpon line 4147

Notice: Undefined property: stdClass::$ID in /public_html/wp-admin/includes/dashboard.php on line 491

Notice: Undefined property: stdClass::$post_type

-----

This has occurred when moving a site between servers. These errors only started showing when I went through the usual debugging steps after seeing some odd behaviour. The site has been moved between so many low quality hosting providers in the past, that I had to manually strip out loads of environment specific settings that had been bundled in with core WordPress files (i.e. a php.ini file hidden in the /wp-admin/ folder and various .htaccess files that had been placed within multiple folders etc. ). So this may be something somewhere in here that has been missed. 

I'm fairly sure that once I know what these two errors are caused by, and how to fix them, that all the other weird things I'm seeing will also be solved. 

Debugging process so far;

 - Updated everything (Core, Themes, Plugins)

 - All plugins disabled

 - Using default 2017 theme

 - WordPress PHP files replaced with a fresh install

 - DB uploaded (I think the problem is in here somewhere - I can't see how it could be anywhere else given the above?)

 - Tested multiple PHP versions to rule that out - same issue regardless of PHP version

 - I was seeing a "Submit for Review" button on WooCommerce Add Product page, so tested this solution, http://www.techextensor.com/fixno-publish-but-submit-for-review-button-displayed-to-site-admin/ - and noticed that the DB tables were half InnoDB and half MyISAM, so I updated everything to use MyISAM and ran a table repair on all the DB tables. I then also 

 - Ran a database cleaner plugin, https://en-gb.wordpress.org/plugins/advanced-database-cleaner/, on the off chance this would clean up anything weird that was going on

Not really sure what else to try to get this working? 

Running a completely clean WP installation works perfectly as normal. I just don't want to go to the effort of re-building something, as this is probably some weird setting / odd custom line of code somewhere that someone has put in that is breaking everything. 

Any pointers appreciated

Regards,

Michael

[Mike Little]

Hi Michael, 

Assuming the shop order post type is not declared in the theme (you mentioned you've switched to 2017), it could be that the code triggering the message is called too early. So that the post type hasn't been registered by the time this code runs. 

I'd check on which action the post type is registered, and on which action/filter this code is run. 

Also check whether some code is accessing the DB directly with a query, rather than using the WordPress API. That's usually the wrong thing to do, but could be added if trying to do something too early. 

Best regards,

Mike Little
WordPress Specialist
https://mikelittle.org
Sent from my 'phone, please excuse any brevity and any auto-correct mistakes.

--
See the group blog at https://mwug.uk
 
You received this message because you are subscribed to the Google
Group "Manchester WordPress User Group".
 
To post to this group, send email to
manchester-wordpress-user-gr...@googlegroups.com
 
For more options, visit this group at
http://groups.google.com/group/manchester-wordpress-user-group
---
You received this message because you are subscribed to the Google Groups "Manchester WordPress User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to manchester-wordpress-user-group+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Cropper]

There is absolutely no custom code running anywhere. Blank WP install + DB migration results in these errors. When I've been inspecting the database, it looks like all of the primary keys and auto increments have been disabled when importing the database oddly. Looking at the import sql file, there also seems to be a large mixture of character encoding types which I have a feeling are the cause of the issue. Not sure how to get around that though if certain tables are encoded in one format, and other tables are encoded in a different format. 

I just tested updating the SQL file so that all the character encoding is the same for all tables on the import, but this didn't work. Not surprising really since they wouldn't match, but thought it was worth testing. 

The more I'm looking into this, the more I am starting to think that the only safe way to get the DB back to a standardised setup is for a bit of grunt work migrating everything over manually. 

[Mike Little]

Seems you have three different things going on here: 

Firstly: The message "post type shop_order is not registered" means that some code has loaded a post record rom the DB with that type and tried to check permissions on it, yet the post type doesn't seem to be registered. This should be unrelated to the DB issues below.

Secondly, the lack of primary key and autoincrement is a nightmare! It means that records get created with and ID of 0 and then WordPress thinks everything is invalid, and can't save anymore, and lots of other cascading issues from that.

I used to see that when using cpanel-like tools to do db dumps instead of doing them myself directly with mysql or phpmyadmin. You can fix it manually:

For each table that should have primary keys:

  Substitute the table creation part of your db dump with a working one that sets up the autoincrement and creates all the indexes. You'll need to manually set the autoincement value to be one higher than the current highest record id.

  Then import the dump (assuming it does drop table)

Thirdly, the mixture of different encoding types will likely only affect the user input text fields.  So, post title, post content, taxonomy terms, some settings, etc. It shouldn't be causing the issue about post_types. 

  There are some plugins still around that will convert to UTF8 for you. Note they are all very old (6-8 years or more) as it was a long time ago WordPress switched. 

Best regards,

Mike

--

Mike Little

WordPress Specialist

Web: mikelittle.org

Skype: mike.little.zed1

Twitter: @mikelittlezed1

LinkedIn: linkedin.com/in/mikelittle

Newsletter: https://mikelittle.org/subscribe

Founder and Director

Zed1.com Limited

https://zed1.com/

Registered in England & Wales, no. 6745562

[Michael Cropper]

Thanks for all the info Mike. It all sounds like quite a lot of messing around (more than it really should be for such a simple task of migrating a site). It's really odd is this as both the export and import are being done via phpMyAdmin, the database export does include the primary keys / auto increments, yet things fail when uploading. If I'd have to guess, I believe there may be some version differences with the phpMyAdmin which is resulting in this odd behaviour. I've seen odd things like this happen when trying to import older WP databases into newer WP instances. **goes to check ** Looks like the export is running on phpMyAdmin v. 4.3.8, which is over 3 years old, and the import is running the latest version, which I wouldn't be surprised if this was causing a few of these strange behaviours. 

With you mentioning about the character sets, one of them I have seen in the DB export file is the latin1_swedish_ci one which hasn't been used since 2007! It's amazing how the site has lasted this long without showing signs of breaking until now. I guess things often only get uncovered though when they get poked a little. I know some of the files in the uploads folder in WP go back to at least 2008, so I'd have to guess that the DB (and entire site) has been migrated a good number of times between hosting providers in this time with tweaks along the way without ever being cleaned up properly. 

With all of this, while I'm sure I could go to the effort of testing the approaches you mentioned above, I have a feeling that this may not resolve all the issues - and since the DB export file is almost 100,000 lines long, it may take a while to trawl through this. So it's likely going to be a lot faster to to a bit of grunt work copying and pasting everything over as it isn't a huge site. 

Thanks for help on this. I was banging my head against the wall wondering what this could be. Never come across odd errors like this before. 

[Michael Cropper]

Not wanting to be defeated by this, I finally found what the underlying problem was. It looks as though the previous database for some reason allowed duplicates in a couple of the tables (I'm not sure how this is even possible! But hey.) so when the phpMyAdmin was exported then imported, a couple of errors flagged up on some logging tables that some plugins had added. As everything appeared to work even though these couple of errors flagged up, the import hadn't actually completed due to the way phpMyAdmin processes the imports. 

In essence, phpMyAdmin, 1) Creates the tables 2) Imports the data 3) Adds the Primary Keys to the tables, if there is no data that would invalidate a primary key 4) Adds the Auto-Increments to the tables. 

So due to the odd data that had somehow got into the old database, the final steps #3 and #4 above were never actually completing. So while the site appeared to work, it didn't. I also had to fix those odd character encoding issues too. 

Everything else was then cascading from this issue. To resolve I just did a bit of smart searching through the enormous database file and deleted all the problem causing logging tables and this worked perfectly on the next database import. 

Solved :-) 

Thought it was worth sharing in case anyone else experiences this in the future.