Gaia Clary

the issue is resolved for our case.

We figured out how to get it to work (for us). Maybe others who have the same issue can try the same fix:

• We deactivated and removed all paypal related woocommerce plugins
• We added back the paypal plus for Woocommerce plugin
• We added back the other plugins:

• aelia currency switcher
• paypal direct checkout

• finally we configured the PayPal Plus plugin and the aelia currency switcher

And now it works as expected ??

well, our shop is a german shop hostet in a data center in germany and owned by a german company. What more ‘german’ do we need ?? ?

from the paypal webiste:

At the moment, PayPal Plus is only available for customers having their registered office in Germany. Nonetheless, international transactions work. Customers not being in Germany can only choose between the payment methods PayPal and Credit card.

• This reply was modified 5 years, 9 months ago by Gaia Clary.

Thanks for the tip. This worked like a charm ??

one question: Is there an integration documentation available for this sort of questions?

I just found that the style i use in my theme style is not used in the admin pages, hence my css styles get not applied to the ticket pages.

/wp-content/plugins/awesome-support/assets/admin/css/admin.css

How can i overwrite styles without need to edit this admin.css?

Most helpful would be if we could specify a link to our adminpage in some generic way, something like this for example:

URL: "/path/to/page?user=$CREATOR"

This link could then be used in the page sidebar:

Ticket Creator

<a href='$URL'>$CREATOR->name</a>

This ticket has been raised by the user hereinabove.

It would be very helpful if the page that you have in mind could be injected into our own adminpage by using a shortcode like:

[wpas-creator-profile id="CREATOR"]

If you prefer to not use shortcode here, then it would still be helpful if your user profile page can have a link to the User’s WordPress profile page.

ah, thanks. that worked ??

Hi, the following is absolutely bad, i know. But i have not been able to find a better workaround to get our admin pages to load in an acceptable time:

1.) ./includes/admin/class-admin.php

Search for the line that contains “Stakeholders” and then comment out this line:

/*add_meta_box( 'wpas-mb-contacts', __( 'Stakeholders', 'wpas' ), array( $this, 'metabox_callback' ), 'ticket', 'side', 'high', array( 'template' => 'stakeholders' ) );*/

2.) in ./includes/admin/settings/functions-settings.php

Search for “function wpas_list_users” and then replace the get_users() call by an empty array:

/* List all users */
  $all_users = array(); /* get_users();*/

These 2 changes let my pages load within 5 seconds instead of 45 seconds. Of course i no longer see the lists of users. But so far i did not miss them.

This might be interesting:
Around line 25 in the file
./includes/admin/settings/settings-general.php

we find an array:

array(
      'name'    => __( 'Default Assignee', 'wpas' ),
      'id'      => 'assignee_default',
      'type'    => 'select',
      'desc'    => __( 'Who to assign tickets to ...', 'wpas' ),
      'options' => wpas_list_users( 'edit_ticket' ),
      'default' => ''
)

The problem is in the function wpas_list_users( ‘edit_ticket’ ).
Although this function actually returns only 3 users, it seems to have a side effect on the Groups plugin:

-------+------+----------------
Groups | WPAS | Database calls
-------+------+----------------
Off    | Off  | ~80
On     | Off  | ~500
Off    | On   | ~4300
On     | On   | ~35000
-------+------+----------------

So i replaced the call to wpas_list_users() in the array above by a static array that contains our wpas agents. Now the number of database calls went back to about 530 with both plugins enabled and the admin pages load as quickly as they should.

I hope this find can help you to figure out why WordPress gets crazy when wpas_list_users( ‘edit_ticket’ ) is called.

[EDIT]: deleted this particular post because it was sent twice.

I mentioned before that there might be a dependency with the Groups plugin from here: https://docs.itthinx.com/document/groups/

So we enabled/disabled both the Groups plugin and Awesome Support plugin. Then we called the plugins page /wp-admin/plugins.php repeatedly and measured the average load time. Here are the results. Maybe that can be helpful to reproduce the problem?

-------+------+----------------
Groups | WPAS | page load time
-------+------+----------------
Off    | Off  | 2-3 seconds
On     | Off  | 3-4 seconds
Off    | On   | 4-5 seconds
On     | On   | 15-20 Seconds
-------+------+----------------

Maybe it is also important to know that we have:

240 Posts
450 Pages
4000 registered users

We also run Woocommerce on the Blog.
The Blog runs on a debian 7.8 server

Getting this fixed or at least getting a workaround for this would be awesome ;/

Is there at least a way to stop slowing down all other plugins as well?
Remind that 30 seconds to wait for a page update is horror ??

i was able to use this with a very small modification:

add_filter( 'wpas_ticket_statuses', 'wpas_my_custom_status' );
function wpas_my_custom_status( $status=array() ) {
        $status['my_custom_status'] = 'My Custom Status';
        return $status;
}

thanks for the help ??

ok, after browsing on the web i finally found a way to get this working.
I added a function to our theme:

add_filter('upload_mimes', 'custom_upload_mimes');
function custom_upload_mimes ( $existing_mimes=array() ) {
    $existing_mimes['dae']   = 'model/vnd.collada+xml';
    $existing_mimes['blend'] = 'application/octet-stream';
    return $existing_mimes;
}

However couldn’t this be added by the wpas plugin somehow ?
It could check which mimetypes are available and then add the missing filetypes.

hmm, then maybe the allowed filetypes would need to be expressed in more detail, like this for example:

jpg,jpeg,png,gif,zip,blend:application/octet-stream,dae:model/vnd.collada+xml

I have seen often that such selection menus get updated “in realtime” such that only a small portion of the data is called first, then while scrolling down the selection the data chimes in as needed. Also i have seen selections together with the ability to search specific entries by typing in the first 2 or 3 letters and the system would then retrieve only entries that match the search string…

If this is really the cause of the problem (a large selection list) then it would be awesome when that list could be replaced by something as i described above. I know that woocommerce provides such a system for assigning users to orders for example. So it can not be such a big thing to do ??