Login ohne Unterlass

Exakt im Moment des Anklickens von „Absenden“ wurde mir klar, dass das keine gute Idee war, den rechtscheibkorrigierten, zunächst als Spam eingestuften, Beitrag erneut abzusenden. Hab ich dir unnötig Arbeit gemacht, Bego, tut mir leid! 🙂

Das ist ja nicht da erste Mal, dass (meist längere) Beiträge von mir, die Links enthalten, zunächst als Spam eingestuft werden.
Könnte das darin liegen, dass ich im Fließtext verlinke?
Ob es was bringen würde, mit Nummer-Verweisen die Links am Ende des Textes aufzuführen?
Wohl eher nicht, oder?
So ganz klar ist mir das System noch nicht, denn manche, ganz ähnlich aufgebaute, Beiträge haben es schon geschafft.

• Diese Antwort wurde geändert vor 8 Jahren, 3 Monaten von Flower33.

Ah, du hast es ja noch nachgetragen, da haben sich unsere Postings eben gekreuzt.
Das ist genügend Speicherlimit.
Du könntest mal in der Datei .htaccess noch Folgendes probieren:

php_value max_execution_time 300

Falls es nichts bringt oder auf diesem Wege nicht greifen sollte, würde ich die max_execution_time mal noch beim Webhoster ansprechen und nach Details fragen.

Hier ist gerade Besuch eingetroffen, melde mich gegebenenfalls später wieder. 🙂

einfach die von Dir vorgeschlagene Zeile dazuschreiben??

Ja, gib sie mal vor dem

# BEGIN WordPress

ein.
Die beiden Änderungen (auf PHP 5.6 oder PHP 7 erhöhen) und Erhöhung der max_execution_time (mit dem Wert kann man noch herumtesten) aber nicht gleichzeitig vornehmen, sondern eine nach der anderen und danach jeweils testen.

Ich würde erst mal auf PHP 5.6 updaten und vor dem Erhöhen auf PHP 7 noch abklären, ob jedes meiner Plugins damit kompatibel ist. Die meisten und wichtigsten sind es schon.

Ich denke, dass dieses spezifische Problem eher nicht an der PHP-Verion liegt, aber es schadet nie, im Zuge einer solchen Aktion auch bestimmte Risiken (z.B. veraltete PHP-Versionen) möglichst zu minimieren.

Ob sich die max_execution_time über die .htaccess steuern lässt, hängt auch von den Servereinstellungen bei deinem Webhoster ab. Falls die Direktive nichts bringt, muss es also nicht zwingend heißen, dass es daran nicht liegt. Du könntest danach auch noch beim Hoster diesbezüglich anfragen, der das gegebenenfalls in der php.ini abändern könnte, auf die du vermutlich keinen Zugriff hast.

Falls all das nichts bringt, muss man halt nach anderen möglichen Ursachen suchen.
Vielleicht haben ja andere hier noch zusätzliche Ideen.

Nachtrag:
Ach so, könntest du vielleicht mal noch deine eingesetzten Plugins hier auflisten?
Ist dir klar, woher diese Art „Captcha“ beim Login kommt?

• Diese Antwort wurde geändert vor 8 Jahren, 3 Monaten von Flower33. Grund: Nachtrag
• Diese Antwort wurde geändert vor 8 Jahren, 3 Monaten von Flower33.

Hallo Dagobert,

ich sehe, du hast gleich Nägel mit Köpfen gemacht und PHP 7 eingestellt! 🙂

Eine Sache, die ich vergessen hatte, anzusprechen, ist eine Meldung, die mir erst heute beim Anschauen deiner Website im Fußbereich jeder Seite aufgefallen ist:

Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /home/u939447588/public_html/wp-includes/functions.php on line 3597

Ich glaube eigentlich nicht, dass das ursächlich mit deinem spezifischen Problem hier zu tun hat, aber du könntest mal in der .htaccess Folgendes eingeben:

php_flag zlib.output_compression Off

Dann müsste dieser Hinweis eigentlich verschwinden, falls dein Webhostingpaket diese Änderung per .htaccess zulässt. Diese output_compression ist eigentlich gut für die Geschwindigkeit der Site, daher nur mal testweise deaktivieren und schauen, ob es eventuell was am spezifischen Problem ändert.

Falls die Meldung nicht verschwindet, hast du bei deinen Hostingpaket keinen Zugriff via .htaccess auf diese Einstellung und müsstest deinen Webhoster um Hilfe bitten und mal fragen, was es damit auf sich hat.

Außerdem deutet diese Meldung darauf hin, dass du in der wp-config.php immer noch stehen hast

define( 'WP_DEBUG', true );

und das aus Sicherheitsgründen wieder auf false setzen solltst.
Ich würde das machen, nachdem ich den Schritt mit der Deaktivierung der output_compression getestet habe.

Solche Tests an der Live-Installation natürlich nie ohne ein vorheriges Backup machen. Das versteht sich ja von selbst und soll dir keineswegs Angst einjagen. 🙂

Vor einem neuen Test immer auch mal Cookies und Cache löschen.

• Diese Antwort wurde geändert vor 8 Jahren, 3 Monaten von Flower33. Grund: Code-Auszeichnung

Habs grade mal getestet: gegenüber gestern Abend läuft die Site jetzt aber ratzfatz!
Bleibt also „nur“ noch die Fage nach dem häufigen Login. 🙂
Das kriegen wir auch noch raus und haben jetzt sogar noch Angelika als Verstärkung dabei.

• Diese Antwort wurde geändert vor 8 Jahren, 3 Monaten von Flower33. Grund: Schreibe