peter lipp

same probleme here. Tried it in private mode only so this shows there is an issue.

Now what do you think if everything works, you install this plugin, and something is suddenly completely broken, I remove the plugin and everything works again? Sorry, but I can’t invest my time to find out whether indeed something else was the culprit, when uninstalling solves my problem (I honestly would be curious enough to find out more about the issue, but since I need the site to be working and have other more important things to do…)

Well I had the same issue today and found that there was a postmeta for the my_account-page containing the value of the field. I had tried to debug this to find out how it can get there but didn’t get very far. Then I just manually deleted the stuff and so far it did not reappear. Maybe not the same as your problem, the value was “sticky” with me (from some customer a while ago) and I hope it still does.

The value should not have been store with the my_account-object of course…

I just updated to the last version – and I still need to change the priority of the action from 10 to 9 to make this work.

The faster way is to add the parameters into the code, you need to move the creation of the $email_abstract_object to before header and footer calls and add this parameter to the calls. Like

ob_start();
$email_abstract_object = new WC_Email();
$mailer->email_header( $email_heading, $email_abstract_object );
echo $email_body;
$mailer->email_footer($email_abstract_object);

Tested and works.

No thats not the place, its the dropdown-list of the search-results in the admin-interface when we entered an order manually and the js searches for the partial string entered.

Got it, was an effect of a change in my css. Thanks anyhow.

No (visible) javascript issues at all (so no messages).

Obviously you cannot tell me what the issue is but since you have a long list of conflicting plugins, I’d assume you have some experience in typical reasons.

I will remove my js-content to try whether this helps.

Just bought the premium version, same issue, same solution…

I have not yet discovered when this exactly happens, a colleague has mentioned that he saw the WSOD in some sequence. SO – so far “only” in the log for me, but since there was no other error message there I guess they may be connected.

Regards
Peter

Well it did not do the job but I found a way around: change the priority of your mangage_users_custom_column-action from 10 to 9. That fixes the issue.

Sorry but no change. I did deactivate and remove (while I am not really sure whay removing should be essential) and still the other columns are empty…

Not sure, I get a “this site experience difficulties” on some option-save-action…

Access To XMLRPC is completely blocked since yesterday.

Since our WordPress-Installation is located in a subdirectory, I manually edited the .htaccess of the root – which did not change anything… Maybe I need to talk to the hoster?

Installed the 5.9.3 version, there it still works…