This support ticket is created Il y a 3 années et 10 mois. There's a good chance that you are reading advice that it now obsolete.
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.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
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:-
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.
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'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?
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.
