search

bobbingwide / oik-types

oik custom content type manager
http://www.oik-plugins.com/oik-plugins/oik-types/
GNU General Public License v2.0
1 stars 0 forks source link

Support for WordPress 4.6 #4

Closed bobbingwide closed 8 years ago

bobbingwide commented 8 years ago

In WordPress 4.6-RC1 and WordPress 4.6-RC2 ( and most likely the beta versions ), if oik-types has been used to override a custom post type (CPT) and then the plugin that registered the CPT in the first place is deactivated ( or otherwise no longer registers the post type), then the subsequent post type that is registered has a cap property which is an array. Because WordPress now expects this to be an object the following Notices are produced on admin pages.

Notice: Try to get property of non-object in wp-admin\menu.php on line 138
Notice: Trying to get property of non-object in wp-admin\menu.php on line 139
Notice: Trying to get property of non-object in wp-admin\menu.php on line 140
Notice: Trying to get property of non-object in wp-includes\admin-bar.php on line 648

Steps to reproduce

  1. Activate Jetpack's Custom Content Types module and enable Portfolio projects
  2. In oik-types override the definition of the jetpack-portfolio post type
  3. Deactivate Jetpack, the Custom Content Type module, or disable Portfolio projects
  4. Visit the Dashboard.

Note: I was using Jetpack 3.8.2. I expect the problem could be recreated using a different plugin that registers any original CPT that is overridden by oik-types.

Workaround

What we want to do is find a solution for oik-types that'll work regardless of the WordPress version.

bobbingwide commented 8 years ago

The problem is due to the fact that the $post_type_args array passed to register_post_type() contained a key called cap which contained the array of capabilities. This didn't cause a problem in WordPress 4.5, but does with the new code in 4.6.

Proposed solution

My current conclusion is that this problem was caused by misuse by oik-types and is not a bug in WordPress. So, since

we can remove the 'cap' key from the post_type_args array and WordPress will create the capabilities.

....Although they may not be the ones that were first thought of. So maybe the key should be changed from 'cap' to 'capabilities'. if it's being passed. So long as we don't break backward compatibility with 4.5.