Torsten

OK, seems to be fixed with the latest update. Thanks.

@gvectorssupport v7.3.15 fixes the issue. thanks!

@gvectorssupport v7.3.14 doesn’t fix the problem for me. @marshy8 how about you?

@gvectorssupport Yes, that seems to work. wpdiscuz-ajax.php throws a 500 internal server error.

@gvectors-team Of course I did, but if I look at the posts while logged in the cache is not in effect and it doesn’t show the comments either. If it should be important: when I, logged in, click on the icon next to the number of existing comments (My content and settings) I get an error msg in a popup “Nonce is invalid.”.

Yes, I know. It’s just the standard form you see, if you add a new form. Here you can have a look: https://knodderdachs.de/kontakt/
I just made the subject and message boxes a bit bigger / wider.

Did you purchase “priority support”? If yes, you can log in to your account. Then you should directly be at “My Account – Downloadable Files” and can download the “Parabola NoLink Child Theme v0.7” file.

If you didn’t purchase, then you don’t have access to that file.

Do you use a child theme? Maybe you should switch away from the child theme for testing. If it works, then your child theme causes the errors.

After downloading the new child theme base (0.7) from cryoutcreations.eu and merging it to my existing one, everything works…

I’d like to add, that the cache clearing happens using the method described in this topic https://www.ads-software.com/support/topic/clear-cache-after-updating-plugins/

@stklcode Es scheint nun zu funktionieren. Was mir noch aufgefallen ist: ich bekomme bei dem Skript statt Code 200 einen Code 204. Die Z?hler erh?hen sich aber, soweit ich das prüfen kann, korrekt und meine Aufrufe (also von meiner IP) werden korrekt gefiltert. Das dürfte dann so richtig sein, oder?

Hm, it seems that wpDiscuz is loading sdk.js whenever Facebook Social Login is configured wheter it is actively used or not. In my case I set it up but didn’t activated Social Logins. I now reset the social login tab in the settings and the call for sdk.js is gone. I would like this behavior to be explained in the help texts.

@stklcode Sorry, habe mich verschrieben. Cache Enabler kann nicht selbst den Cache l?schen, wenn es so eingestellt ist, dass PHP umgangen wird und die gecachten Seiten gleich ausgeliefert werden. https://www.keycdn.com/support/wordpress-cache-enabler-plugin#will-cache-enabler-s-expiry-function-still-work-if-i-m-using-the-advanced-snippet

@stklcode Habe nun herausgefunden, woran es liegen k?nnte. Scheinbar kann Statify den Cache selbst gar nicht l?schen, da ich das seinerzeit so konfiguriert habe, dass die Ausführung von PHP komplett umgangen wird und direkt die gecachten Seiten ausgegeben werden, sofern sie existieren. In der Statify Anleitung steht drin, dass in diesem Fall die Einstellung zur Cache Expiry nicht funktioniert, da der Aufruf für diese PHP Funktion übergangen wird. Ist mir bisher nie aufgefallen, da ich den Cache auch maximal aufrecht erhalten wollte…

Habe das L?schen des Cacheverzeichnis nun per Cronjob auf alle 10 Stunden eingestellt und beobachte weiter.

@stklcode Habe die Dauer nun mal auf 8 Stunden eingestellt und beobachte weiter.

@stklcode Ja, das ist die richtige Adresse. Stimmt, der Cache ist immer noch aufgebaut und wirft bei snippet.min.js einen Fehler 403. Das wundert mich allerdings, da ich gestern Abend die Cachedauer auf 12 Stunden gestellt habe. Cron wird extern getriggert.

Den Cache wollte ich ursprünglich so lange wie sich nichts ?ndert, erhalten, da die Website dann einfach schneller ist. Ich will aber auch, dass Statify (und evtl. andere Plugins, bei denen ich bisher evtl. noch nichts gemerkt habe) einwandfrei funktionieren.

Geht die Erh?hung der Nonce-Lifetime nicht mit einem h?heren Sicherheitsrisiko einher?