Lots of PHP notices

Hi,

I have “WB_DEBUG” setup to true at all my development copies of WordPress from very begin. I do not see any PHP notices at published version.
There is something special at your WP installation possibly. According to your information notice goes from WordPress core file, not mine one. Could you please find in your debug info, line # and file name which belongs to the “User Role Editor” package.

Hi Vladimir,

Well, I defined new roles and new capabilities.=, but I wouldn’t call that special. The notices do not appear in the core User Role Editor settings, but only when clicking the “Capabilities” link under a specific user.

They are all in the “Custom capabilities” section of checkboxes in the screen. The “Core capabilities” checkboxes are all fine.

They might be Xdebug notices, but I guess you most probably use a debugger too while developing. I’ll check that and report back.

For now, the URE files and lines are:

../class-ure-lib.php:973
../ure-user-edit.php:119
../class-ure-lib.php:180
../class-ure-lib.php:87
../class-user-role-editor.php:382

In total I have 48 of these notices.

I confirm that the notices are there even without Xdebug. I just checked on a different server that does not have Xdebug installed.

Xdebug is nice as it shows the full call stack for the notice. Vanilla PHP only shows the final notice.

Here are all the notices with full call stacks straight from the URE capabilities page (copy/pasted the html code):
https://dl.dropboxusercontent.com/u/884148/xdebug.html

And the same ones for the other server without Xdebug:
https://dl.dropboxusercontent.com/u/884148/vanilla.html

Just open those html files in a browser (they lack a doctype and head but Firefox and Chrome display them just fine).

If it is test database without critical data, may be you may send me the link to download its dump in order I can make some tests myself?

All notices are from ‘map_meta_cap()’ function, where WP tries to get $args[0], 3rd parameter value, while function has 2 named parameters only.
‘map_meta_cap()’ calls itself with extra-3rd non-documented parameter at line 1150:

$caps = map_meta_cap( 'edit_post', $user_id, $post->ID );

As I do not call ‘map_meta_cap()’ at URE plugin directly (I call ‘user_can()’ with 2 valid parameters), that problem could be wider when it seems from begin.

For some reason WP could not get valid post object for using at line 1150…

WP checks if $args[0] exists at line
1006

if ( 'edit_user' == $cap && isset( $args[0] ) && $user_id == $args[0] )

But it doesn’t make it further in the code in assumption that such call for ‘META’ capability could not occur.
Just assumption:
Look on possibility that WP looks on the one of capabilities you created as the ‘meta’ one for the custom post type, and goes to the wrong direction at map_meta_cap() code for that reason.

I’d love to help further but I can’t quite offer you the DB.= as it has sensitive data. I posted above full call stacks from Xdebug (in case you missed those).

You may try to reproduce it by creating a few new roles and a few new caps. Various subsets of the new caps (mostly overlapping) are assigned to the new roles but also to the core WP roles. Create users that have a single role equal to one of the new roles which has new caps as well.

In my case, those users which cause these notices have these equivalent roles and caps:

Role:
Customer

Core caps:
read

Custom caps:
edit_products
do_review
read_private_products
read_private_reviews

Hope you’ll be able to figure it out. I can try to help with testing or provide more info if you wish.

Thanks.
Try to remove self-created capabilities for custom post types with singular name, like ‘edit_review’, ‘edit_answer’, etc., and look if notices will go away.

Do you see ‘edit_post’ capability at standard WP capabilities set? No. So you should not create singular type capability for your custom post type, in case you define it as the custom capability for the custom post type, e.g. ‘review’, ‘answer’, etc.

Read this post, for more details:
https://shinephp.com/capabilities-set-for-custom-post-type/

Not sure whether you got a bit defensive regarding singular caps, but I created the caps using the available WordPress documentation:

https://codex.www.ads-software.com/Function_Reference/register_post_type

( see “capabilities” section, around mid-page )

which, as you can see, clearly shows singular caps of the kind “edit_post”, “read_post” etc. My setup has been working fine without any problems for months, except the notices triggered by your plugin.

Are you saying that the above documentation from WordPress is wrong and that singular caps are now deprecated? (wouldn’t be the first time that the WP docs are wrong or out of date, I actually think they are the worst docs I’ve ever encountered as a dev)

Re-read the ‘Capabilities’ section from the link provided by you. Pay special attention to the ‘meta’ capabilities and the last phrase about them – meta caps would not be generally granted to users or roles. But you included them to the roles. This is the most probable reason of notices you get, not from the User Role Editor, but from the WP core.

Quote: “By default, seven keys are accepted as part of the capabilities array:
edit_post, read_post, and delete_post – These three are meta capabilities, which are then generally mapped to corresponding primitive capabilities depending on the context, for example the post being edited/read/deleted and the user or role being checked. Thus these capabilities would generally not be granted directly to users or roles.”

“would generally not” is hardly a well defined rule … what is that even supposed to mean? Sounds like there are exceptions but nothing definite is said (the word “generally” predominates).

My question still stands: are singular caps deprecated? Do I need to create them at all?

You asked whether I see “edit_post” in WP core caps as set … I actually don’t see it at all, it’s nonexistent in the list shown by your plugin.

I unchecked all the checkboxes for singular caps from all the roles and all the Notices are still there.

The URE plugin is the only piece of code in my setup that trigger these notices; the call stack I attached a few posts above shows that. It might not be at fault per-se; I’m still confused regarding the singular caps. See my question above.

The answer on you question about singular caps is in your last sentence: you don’t see ‘edit_post’ at URE plugin page as it is not included at any role. It is defined by WP for internal use only. The same is for any other capability which name corresponds the rool WP uses to build custom post type meta cap.
My opinion – you do not need to use singular (meta) caps directly, use so-called “primitive” capabilities only.

You see PHP notice not because of singular cap is turned on, but because of it is included into role apparently. URE tries to check if user has such cap or not, but WP process such request not accurately as developer didn’t supposes such kind of calls.
Make DB copy and try to remove singular caps and check if it change something except PHP notices at URE. If you do not use them directly in the custom code, you should not have any problem.

In my last message I said that I did unset all singular caps (i.e. none of them are granted to any roles) and the notices are still there.

Also, although I appreciate your input, I’m still not 100% sure about what you mean by “remove singular caps”. Do you mean to delete the singular caps completely?

If yes, that would contradict the WP docs that I posted previously which show that singular caps should be created but generally not granted to users or roles.

If no, then I already said that none of the singular caps are granted to any roles or users and the notices are still there.

There is no separate storage for user capabilities. Capabilities are stored in the roles. Role is PHP array of capabilities
array(‘read’=>1, ‘edit_review’=>0, …). Some are turned on, some are turned off, But all of them are still there, until you remove/delete unused capability.
You unset singular caps, but they are still in the roles, while you see them in the “User Role Editor”.

Doc page you mention is about creating capabilities programmatically when you register custom post type. This page is not about giving access to those capabilities to the roles and users. When you create capability in the “User Role Editor” you work with permissions system which helps WP to decide if allow or prohibit operation to the user. Needed capabilities are existed/registered already in WP. There is no need to duplicate meta-caps in roles. Work with primitive capabilities only.

Our discussion goes to the circle. I have suggested you to check, that you see notices from WP core because of improper use of User Role Editor to create manually custom post type meta (singular) caps. If you do not wish to follow it, it is nothing I can do.

May be it has sense to test if capability have the same name as existing meta-cap and do not allow to create and show it in the roles, in the future. But the task is not trivial for the 1st glance.

P.S. You are not alone. WooCommerse plugin registers capabilities the same way and I see the notices from capabilities.php you mentioned above. So I have the own playground to test now.

Thanks for the information.

Our discussion goes to the circle. I have suggested you to check, that you see notices from WP core because of improper use of User Role Editor to create manually custom post type meta (singular) caps. If you do not wish to follow it, it is nothing I can do.

I think I went to the length of posting full call stacks of the code for you to see exactly what’s going on. I also un-asigned all singular caps (that’s what I thought you meant). I’m actually trying to follow your advice … You give lengthy replies, which are much appreciated, but have not really answered my question or if you did, it’s still confusing to me, maybe I haven’t had enough coffee or sleep. So once again:

Are you saying I should DELETE the singular caps using URE? (i.e. select the cap, click delete). A yes/no answer would be great.

The WP docs are confusing too as they suggest that singular caps should be created, but not generally granted to roles. That’s exactly what I did, i.e. created them but not granted. You seem to be saying something different, but I’m not 100% sure.

As a side note, I disagree that caps are stored in roles. The same cap, e.g. “edit_posts” can be granted to any role, and also to multiple roles simultaneously. You probably mean the granting of caps, but the cap itself is standalone.