TRILOS

Hi @tneville ,

you′re welcome, we′ll clear this up.
In fact there′s no problem with the character encoding in german translation, see
https://translate.www.ads-software.com/projects/wp-plugins/post-smtp/stable/de/default/?filters%5Bterm%5D=Supportanfrage+&filters%5Bterm_scope%5D=scope_any&filters%5Bstatus%5D=current_or_waiting_or_fuzzy_or_untranslated&filters%5Buser_login%5D=&filter=Apply+Filters&sort%5Bby%5D=priority&sort%5Bhow%5D=desc
May be the affected site has been migrated beetween servers and the encoding of translation files′ content has been corrupted. Of course this is not your problem. I′ll keep watching this issue on this and other sites and get back if there might be problem with the plugin.

So we have just my recommendations “Independently of language” left which you might consider.

Best Regards
Erik Petersen, TRILOS

Well done!
But the changelog is for the users, not the attackers. Attackers have other ways to know the vulnerability before this.
Hiding the fix
1. does not prevent any attack if the vulnerability has already been disclosed (like in this case)
2. hinders the plugin users of being aware of a critical threat and taking measures.
Don′t say the WP Team has forced this ridicolous strategy?!?

This phenomenon has… vanished… May be changing php to v7.4.11 had an effect.

Going to translate the readme next days, then DE will be complete.

I am Translation Contributor… done:
Untranslated (0)
Waiting (68)
Do you like to request review by GTE or should I?

It works when I use the correct path.
May I complete https://translate.www.ads-software.com/projects/wp-plugins/events-made-easy-frontend-submit/stable/de/formal/?filters%5Bstatus%5D=untranslated and “we′re ready”?

Datepicker appears again sincelast update, thank you.
(“Changelog
1.0.56 (2020/09/24)
– Correct JS error if the map integration is disabled”)

Option “Enable Maps integration?” on /wp-admin/options-general.php?page=emefs is OFF

errr…. bno datepcker

…and 1.) is still acute.

@dnesscarkey , I suspected that ?? Please add this to the plugin description to inform less experienced users, thank you!

Same here with php 7.4.9

In this case, blocking XMLRPC is provided by the Plugin iTHemes Security Pro by writing a rule into the .htaccess file.
I guessed this was cause for the problem because after deactivating the blocking the problem was solved, I assumed this plugin might require this and I haven′t analysed this further, sorry. And Apache gives no infos in the logfiles on causes for 403′s.
After reproducing this again, XMLRPC blocking has actually nothing to do with the blocking of /admin.php?page=matomo-reporting
I′ll see if the problem occurs again and try to get more aspects on this.

@seehundnz Vielleicht hilft es, das Plugin einmal zu deaktivieren und wieder zu aktivieren. Das hat ja auch in meinem Fall (unbeabsichtigt) geholfen. @msvfan hatte es sogar einmal entfernt und erneut installiert, siehe oben.

• This reply was modified 4 years, 10 months ago by TRILOS.

Hallo Svenja, das ist entweder Bl?dsinn oder was anderes ist gemeint. Jede WordPress Website l?uft mit htaccess (es sei denn man baut das selbst um). Vielleicht ist htpasswd gemeint gewesen, also ein Zugriffsschutz für http-Zugriffe, wenn man z.B. die unfertige Website-Baustelle noch verstecken m?chte – da w?re es naheligend zu vermuten, dass die Verbindung zwischen CleverReach und Plugin dadurch blockiert wird. Auch ein Wartungsmodus-Plugin, wie oben erw?hnt, kann Verbindungen blockieren.
Bei mir war das aber alles definintiv nicht der Fall. Ohnedies k?nnten natürlich entsprechende Hinweise auf der Einstellungsseite im back end hilfreich für unbedarfte Nutzer sein.