minickel

Thank you for your support, Niklas.
I’ve just created a private support request through the form.
Kind regards
Michael

Ok, I’m one step further: Is it possible that Mollie for Woo has issues in wordpress multisite network environment (or a single site staging environment, which I use for test purpose)?

I used a staging site of a wordpress single site installation – for this site, mollie for woo works fine … Thus I became suspicious that it might be a multisite network issue of the plugin on the other site.

On the multisite staging installation I even used the clean plugin option of WP-Staging, but it did not change the eraneous behaviour.

Since I cannot test on the productive site for now, I’d still appreciate your help.
Thank you.

I also tested refunds. Refunding throught the mollie refund button (inside the Woo order itself) will result in Woocommerce going successfully through refund and also mollie dashboard for the order states:

Verlauf

Webhook erfolgreich aufgerufen, es dauerte 0,3 Sekunden
9. Dezember 2022, um 17:26
1× Testprodukt (0,01?€) von Bestellung rückerstattet
9. Dezember 2022, um 17:26

However, the order itself in mollie still shows status “paid” and would allow for manual refund through the dashboard.

Somehow the plugin and the mollie server seem to communicate only half of the story …

• This reply was modified 1 year, 11 months ago by minickel.

P.S.: Also changes in the mollie dashboard like confirming shippig or refunding which sets an order to “completed” or “refunded” in mollie will not be synchronized with Woocommerce despite the dashboard’s output

Webhook erfolgreich aufgerufen, es dauerte 0,3 Sekunden
8. Dezember 2022, um 12:32

Hi there again,
actually, i found that when going to wp > settings > font awesome, changing “Enqueue” to Backend, UsersWP does not load fontawesome any more as a web font. So far I have not found any restriction because of that in the way I use UsersWP …
Hope that helps
Best
Michael

Hi there,
I’m having the same issue. I even installed a local font awesome instance into my wordpress, following the official font awesome guide: https://fontawesome.com/docs/web/setup/host-yourself/webfonts
and this German article which basically uses the “all.css” option of the official guide:
https://fastwp.de/magazin/font-awesome-lokal-einbinden/

This approach works for me insofar that for example Learndash-realted plugins now load the local font.

However not so UsersWP … It still loads the webfont persistently … I wonder why? If UsersWP would call font awesome in a standard procedure, the local installation should be used by it properly like in the mentioned Learndash plugins …
Could you please change that urgently?

Btw. this is not specific for German GDPR. We basically have the same GDPR rules in the whole of the EU. So this is an issue that will affect lots and lots of your installations …

Thank you and best
Michael

• This reply was modified 2 years ago by minickel. Reason: clarification, adding missing link

Ok guys, here is the solution and the whole story: the issue is user-dependent. Nothing else – quite trivial, yet, i don’t understand, why AWS for WordPress behaves that way.

My page is a multi-user-blog. So far, I have created all Posts through a super-user account and audio conversion worked just fine.

The problem began, after I started using my author account. Since that fell together with the WP Core upgrade and some plugin updates, i never thought that simply switching the user could make audio conversion stop working. Today, by chance, I switched back to the super-user account and audio conversion worked again.

Is there any way of making the plugin work for more users? It is certainly not a issue of user rights, since both accounts I used are formally super-user accounts with the same rights. I just use one as a general super-user for setup and maintainance more … that is the one which works, which ahs likely been used to install AWS for WordPress …

• This reply was modified 3 years, 9 months ago by minickel.

Looking into the timing details of the issue again, I can now also rule out that the core update to 5.6.1 created the issue, since the update came in a day before the last audio conversion took place after a post update according to my S3 bucket.

I also ran tests to roll back and/or deactivate all plugins that got updates between February 5 (last conversion) and Feb 10 (detection of the issue):

– Cookie Notice & Compliance for GDPR / CCPA 2.0.1 -> 2.0.2
– Really Simple SSL 4.0.7 -> 4.0.8
– Mailpoet 3 3.59.1 -> 3.59.2
– WP Fastest Cache 0.9.1.4 -> 0.9.1.5
– WP User Avatar 2.2.10 -> 2.2.11

Rolling back or deactivating those plugins does NOT fix the AWS for WordPress Polly issue I encounter. I ran out of ideas on how to possibly fix it.

One addition towards the additional ssl headers in .htaccess:

Basically I can rule out that those affected the AWS plugin. I implemented those changes a day before the last audio-update of a post was created by polly. So the plugin stopped working independently of those headers for sure ….

Still would be very much appreciating some support, @tstachlewski, @awslabs, @wpengine, @stevenkword

Thank you @brandonfire for your time and will to reply. Republishing a post helped in past issues sometimes and I also had one case before, where a certain German abbreviation crashed the audio creation, which was fixed by removal of this. However now, it stopped working completely, also for new posts with only a few simple words …

Still hope for a solution, since I love the text-to-speech functionality …

In addition, I have deactivated (in the staging sandbox) all plugins that had been updated since the last successful audio conversion, but still the issue prevails … Not sure what option is left now to look into

@tstachlewski – any suggestions how to regain functionality?

@brandonfire – you seem to have resolved a similar issue a while ago (https://www.ads-software.com/support/topic/text-to-speech-not-working/) – May I ask you to share how you resolved it?

Using a staging site, I downgraded the core to 5.6, but the plugin is still not working, neither on new posts, nor on the post where it stopped working on the production site.

Logging is active, but no errors are logged.

Using the latest pliugin version, I downgraded to 4.2.1 and updated to 4.2.2 again, with no result. Neither of the plugin versions working.

The only change I had made apart from the automatic core upgrade to 5.6.1 has been adding the following lines reagrding ssl to the .htaccess – however I have removed them, without any effect on the issue, which still remains. However, the question is, if something of these settings will still remain active once set, even after removing from .htaccess

Header always set Strict-Transport-Security: "max-age=31536000" env=HTTPS 
Header always set Content-Security-Policy "upgrade-insecure-requests"
Header always set X-Content-Type-Options "nosniff"
Header always set X-XSS-Protection "1; mode=block"
Header always set Expect-CT "max-age=7776000, enforce"
Header always set Referrer-Policy: "no-referrer-when-downgrade"

Any ideas what the issue could be?

Appendix: The following code is rendered

<div id="amazon-ai-player-container">
<audio class="amazon-ai-player" id="amazon-ai-player" preload="none" controls   controlsList="nodownload" >
<source type="audio/mpeg" src=""></audio>
		</div>
<div id="amazon-polly-subscribe-tab"></div>
<div id="amazon-polly-by-tab"></div>

So, there is also no audio link created (empty src=””)

Hi,
I have the same issue with MailPoet forms and elements like the sidebar in my Enfold theme. Did you find a solution?
Thank you and best

• This reply was modified 4 years ago by minickel.