search

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

After setting a custom capability access is revoked for single install admins #7218

Closed JoryHogeveen closed 7 months ago

JoryHogeveen commented 8 months ago

Description

Once you've saved a CPT Pod with a custom capability this capability will keep on being used, even after you switch back to the default Post or Pages capabilities.

If you set a custom capability then the whole access is revoked if you do not assign it to the admin role. If you have set a custom capability and then select the Post again you will be able to list the CPT but not edit or anything.

The capability value keeps being saves in the CPT, even though it's not set on a custom capability anymore. This isn't a problem but should be fixed when registering the CPT.

Version

3.0.8

Testing Instructions

  1. Create CPT in a single WP installation
  2. Select custom capability.
  3. Notice you'll not be able to to view this CPT anymore since you do not have this capability.
  4. Switch back to Post capability.
  5. You are able to list but not edit the CPT.

Possible Workaround

~You can manually remove the capability input and it will work again.~

Nope, this doesn't work either... can't undo this for some reason...

sc0ttkclark commented 8 months ago

Super admin checks are not utilized unless on multisite -- so even if you are an admin of a single site, you don’t automatically get access to any/all caps. That’s a WP quirk IMO.

We could perhaps do a check when they set a cap there to warn them that their role doesn’t have that cap yet, but I don’t think there’s anything we could do there besides possibly some workflow improvements like:

  1. Notice: we could show a notice next load of the pod edit screen for a CPT/CT when cap is not set on the current user role
  2. Notice: we could add HTML field that shows a notice below the cap setting that shows only if the value of that cap is not in the list of the current user role’s caps
  3. Action: we could add checkbox field that shows a notice below the cap setting that shows only if the value of that cap is not in the list of the current user role’s caps and allow them to check it to auto-add the cap to the current user role
JoryHogeveen commented 7 months ago

While your assessment here is totally valid, it's not directly related to the bug here so probably belongs in it's own issue (related to this one).

The issue here is that when I revert the capability to "post" this change isn't done. For some reason it still not accessible anymore and I cannot find out why/where this goes wrong. The register parameters seems correct.

sc0ttkclark commented 7 months ago

I didn't realize resetting there wasn't working. Can you confirm that the value remains post on reload and that the pod config did change over?

JoryHogeveen commented 7 months ago

Yes I already checked this, the change does seem to reflect the Pods register options but it looks like it's maybe modified afterwards based on the custom value? The custom value isn't removed, it's just hidden after you select "post" instead of "custom". The custom value also keeps being saved in the Pod object.

sc0ttkclark commented 7 months ago

Found the culprit. Basically this field is a text field with a default value. The default value kicks in when null is received from the config. But when you save an empty text field option it will automatically be removed from the postmeta table. At that point, it's not an empty string as when you saved it -- it becomes a null.

The solution here is to stop using the default value and move that into the placeholder text instead.

Note: Switching to post/page capability types would still work.