Fix custom capability fallback

pods-framework / pods

The Pods Framework is a Content Development Framework for WordPress - It lets you create and extend content types that can be used for any project. Add fields of various types we've built in, or add your own with custom inputs, you have total control.

https://pods.io/

GNU General Public License v2.0

1.06k stars 265 forks source link

Fix custom capability fallback #7250

Closed JoryHogeveen closed 3 months ago

JoryHogeveen commented 5 months ago

Description

Currently if you leave the custom capability field empty it will fallback to post instead of the CPT name. This PR fixes this :)

Related GitHub issue(s)

Related #7218

Testing instructions

Create CPT with custom cap
Leave custom cap empty
Switch to role that includes the custom edit caps (edit_cpt/edit_cpts) but doesn't have the default edit_post and edit_posts caps.
Try to edit CPT post
You can't! :(
Apply patch
You can! :)

Changelog text for these changes

PR checklist

[x] I have tested my own code to confirm it works as I intended.
[x] My code follows the WordPress Coding Standards.
[x] My code follows the WordPress Inline Documentation Standards.
[ ] My code includes automated tests for PHP and/or JS (if applicable).

what-the-diff[bot] commented 5 months ago

PR Summary

Improvement to Capability Type Determination The change to the "*.php" file ensures that the system retrieves the correct capability type depending on the specific post type. This refactor adds a more accurate way to identify the right capability type rather than using a default 'post'.
Enhanced Specificity for Custom Capability Types The changes following the first are primarily focused on enabling the system to accurately fetch custom capability types when dealing with specific post types. This is another step towards better accuracy in capability-type identification in different scenarios.
Stability in Menu Display Choices There's no modification in the part of the code responsible for deciding if a given post type should be displayed in the menu or not. This means whatever your menu's composition prior to these changes will remain as it is, ensuring stability in user experience.

sc0ttkclark commented 3 months ago

I believe this was intentional because all CPTs by default use 'post' as the capability base: https://developer.wordpress.org/reference/functions/register_post_type/#:~:text=the%20posts%20icon.-,capability_type,-string%7Carray

I'm going to keep this as it was before except add a strict check on it so that if it was saved as empty then should force 'post' no matter what there.

sc0ttkclark commented 3 months ago

Oh wait I see this was capability_type_custom, carry on!