-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Capabilities setting/editing for post types and taxonomies. #390
Comments
Is there a workaround to this? I saw the pre-filtering for the taxonomies here: https://wordpress.org/support/topic/want-to-manage-the-custom-taxonomy-capabilities/ and was wondering if something similar existed for post_type? Basically I just want to fade out the "add new" button for a couple of post types, as explained here: |
Yes, for majority of the hooks that we add to our plugins, especially when related to details for post types or taxonomies, there's a similar hook for both. For hooking in and amending arguments for a post type, please refer to https://github.com/WebDevStudios/custom-post-type-ui/blob/1.5.7/custom-post-type-ui.php#L441-L453 |
@tw2113 Hi yes, I saw that, however I am not quite sure about all the input parameters and usage of that hook. Could you maybe provide an example for a cptui_pre_register_post_type filter as needed in functions.php as you have done here for taxonomies? -> https://wordpress.org/support/topic/want-to-manage-the-custom-taxonomy-capabilities/ |
It's going to be pretty much the exact same structure. For a custom post type, change out "some_slug" to be the one you want this to affect. If you want to affect all of them, then that wrapping if statement can be removed
Adjust as needed from here. |
I just figured it out myself ...
Cheers! |
It's time to get this merged in. |
After internal discussion, we are going to leave this as an extension of CPTUI instead of merging into core. The reasoning is because majority of users don't need it, and unless they know what they're doing, shouldn't touch the settings. Also the amount of settings needed would add more visual noise to what is already an admittedly long list. |
Picking up what was discussed at tw2113/custom-post-type-ui-capabilities#3, I think there are still a good number of benefits to integrating this separate plugin (https://github.com/tw2113/custom-post-type-ui-capabilities) into the main plugin given how lightweight it appears to be. Currently, this add-on/extension plugin is very difficult to find when it really could be quite nice/useful for those that need it while it's also not really being kept up-to-date with the rest of the plugin since that then needs to be done separately (when those updates, like minor UI adjustments, would otherwise be really quick and keeps it looking correct & working well.) Meanwhile, the concern about visual noise & how most users don't need this feature (while a valid concern) could be alleviated by having something like "Enable Capability Mapping" as a checkbox which then toggles these additional settings on the page. Users that don't need it just see it as one more checkbox in the list of settings that they can ignore since they don't need it (not unlike "Custom Query Var" setting & similar where arguably most users don't need it) while those that do need it then have it right at their fingertips rather than assuming something like this isn't available unless they happen to stumble across this on the Help/Support page of CPT UI (and are then also okay with a non WP.org directory plugin [making updates more of a concern] that then might appear to be abandoned or otherwise have questionable support [per this part of things maybe not having any updates in years]) with it seeming to be nearly impossible to find outside of that one page that's likely overlooked. I'm just thinking this decision could potentially be reconsidered & thanks for hearing me out. 😊 |
No description provided.
The text was updated successfully, but these errors were encountered: