New features and improvements
New API to register tabs in the Access Control page
You can register a new tab in the Access Control page by using a short filter:
add_filter( 'types-access-tab', 'prefix_my_tab' );
function prefix_my_tab( $tabs ) {
$tabs['my_tab_slug'] = __( 'My tab title', 'my-textdomain );
return $tabs;
}
Then you can populate the tab with your own sections by reusing the tab slug in a modified filter that comes from the already existing types-access-area one:
add_filter( 'types-access-area-my_tab_slug', 'prefix_my_tab_area' );
The callback prefix_my_tab_area returns the same kind of data that you could provide to the already existing types-access-area hook.
Separated Access Control tabs for Types fields and CRED forms
Using the above new API, Types and CRED will register their own tabs in the Access Control page:
Improved admin pages by using h1 HTML tags for titles
This has been recommended by WordPress for some time now, and we finally adjusted our header tags.
Bug fixes
Fixed the Access Control tab invalidation
Some actions performed in a tab on the Access Control page can have effects on other tabs. For example, adding, changing the level or removing a custom role means that this changes need to propagate to all the other tabs, as the affected role will surely not belong to the same level. Creating a post groups, also, will produce a warning on the post type section in the Post Types tab.
We evaluated which interactions affected other tabs, and introduced an invalidation mechanism. As tabs are loaded on-the-fly using AJAX, once a change affects another tab, that tab will be marked, and when getting back to it, it will be refreshed to reflect the changes.
Fixed a compatibility issue that was hiding the button to apply post revisions
Difficult to catch, it seems one of our scripts were hiding the button to apply post revisions.
Fixed a problem when checking capabilities of specific users
By default, Access hooks into the WordPress capability checks, and returns the adjusted capabilities set. Unfortunately, we were assuming that every time a capability was checked, it was being asked whether the current user could perform an action.
That means that generic checks against other specific user were mismanaged, and returning erratic results. We reviewed our whole code and fixed it.
Fixed a usability problem with taxonomy term capabilities
Access extends the default capabilities for managing terms, but we used to group some of them as bundles: enabling editing was affecting creating and deleting. We reviewed those interaction and now they make much more sense.