Capabilities sometimes not set up on an initial activation of Event Espresso

[lorenzocaum]

This isn't specific to a recent version

Summary From time to time, a customer will report that they've activated Event Espresso but they don't see it in their menus so they cant get started with Event Espresso.

Recently two members who started with decaf ran into this issue.

• https://secure.helpscout.net/conversation/662674495/566423
• https://secure.helpscout.net/conversation/666223008/567922/

I did some digging and I found other reports for earlier this year where it affects premium customers as well:

• https://eventespresso.com/topic/no-dashboard-icon-you-do-not-have-access-to-this-route-payment-options/
• https://eventespresso.com/topic/plugin-not-showing/

Steps to reproduce N/A

I know we need steps to be able to reproduce but in looking at the reports, it isn't specific to a certain version of Event Espresso nor is it specific to a certain web host.

Would it help to revisit the process around setting up the capabilities to see if anything stands out?

Other notes This is what I share so they can get back on track and move forward with their events.

1) Login to your WordPress admin

2) Reactivate Event Espresso 4 decaf

3) Go to this link: [WEBSITE]/wp-admin/admin.php?page=espresso_maintenance_settings&action=data_reset

4) Click on the Reset Event Capabilities button which looks like this: https://cl.ly/0u2L2L1a3B2S

[lorenzocaum]

Can this issue be triaged? When it happens, its a blocker for getting started.

[mnelson4]

Unless you're wanting to keep stuff off Darren's list of priorities, this would be better for him to look into as capabilities are usually more his sphere

[lorenzocaum]

This came up again: https://secure.helpscout.net/conversation/720150985/594201?folderId=100617

Keep in mind that these are reports that we've seen. I suspect that others have experienced this blocker and have quit without reaching out for feedback.

[nerrad]

Is this only happening for EE4 decaf users? Sorry, I haven't read through the linked helpscout threads, so if that info is there my apologies. Ideally, especially for things you can't reproduce yet, it'd be useful if you could list some commonalities you are able to readily identify among users reporting this problem. Summarizing any thing about user's environment setup in the issue (rather than me, or someone else having to dig through the helpscout reports) could be useful too.

[lorenzocaum]

I looked for patterns when I reported this issue but came up with limited information.

• This affects decaf and premium
• It doesn't appear to be a plugin conflict (was reported on a site with a couple of plugins and on others with lots of plugins)
• Customers are using different web hosts

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nerrad]

I've reviewed the code and I'm still not seeing anything stand out that could be a definite cause for this.

The only thing I can think of that might result in this is if there's a conflict with another plugin on the users WP install that is interfering with the cached WP_User object cached on the current request. We have some code that attempts to clear any WP_User cached when initializing our caps on activation but that might not be working in some conditions.

Without reproducible steps I'm shooting in the dark with regards to how to fix. At a minimum it'd be nice to get a list of what plugins users reporting this issue have active so we can see if there's any commonalities among the reports (and I could try installing plugins from that list that involve caps/wp_user and see if I can reproduce).

With that said, there is one thing we could try (but I'm wary of doing this). We set a record of our caps having been initialized and use that to abort the initialization process so it doesn't repeat unnecessarily. So if something goes wrong with that initialization and the caps don't get setup there won't be another attempt. What we could try then is detecting when the logged in user is an administrator role and there are no EE caps on that role and attempt to initialize again (regardless of the current bail option value). Downsides to this approach however are:

• Extra processing time (although minimal).
• Assumes that there won't be any sites where they explicitly removed all Event Espresso capabilities from the administrator role and only have them on specific roles.
• We'd have to pick an Event Espresso capability that we're reasonably certain would not be excluded from the site administrator role intentionally by site owners (maybe ee_read_access).
• Do we only attempt an automatic fix once or keep trying?
• It's possible this will still not kick in soon enough on activation requests. So user's would still perceive an issue with the EE top-level menu item not showing up.

Would probably take me a few hours to implement the above. I'm not certain it would resolve the reported issues but might be worth a try.

Bottom line, with this not being a widespread reported problem, it lends itself to being caused by an edgecase scenario introduced by a conflict with a certain theme/plugin that is not in wide use.

[joshfeck]

I think the above ideas have merit, but I'm also wary of doing those. What we'll need to prevent the condition from happening in the first place is a set a reproducible steps (e.g. specific plugins activated before EE4 is activated for the first time). Then we can do a fix

So I'm going to close this for now. If support staff can find the offending plugin (or other cause) we can reopen.