[Resolved] Broken Access to Post Type

[Author]

Posts

[josephG-4]

I am trying to: Restore a user role's access to a specific post type after the client reported they can no longer access the post type.

Link to a page where the issue can be seen: Admin side.

I expected to see: After my client reported a user on their end suddenly cannot access a post type they've had access, I created a test user with the appropriate user role to test. I have checked the permissions for the post type and confirmed the user role has appropriate access. I logged in as the test user and expected to see the post type listed in the admin nav and to be able to access it.

Instead, I got: The post type is not listed in the admin navigation and I get "Sorry, you are not allowed to access this page." if I attempt to access the post type directly.

I have disabled the plugin and re-enabled it. I have turned off Access control for the post type and turned it back on. I have deselected every permission for the user role and reselected them. I have switched the test user to different user roles that appear to have access to the post type, but experienced the same issue. The post type itself seems to be locked out from Access control. Is there a cache I can clear or something I can do in the database?

I updated the plugin on our staging environment to check if that was the issue. No file changes have occurred on the production site in a while, other than automatic updates of WordPress. The issue came up seemingly out of the blue.

[Minesh]

Hello. Thank you for contacting the Toolset support.

Toolset offers the reset the access permissions but by doing that it will reset all Access permissions.
- Do you want to do that? If yes:
Please follow the following doc:
=> https://toolset.com/course-lesson/how-to-reset-access-settings/

If you do not want to reset the access permissions, then I would like to know to what post type you assign the access permission and I will require admin access + the user access details using which I should login and check the access permission for both admin + user.

*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.

I have set the next reply to private which means only you and I have access to it.

[Minesh]

Thanks for the admin access details.

I login to the admin and can see the issue with the test toolset user you shared. I even tried to create a new role and check and it's still not working with that role even-though I assigned the permission to access the post type for that new role.

I can see you only installed the Toolset Access plugin. How you created the post types? Using any other third party plugin? If yes:
- Can you please tell me using what plugin you created your post types.

In addition to that I can see you are using lots of outdated plugins on your install. Can you please update ALL plugins to it's latest official release version. Also, Please update WP to latest release 5.5.1.

Also, We just published the Toolset Access plugin version 2.8.8. Can you please update that as well.

Once you update everything - In order to minimize the cause of the issue and to check there is no conflict between thirdparty plugin or theme you are using:
Could you please try to resolve your issue by deactivating all third-party plugins as well as the default theme to check for any possible conflicts with any of the plugins or themes? - Do you see any difference?

Also, The issue I can see is with only "Safer Choice Ingredients" role. So, I tried to change the role name but no luck and I cant able to access the site now. Maybe the security plugin or something has blocked me.

Can you please setup your staging site and follow the update process and compatibility check and get back to me once you done with evereything.

Can you please activate error log and also see if you see anything with your error logs?
More info:
=> https://toolset.com/documentation/programmer-reference/debugging-sites-built-with-toolset/#php-debugging

[josephG-4]

Hi Minesh,

I have restored the staging site to the state prior to your changes. Feel free to dive back in and debug further if you have any other checks to run

The post types were created manually by our previous developer. They are defined in /wp-content/themes/dexter/includes/cpts.php.

I do not see an available update for 2.8.8 so I am unable to update at this time.

Regarding the long list of outdated plugins and outdated core, I'm aware, but unfortunately there is a pending change in development blocking cleaning up that list. Once that pending change has been pushed to production and there is no risk that updating plugins will harm production, I'll go through on staging. In the meantime, I will consider whether I am able to update and test as you described locally or whether I have another environment available for that. Please keep this thread open.

[Minesh]

On this page: hidden link

You should always click on the button "Check for Updates" to get latest updated plugins. I can see now Toolset Access version 2.8.8.

Yes, you will first require to update everything (corer, plugins,themes) and once you have that version, please ping me and I will see what I can do next.

[josephG-4]

Adding to this thread to avoid cleanup by the support cleanup bot. I will notify here when I have completed the updates mentioned above.

[josephG-4]

Hi Minesh,

My customer reported a new issue related to privileges that seems to be related to Access. So I went ahead and ran all plugin updates on the staging site.

I was still experiencing the original issue as well as the new issue: a user with the Editor role is unable to edit most content items in the Safer Choice Ingredients, as #no_privileges is appended to the edit urls.

I disabled all plugins. I was then able to access the Safer Choice Ingredients content type and edit.

I then enabled "Access". With just "Access" enabled and no other plugin, both issues return.

There is something wrong on the Access side.

I have left the staging site with plugins deactivated. Let me know if you need a list of previously active plugins—I would send if you can enable a private response.

Please take a look and advise on a fix as soon as you can—this section helps my client meet regulatory notification requirements, and the user has changes they need to make.

I have turned on debugging as requested. The file should be where the instructions indicated.

[Minesh]

Can I have a duplicator copy of your site so I can debug this issue further and check whats going wrong there.
=> https://toolset.com/faq/provide-supporters-copy-site/

The thing is that I tried to check with my test site and at first point it was not working and then when I created brand new role (using copy from subscriber) and set the permission to post type, I can see it working.

I will require to run another test now on clean install and I will require your site copy for further debugging.

I have set the next reply to private which means only you and I have access to it.

[josephG-4]

The Duplicator plugin is not allowed on the host (WPEngine). But I can download a full backup and make that available to you. Would that work?

[josephG-4]

Looks like I used up that private reply—if a WPE backup will work for you, please let me know and enable a private reply where I can post the link. Thanks!

[Minesh]

Can you please try following plugin - does that work?
=> https://wordpress.org/plugins/all-in-one-wp-migration/

[josephG-4]

Hi Minesh,

That plugin is acceptable to the host. I've installed it and created a backup which you can access through the backend of the staging site you have access to.

[Minesh]

I'm able to track the issue and I found that the issue is with the argument you passed to register your post type.

For the post type "Safer Choice Ingredients", I've change the public argument from false to true:

"public" => true,

as you can see with the following argument array:

$args = array(
    "label" => __( 'Safer Choice', '' ),
    "labels" => $labels,
    "description" => "",
    "public" => true,
    "publicly_queryable" => false,
    "show_ui" => true,
    "show_in_rest" => false,
    "rest_base" => "",
    "has_archive" => false,
    "show_in_menu" => true,
    "exclude_from_search" => false,
    "capability_type" => "post",
    "map_meta_cap" => true,
    "hierarchical" => false,
    "query_var" => true,
    "menu_icon" => "dashicons-shield-alt",
    "supports" => array( "title", "editor" ),
  );

Now, when I loggedin as the user "toolsettest" I can see the post type is available and I can access it.

Can you please confirm it works as expected now.

[josephG-4]

Strange. Source control shows that it has been set to false since at least October 2019. This issue is more recent than that, which suggests that setting isn't directly related, even if changing it to true fixes it. Setting to true may cause other undesirable effects, though I'm not sure since I'm not the original developer of this site and I'm not familiar with the rationale for setting it to false.

Could there be a different cause that would explain the sudden change in recent weeks? I don't understand why the content type is available when Access is disabled, for example.

[Minesh]

Can you please check now, I've set your post type option: public=> false

Thata was the original settings with your post type and then I've applied the fix our devs shared within the Toolset Access plugin.

Can you please confirm it works as expected?

The official fix will be release with the next release of Toolset Access plugin in near future.