new ticket shows blank screen on local dev

Hi jibranb,

Strange issue. Unfortunately I can’t see a valid reason for such an issue in the log. I guess you’re using the latest version of Awesome Support (3.2.9)?

Have you tried deactivating your other plugin to rule out a plugin conflict?

Hi Julien,

I did as you suggested, but there was no difference. It seems the issue has to do with the number of users in the database (~45K).

When I comment out lines 72 and 96 in includes/admin/metaboxes/stakeholders.php, I am able to view and submit the new ticket form.

• 72 wpas_support_users_dropdown( $users_atts );
• 96 echo wpas_users_dropdown( $staff_atts );

Also, when I replace the wpas_list_users() call with an empty array() in /includes/admin/settings-general.php line 31 for Default Assignee, all settings pages display. Of course the Default Assignee is empty, but that’s expected for this test!

• 31 'options' => /* isset( $_GET['post_type'] ) && 'ticket' === $_GET['post_type'] && isset( $_GET['page'] ) && 'wpas-settings' === $_GET['page'] ? wpas_list_users( 'edit_ticket' ) : */ array(),

It seems that for each call, all users are queries and looped through to determine which users to display in a particular drop down. But because of the large users base it runs into memory issues.

Do you have any ideas how to deal with this?

Also note that I’ve edited the capabilities of the WooCommerce role ‘Customer’ to include that of the ‘Support User’. All of my users are assigned the ‘Customer’ role.

Thanks for your response and willingness to help!

-Jibran

Hi Jibran,

Your analysis and conclusion are correct. There is indeed a problem with the current version for sites with a lot of users (~6k+).

The problem is that even though Awesome Support comes with custom roles, lots of AS users give their clients different, pre-existing roles. Typically someone with an e-commerce shop using the customer role and adding Awesome Support capabilities to it.

That’s what makes our plugin easily compatible with tons of other plugins, but that’s also what causes this issue.

Because we can’t get users by role (again, support users can have many different roles on different setups) we need to query users by capability. Unfortunately WordPress doesn’t support querying by capability (the system isn’t designed for this).

This leaves us with one solution: querying all users and then filtering them manually based on their capabilities.

This is actually working well on the majority of sites containing a few hundreds to a a few thousands of users. But as soon as the number of users reaches 5/6k+ users things start to slow down, and timeouts happen on sites with many thousands of users.

What causes the issue is a caching layer that’s built in the WP_User_Query class.

It’s taken us some time but we’re finally in the process of fixing that. Various solutions were considered, and we decided to go about it from 2 angles:

1. Introduction of a user query class similar to WP_User_Query but way simpler and using custom SQL queries
2. The use of Ajax to display users lists

The development is in progress (almost finished actually) and the results are incredibly positive. There is an issue on GitHub where you can follow what’s happening: https://github.com/Awesome-Support/Awesome-Support/issues/285.

This will be released with version 3.3 that we are planning to release soon: https://github.com/Awesome-Support/Awesome-Support/milestones/3.3

Right on, Julien. I’m convinced Awesome Support is the way to go. I won’t be launching my support funnel for 4-6 weeks. Do you expect to release within the next few weeks? No pressure, just ballpark.

Thanks for confirming my findings.

We expect to release it in the upcoming weeks.

Great, I believe I will need the same thing! Over 246,000 customers ??

Wow! That’s a lot!

I’m happy to say that we have addressed the performance issue and version 3.3 should behave much better with sites having lots of users.