Huge Performance Issues

@rafalosinski If the Capabilities screen shows any post types or taxonomies configured for Type-Specific, Taxonomy-Specific or Detailed capabilities, their capabilities arrays are examined on each plugin execution. If those capabilities are the same as the standard “post”, “page” or “category” type, a type-specific equivalent (“edit_things” or “manage_sections”) capability is defined instead.

The processing here is on post type and taxonomy definitions, not posts and terms. So there’s nothing in the logic and intentional execution that would be impacted by the number of rows in your posts, terms or user tables. But maybe there’s an unintended side effect causing a table scan on your installation.

Whatever the cause, since this is causing you such a drastic issue, try disabling those post type and taxonomy settings on the Capabilities screen. Your other plugin or theme code will then be responsible for defining capabilities for each custom post type and taxonomy. Note that the Capabilities UI will not display Reading, Editing, Deletion, Management or Assignment checkboxes for a custom type or taxonomy if its defined capabilities are defaulted to “edit_posts”, “manage_categories” etc.

There is not currently a plugin setting to bypass the force_distinct_post_caps() and force_distinct_taxonomy_caps() functions entirely. Little code will execute there once you’ve disabled the type and taxonomy settings, but for an even leaner and safer execution you could write your own code snippet to hook into the ‘init’ action and call remove_action for the “_cme_cap_helper” function at priority 49. This will cause the Type-Specific, Taxonomy-Specific and Detailed capabilities settings to be ignored (with the same implications I just described).

• This reply was modified 2 years, 4 months ago by Kevin Behrens.