Skip Navigation

[Resolved] Capabilities

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

This topic contains 4 replies, has 2 voices.

Last updated by julieP 11 months ago.

Assigned support staff: Waqar.

Author
Posts
#1654921

I've been playing around with some ideas on a dev site using just Types & Forms and I've noticed that (sometimes) after a form has been submitted, these values are added to the wp_capabilities field in the usermeta table:-

wpcf_custom_post_type_view
wpcf_custom_post_type_edit
wpcf_custom_post_type_edit_others
wpcf_custom_taxonomy_view
wpcf_custom_taxonomy_edit
wpcf_custom_taxonomy_edit_others
wpcf_custom_field_view
wpcf_custom_field_edit
wpcf_custom_field_edit_others
wpcf_user_meta_field_view
wpcf_user_meta_field_edit
wpcf_user_meta_field_edit_others

Access is not installed so why is it necessary to add these fields?

What I find particularly troubling is that the values are added IN FRONT OF values that already exist in that field. Surely new values being added to any array anywhere in the database should always occupy the next position/s not push the existing value to the back of the queue? This behaviour potentially messes up any existing retrieval of information based on the (known) position of a value in an array.

#1655071

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi Julie,

Thanks for asking! I'd be happy to help.

It makes sense to add these special capabilities by default and without waiting for the Access plugin's activation, since, otherwise, they'll need to be added retrospectively for all existing users, when Access plugin actually gets activated.

As for the order of the capabilities, it is considered good practice to check for the existence of capabilities rather than checking whether they exist at a specific position or order.
( for example please check the source code of "has_cap" function at https://developer.wordpress.org/reference/classes/WP_User/has_cap/ )

WordPress, themes, and plugins can all add to the user's capability field, which is why relying on the order of a particular capability isn't safe or even future proof.

I hope this makes sense.

regards,
Waqar

#1656659

Hi Waqar

Many thanks for your quality response.

I'm not sure I agree that Toolset should be making an assumption (or a presumption) that Access will be activated at some point and preparing for it; after all there are other role management solutions out there that would have to add permissions retrospectively for existing users and if Access were not the plugin of choice for anyone, the wpcf- fields would remain and be superfluous.

Just out of curiosity and for those that want to use a different solution, is there a filter/action hook that could be implemented to prevent the behaviour in the first place?

#1656957

Waqar
Supporter

Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Hi Julie,

Thanks for writing back.

I stand corrected and my further testing and research show that those Toolset capabilities are not dependant on Toolset Forms or Access.

On a clean WordPress install, as soon as you'll activate the Toolset Types plugin, your admin user account will be updated with those capabilities.

The code audit confirms that these capabilities are used by the Types plugin to control which WordPress user can or can't access different Types features and admin menus, like managing post types, taxonomies, post custom fields, and user custom fields.

For this reason, removing/blocking these plugin capabilities is not recommended.

regards,
Waqar

#1658347

Ah OK - that changes things a bit then. Thanks for clarifying this for me.