Support » Allgemeine Fragen » Login ohne Unterlass

  • Hallo im Forum,

    Ich bräuchte dringend Eure Hilfe bei der Lösung eines ziemlich nervenaufreibenden Problems: seit geraumer Zeit (wann genau und nach welchen Manipulationen das angefangen hat, weiß ich leider nicht mehr) muß ich mich ununterbrochen neu einloggen, wenn ich an meiner Homepage arbeite, d.h. nach fast jedem Speichervorgang oder Seitenwechsel.

    Woran kann’s liegen?

    Liebe Grüße und Danke im Voraus für Eure Antworten!
    Dagobert

Ansicht von 15 Antworten - 16 bis 30 (von insgesamt 85)
  • 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 7 Jahren, 7 Monaten von Flower33.
    Thread-Starter Dagobert48

    (@dagobert48)

    Hallo Flower33,

    Sorry, habe Deine Antwort erst jetzt entdeckt, die Mail-Nachricht wohl übersehen…

    In der Zwischenzeit nochmals mit dem Support des Hosters geflirtet, er schiebt das Login-Problem auf „den Autor des Scripts“, die Trägheit der Verbindung auf die Plugins (URL einer Test-Seite als Beleg mitgeschickt).
    Habe also doch alle Plugins mal abgeschaltet und bin eine Weile durch die Webseite gewandert. War tatsächlich ein bißchen flotter, das Login-Problem bestand aber nach wie vor: mußte mich regelmäßig neu anmelden, manchmal sogar eine kleine Rechenaufgabe lösen (wieviel ist 11-9? oder so).

    Dann das Theme und die GP-Premium-Version upgedatet (sagt man so?:-), das von Dir empfohlene Plugin zum Abrufen der php-Informationen installiert und mich in diesem spanischen Dorf mal umgeschaut: natürlich ratznix verstanden. Die php-Version sehe ich allerdings: es ist die 5.5.35.

    Jetzt alle wichtigen Plugins wieder angeknipst.

    Werde mich also noch mal mit dem Hoster kurzschließen und ihn wegen der php-Version und des Speicherlimits interviewen.

    Ob das alles das Ursprungsproblem der überaus nervigen Login-Kaskaden löst, bezweifle ich. Vielleicht gibt sich das ja irgendwann im Laufe des Jahrhunderts…

    Liebe Grüße, Dagobert

    P.S. Wie kannst Du eigentlich die php-und Thema-Version meiner Webseite kennen 🙂 ?

    Thread-Starter Dagobert48

    (@dagobert48)

    …habe die Antwort auf eine Deiner Fragen vergessen: memory_limit 256M

    Hallo Dagobert,

    Dann das Theme und die GP-Premium-Version upgedatet (sagt man so?:-),

    stimmt so, grammatikalisch sicher korrekter als „geupdatet“, wie manche schreiben. 🙂

    Werde mich also noch mal mit dem Hoster kurzschließen und ihn wegen der php-Version und des Speicherlimits interviewen.

    Ob das alles das Ursprungsproblem der überaus nervigen Login-Kaskaden löst, bezweifle ich.

    Wenn ein Webhoster heutzutage nicht das Update auf mindestens PHP 5.6 erlaubt, sollte man ihm andeuten, dass man sich dann wohl bei der Konkurrenz umsehen müsse. 🙂

    Von deinen Zweifeln solltest du dich aber nicht abhalten lassen, das memory_limit abzuklären, denn es könnte hier durchaus eine Rolle spielen. Schade, dass du mit dem phpinfo-Plugin Probleme hattest und das memory_limit nicht selbst auslesen konntest. Da ich selbst nicht dieses Plugin brauche, muss ich es heute Abend mal testweise installieren und kann dir dann sagen, wo du die Angabe findest.

    P.S. Wie kannst Du eigentlich die php-und Thema-Version meiner Webseite kennen?

    Das Thema kann man sehen, wenn man sich den Quelltext einer WordPress-Website anschaut, und die PHP-Info habe ich über diesen Online-Sitecheck ausgelesen.

    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. 🙂

    Thread-Starter Dagobert48

    (@dagobert48)

    Tausend Dank!

    Das geht ja jetzt wirklich ins Eigemachte: habe die Datei .htaccess tatsächlich gefunden -> einfach die von Dir vorgeschlagene Zeile dazuschreiben??

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    
    # END WordPress

    Außerdem gab es auf der „Konfigurationsseite“ des Servers die Möglichkeit, die PHP-Version bis auf 7 (über 5.6) selber hochzusetzen. Hab ich einfach mal gemacht und werde die Seite jetzt mal durchtesten.

    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 7 Jahren, 6 Monaten von Flower33. Grund: Nachtrag
    • Diese Antwort wurde geändert vor 7 Jahren, 6 Monaten von Flower33.

    Ach so, fällt mir grade ein, die aktuell bei dir eingestellte max_execution_time kannst du ja mit dem Plugin selbst auslesen. Sie steht im Bereich der Core-Angaben.

    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 7 Jahren, 6 Monaten von Flower33. Grund: Code-Auszeichnung
    Thread-Starter Dagobert48

    (@dagobert48)

    Danke für Deine zeitaufwändige Hilfestellung !!!

    Komme ganz schön ins Schwitzen bei all diesen chirurgischen Eingriffen, von denen ich nichts verstehe.
    Ich habe aber all Deine Ratschläge mutig ausgeführt, mein Hoster erlaubt ziemlich viele Eingriffe. Die Meldung am Fußende ist mir gar nicht aufgefallen, aber nach der Operation ist sie jetzt verschwunden :-)!
    php_flag zlib.output_compression Off eingegeben.
    – Das true durch false ersetzt.
    – Die max_execution_time ist auf 120 gesetzt, daran kann ich wohl nichts ändern – oder soll ich den von Dir angegebenen Code php_value max_execution_time 300 in .htaccess eingeben? Bringt das was?
    – Alle Cookies gelöscht und den Cache geleert.

    Dann die Webseite getestet: gefühlt mindestens 2x flotter !!
    Aber: das Problem der sich ständig wiederholenden Login-Aufforderung ist immer noch vorhanden – vielleicht etwas weniger oft, das wird sich im Laufe der Zeit herausstellen…

    Liebe Grüße, Dagobert

    php_flag zlib.output_compression Off
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress

    Hallo Dagobert,

    bist du der einzige, der Probleme beim Login hat?
    Hast du es einmal mit einem anderen Browser getestet?
    Oder einem anderen Rechner, Device, etc?

    Wieso bekommst du beim Login eine Rechenaufgabe?
    Hast du einmal testweise ein Stadardtheme aktiviert und überprüft, wie es sich da mit dem Login verhält?

    Hallo Dagobert,

    – Die max_execution_time ist auf 120 gesetzt, daran kann ich wohl nichts ändern – oder soll ich den von Dir angegebenen Code php_value max_execution_time 300 in .htaccess eingeben? Bringt das was?

    Ob es was bringt, kann man nur durch Testen rausfinden. 🙂

    (1)
    Gib den entsprechendn Code doch einfach, wie vorgeschlagen, mal testweise am Anfang der .htaccess ein, lösche den Cache, aktualisiere die Seite und schau, ob es was bringt.
    Bringt es nichts, überprüfe mit dem phpinfo-Plugin, ob die Änderung überhaupt gegriffen hat. Steht dort jetzt 300 statt 120, hat die Änderung gegriffen. Bringt sie nichts, war es das wohl nicht, wobei der ert 300 ja auch nicht in Stein gemeißelt ist und testweise variiert werden kann. Aber das müsste egentlich gut reichen, falls nicht irgendwas uns Unbekanntes da wahnsinnig viel Zeit in Anspruch nimmt.

    (2)
    Daher auch meine Frage nach einer Auflistung aller eingsetzten Plugins, z.B. Sicherheitsplugins oder Membership-Plugins etc.

    (3)
    Was mich etwas irritiert ist deine Bemerkung

    das Login-Problem bestand aber nach wie vor: mußte mich regelmäßig neu anmelden, manchmal sogar eine kleine Rechenaufgabe lösen (wieviel ist 11-9? oder so).

    Wieso nur manchmal? Daher meine Frage, ob du weißt oder eine Vermutung hast, woher das kommt.

    • Diese Antwort wurde geändert vor 7 Jahren, 6 Monaten von Flower33. Grund: Schlechtschreibung
    • Diese Antwort wurde geändert vor 7 Jahren, 6 Monaten von Flower33. Grund: nochmal Schreibung

    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 7 Jahren, 6 Monaten von Flower33. Grund: Schreibe

    Ich hatte überlesen, dass Torsten schon den Wechsel eines anderen Browsers vorgeschlagen hatte und dies bei deinem Test keine Änderung gebracht hatte.

    Bleiben also folgende Tests/Fragen:
    Hast nur du Probleme mit dem Login?
    Theme-Wechsel
    Anderer Rechner/Device
    Die Frage, wieso überhaupt und wieso nur ab und zu eine Rechenaufgabe vor dem Login.

    Des Weiteren hat Kaspersky ein nicht vertrauenswürdiges Stammzertifikat beim Aufruf der Website commpell.com gemeldet. Das stammt von deinem Hoster, siehe nachfolgenden Link (Screenshot)
    http://d.pr/i/19hDF/623YPCqX

    Ich kann mir vorstellen, dass es auch irgendwie Einfluss auf das Login-Verhalten haben könnte.

    Das Plug-in WP-SpamShield ist installiert (apropos „Captcha-Abfrage“, die sollten lt. Plug-in-Entwickler alle deaktiviert werden)
    Hier ist eine Beschreibung möglicher Konflikte:
    http://www.redsandmarketing.com/plugins/wp-spamshield/known-conflicts/

    sowie auch das lesen:
    http://www.redsandmarketing.com/plugins/wp-spamshield/troubleshooting-guide/


    Auch wenn du alle Plug-ins deaktiviert hattest, könnte dennoch das Cache des oder der Plug-ins aktiv gewesen sein und daher trotzdem noch die Probleme extistent gewesen sein. Ist leider manchmal so.

Ansicht von 15 Antworten - 16 bis 30 (von insgesamt 85)
  • Das Thema „Login ohne Unterlass“ ist für neue Antworten geschlossen.