[Gelöst] Access can no longer control permissions of a custom post type

[Author]

Artikel

[gaborN]

Dear Support,

We've been successfully using Access and the plugin called Log Emails together (https://wordpress.org/plugins/log-emails/) for a while but recently our WooCommerce Shop Manager Roles are blocked from accessing the listing of the Posts of Log Emails (edit.php?post_type=log_emails_log). Earlier it used to work well.

Currently they get:
Cheatin’ uh?
Sorry, you are not allowed to edit posts in this post type.

As fas as I can track it down, this message comes from the WordPress core and not from the Log Emails plugin because I searched the codebase of the site and such messages only appear in the core, not in the plugin.

Also, the Log Emails plugin has not been updated for quite a while but in the meantime I updated WordPress and Access as well, so some changes introduced in Access and/or WordPress itself could be the cause of this issue.

Luckily I have a backup of the site where the access is still granted for Shop Manager Roles, so I did make sure that it did indeed worked a few months ago but not anymore. After updating plugins and WordPress, it no longer works.

I tried to fiddle with Access's settings but could not make it work again. Please help, I do not know where to go from here.

If you need access to the site, please provide a way to give you the credentials needed. Your current form below is too simple in this case, as I want to give access to a staging site protected by .htaccess. Also, I can give you access to both an Administrator and a Shop Manager account.

Regards,
GN

[Nigel]

Hi Gabor

I didn't test on earlier versions to see how it worked previously and what may have changed, but I have tested on current versions and it appears to work okay.

I went to the page Toolset -> Access Control and brought the Email Logs post type under Access control. I then made sure that the Shop Manager role had full permissions over Email Logs.

In another browser logged in as a user with the Shop Manager role I was able to view the email logs at the page Tools -> Log Emails.

Can you check the above on your site and if you still have problems, let me know?

[gaborN]

Hi Nigel,

Thanks for taking a look at it. I have "Managed by Access" enabled for "Email Logs". Shop Manager has all its checkboxes "checked" (meaning full permissions), just like Administrator BTW.

I think I have the same setup as you have in tis regard. I have just updated to Access 2.4.3.1 and it BROUGHT the admin DOWN! Just blank screen, no admin 🙁 I reverted to Access 2.4.3.

One thing to note is that because I removed the Tools menu for Shop Managers, I moved the Log Emails menu item form its original submenu position to the top level. But this should not affect access restrictions, right? It is just moving the menu items around, but it still points to "edit.php?post_type=log_emails_log" which is blocked somehow. Only Administrators have access to it currently.

Regards
Gabor

[Nigel]

Hi Gabor

I'm using Access 2.4.3.1 successfully.

If updating gives you a white screen we ought to see why, it sounds like there may be a conflict from another plugin or your theme.

You or I need to do a basic install check (disable non-Toolset plugins and switch to a default theme such as twentyseventeen) to try and isolate any conflict, and when experiencing the white screen after updating Access there should be some error(s) in your debug logs.

Do you have a test server to check this on? If not I can test on a local duplicate of your site. You can make a copy of your site available using Duplicator as described here: https://toolset.com/faq/provide-supporters-copy-site/. If needs by I can do that for you.

Let me know what you are able to check or what you would like me to test and I'll set up a private reply if needed.

[gaborN]

Hi,

Could you please provide a secure way I can share our login credentials (private reply?) to our staging/test site where you can safely do your testings? We cannot use Duplicator free version, it always fails with timeout on our server. But our staging site is the exact clone of the production site.

As I wrote in my fist post above, I can give access to the site but it is protected by .htaccess. Also, I can give you access to both an Administrator, a Shop Manager account and an ftp access too.

We have lots of plugins (34 active ones) and so far Access used to run without major issues. I think it is faster for you to do this enable/disable troubleshooting procedure because I do not really know which one to start with. I'm sure not all of them need to be deactivated as there can be completely unrelated ones, and disabling some of them could surely bring down the site too. But it is okay on the staging site.

thanks in advance,
Gabor

[gaborN]

Hi,

This is the fatal error after updating to Access 2.4.3.1 form 2.4.3:

Fatal error: Uncaught Error: Class 'WPV_Page_Slug' not found in 
.../wp-content/plugins/types-access/vendor/toolset/toolset-common/user-editors/editor/screen/basic/backend.php:102
Stack trace: 
#0 .../wp-includes/class-wp-hook.php(298): Toolset_User_Editors_Editor_Screen_Basic_Backend->admin_enqueue_assets('update-core.php') 
#1 .../wp-includes/class-wp-hook.php(323): WP_Hook->apply_filters(NULL, Array)
#2 .../wp-includes/plugin.php(453): WP_Hook->do_action(Array) 
#3 .../wp-admin/admin-header.php(97): do_action('admin_enqueue_s...', 'update-core.php')
#4 .../wp-admin/update-core.php(584): require_once('/Users/.../...')
#5 {main} thrown in .../wp-content/plugins/types-access/vendor/toolset/toolset-common/user-editors/editor/screen/basic/backend.php on line 102

What next?

[Nigel]

Hi Gabor

I've marked your next reply as private, could you please provide credentials to the staging site so I can take a look.

Thanks

[Nigel]

Hi Gabor

A quick update to let you know that I have, at least, identified the problem which was bringing down your site when updating Access to 2.4.3.1. It arises when Views 2.4.1 is active. It seems like it needs updating to 2.5 before you can update Access to 2.4.3.1. It shouldn't be like that and I've reported it.

I can now continue to see what the issue with the permissions for the email logs is.

[gaborN]

Thank you for the quick report, Nigel!

Also thanks for the "tip" on updating the plugins. I have just tested it on my local machine and it does indeed work if I update to Views 2.5 before applying the update of Access.

I hope you will have an answer to the "Email log" issue too.

Regards,
Gbaor

[Nigel]

Hi Gabor

I noticed something similar on a local install where Access and Types were the only other plugins active than Email Logs, and disabling Types fixed the problem. Re-enabling Types I found that I had to go to Toolset > Settings > Access and use the "Remove Access settings from my database" option to fix the issue.

Having done that I brought Posts and Email Logs back under Access control and am now able to see the email logs when logged in as a shop manager.

I've done the same with your staging site.

It does mean that the Access settings have been lost and you will need to set those up again.

I'm not sure how the issue arose, but that appears to fix it.

If when setting the Access controls again to match those on your live site, if you encounter any more problems then let me know.

Thanks for your patience.

[gaborN]

Hi,

I'm not quite sure I'm following you, I tried the following on my local machine and it did not solve it:
- Disabled Toolset Types
- Enabled Toolset Types (right after disabling it)
- Applied "Remove Access settings from the database"
- Set "Email Logs" to "Managed by Access" and checked all permission on for Shop Manager

It did not help. I can see that on the staging site it already works but I cannot reproduce it. What am I missing?

thanks in advance
G

[Nigel]

I meant that the problem was occurring with Types enabled and disappeared if Types was disabled (which is obviously not a viable solution), so I reset the Access database and it began working, even with Types enabled.

Note that I had to bring standard Posts as well as Email Logs under Access control. Did you do the same?

Otherwise, on the staging site I disabled most plugins while testing, I'm guessing the difference is that on your local site they are mostly still active?

[gaborN]

"Note that I had to bring standard Posts as well as Email Logs under Access control. Did you do the same?"
Yes I did.

I cannot reproduce the way you fixed it. I also tried deactivating Types and all other plugins and afterwards resetting permissions to no avail.

The strange thing is that after that I tried these too:
- I migrated only the database form the online stating site (the one you work on) to my local machine and Shop Manager's access was still denied
- I migrated the files too, and I got a clone of the online staging site where access IS granted for Shop Manager and I even activated all plugins afterwards and now I have a site with all plugins active and access granted...

I just do not know how to reproduce it so that I can fix the site in production as well 🙁
Any ideas?

[gaborN]

Hello Nigel,

This morning I upgraded to Views 2.5 from 2.4.1 then to Access 2.4.3.1 from 2.4.3. First I did it in a local test environment and because it worked, I also upgraded the production site.

However, today I also noticed what happens from time to time (but not always) when upgrading Access. The issue is that sometimes CRED Form settings are changed during the upgrade process. I attached a screenshot to show you what happens. The screenshot is what can be seen on admin.php?page=types_access&tab=cred-forms

I have two forms and you can see that below Shop Manager I remove permissions to delete the posts and give access to anybody else as these are public forms in this regard.

But these settings sometimes change and I have to remember checking them after each Access update.

Note that – for example – today these settings did change in my local test environment but did not change on the production site. However, there are times when they do change on the production site, making the from disappear from the forntend. It is quite problematic when I forget to check them after the update.

Regards,
G

[Christian Cox]

Hi, Nigel is out on holiday for a few days so I'm taking over this ticket. I hope that's okay.

Note that – for example – today these settings did change in my local test environment but did not change on the production site. However, there are times when they do change on the production site, making the from disappear from the forntend. It is quite problematic when I forget to check them after the update.
This sounds like a bug, and I'd like to investigate it in much more detail. May I kindly ask you to create a separate ticket? Our policy is to address one issue per ticket. Thanks for understanding.

I just do not know how to reproduce it so that I can fix the site in production as well
Very strange - from the ticket comments I can see that you and Nigel have struggled to come up with a replicable solution that works consistently on both local and staging environments. If that's the case, it becomes quite important to work with a true clone of your production site to ensure that the solution we come up with can be expected to work once deployed. You mentioned that the free version of Duplicator always times out on your server. I have access to the Pro version, where several improvements are available to help resolve that problem. If it's okay with you, I would like to make an attempt to clone your staging environment first. If I'm able to get Duplicator Pro to work on your staging environment, then it will become easier for me to make repeated tests and confirm a consistent approach. Let me know if that's okay with you and I will try with Duplicator Pro.