Support » Plugins » Plugin Simple Google reCaptcha

  • Gelöst Thobie

    (@thobie)


    Moin,

    ich habe ein merkwürdiges Verhalten zweier Websites auf die Benutzung des Plugins „Simple Google reCaptcha“.

    Ich verwalte fünf eigene WordPress-Installationen und drei Kunden-Installationen.

    Auf den Kunden-Installationen und drei eigenen Installationen läuft das Plugin gut. Es ist eine dritte Absicherung vor Hackern zur .htaccess und dem zweiten Einloggen jeweils mit Benutzername und Passwort.

    Nur bei den beiden Websites:

    Foodblog https://www.nudelheissundhos.de und
    Buchshop https://www.buch-schmie.de

    bekomme ich mit diesem Plugin immer Probleme.

    Ich habe gestern überlegt, das Plugin einmal wieder versuchsweise als dritte Absicherung zu aktivieren.

    Heute stelle ich fest, dass ich bei der Einwahl in das Backend des Buchshops kein reCaptcha angezeigt bekomme, sondern die Einwahl auch mit den korrekten Einwahldaten nicht funktioniert. Stattdessen habe ich im Einwahlfenster den Link „Emergency reCaptcha deactivate“. Klicke ich diesen, wird reCaptcha deaktiviert, ich kann mich einwählen, aber die Keys in den Einstellungen des Plugins sind leer, das Plugin somit deaktiviert. Das ist ja nicht Sinn der Sache.

    Beim Foodblog kommt es noch heftiger. Sowohl Frontend als auch Backend sind komplett nicht zu erreichen. Fehlermeldung bei Aufruf der URLs. Ich kann dies nur beheben, indem ich das Plugin per FTP vom Webspace des Hosters lösche.

    Was läuft hier schief? Warum funktioniert dieses Plugin ausgerechnet bei diesen Websites nicht, jedoch bei den anderen fünf sehr zufriedenstellend?

    Liegt es daran, dass diese beiden Websites sozusagen vom Aufbau, der Datenmenge und den Einträgen in der Datenbank die jeweils „mächtigsten“, also umfangreichsten sind, die andern Websites jedoch eigentlich immer nur 7–8 Seiten enthalten und mehr nicht?

    Würde mich über Hilfestellung aus dem Forum freuen!

    Bleibt gesund!

    Grüße aus Hamburg

    Thobie

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 17)
  • Hallo,

    Was läuft hier schief? Warum funktioniert dieses Plugin ausgerechnet bei diesen Websites nicht, jedoch bei den anderen fünf sehr zufriedenstellend?

    ich gehe mal davon aus, dass deine WordPress-Instanzen nicht alle komplett identisch sind, d. h. andere Themes, andere Plugins, etc.
    Dann kann es durchaus bei der einen oder anderen Instanz zu einem Konflikt kommen.
    Du kannst ja mal nach einer Sicherung das plugin Health Check & Troubleshooting installieren. Wenn du auf den Button „Problembehandlungsmodus aktivieren“ unter Problembehandlung klickst, werden alle plugins deaktiviert und als Standardtheme (wenn vorhanden) twenty twenty oder Twenty Twenty-One aktiviert. Dann kannst du sehen, ob die beschriebenen Probleme noch weiterhin auftauchen. Aktiviere dann Plugin für Plugin im Problembehandlungsmodus und schaue jeweils nach Aktivierung eines Plugins, ob das Problem noch besteht. Auf diese Weise kannst du möglicherweise ein Plugin finden, dass das Problem verursacht. Vorteil dabei ist, dass der Leser deines Blogs die Seite weiter mit allen Infos und plugins sieht, während nur für dich alle plugins deaktiviert sind.
    Lies dir dazu bitte auch mal die Informationen in dem Beitrag zu Health Check durch.
    Viele Grüße
    Hans-Gerd

    Thread-Ersteller Thobie

    (@thobie)

    Moin, Hans-Gerd,

    das Plugin Health & Troubleshooting ist mir bekannt und auch installiert.

    Ich habe jedoch einmal wieder große Bedenken, so tief in die Installation der beiden Websites einzugreifen und alle Plugins und das jeweilige Theme zu deaktivieren.

    Der Buchshop ist noch das kleiner Problem, abwr er enthält immerhin etwa 40–50 Bücher.

    Aber das Foodblog ist recht umfangreich, 2.800 Blogbeiträge, über 5.000 Fotos, sehr viele installierte und aktivierte Plugins usw.

    Kann ich da einfach so verfahren, wie Du beschreibst? Das zerschießt mir nicht die Installation?

    Bleibt gesund!

    Grüße aus Hamburg

    Thobie

    Hallo,

    das Plugin Health & Troubleshooting ist mir bekannt und auch installiert.

    das dachte ich mir 😉

    Das zerschießt mir nicht die Installation?

    Tja, was soll ich dazu sagen. Ich sitze nicht davor.
    In der Regel mache ich in dem Fall eine Sicherung und bin damit schon mal auf der „sicheren“ Seite. Normalerweise habe ich für solche Fälle auch eine ziemlich identische lokale Entwicklungsumgebung. Da kann nichts passieren und ich kann das in aller Ruhe ausprobieren. Das ist sogar bei mir immer die erste Maßnahme.
    Hier mal ein paar Beispiele: Laragon, Bitnami, Local oder (relativ neu): Kinsta WordPress Development Suite. Interessant ist auch https://tastewp.com, Anleitung siehe z. B. hier: https://einstieg-in-wp.de/tastewp/
    Wir haben mit Laragon sehr gute Erfahrungen gesammelt.
    Mehr kann ich dir dazu leider nicht sagen.
    Viele Grüße
    Hans-Gerd

    • Diese Antwort wurde geändert vor 1 Monat, 2 Wochen von Hans-Gerd Gerhards. Grund: Tippfehler
    Thread-Ersteller Thobie

    (@thobie)

    Moin, Hans-Gerd,

    ich benutze WP Staging für eine Testumgebung.

    Ich aktualisiere gerade die vor einem 3/4 Jahr erstellte Testumgebung für das Foodblog.

    Und habe gleichzeitig eine neue Testumgebung für den Buchshop erstellt.

    Ich teste jetzt Deine Vorgehensweise mit dem Plugin Health & Troubleshooting in der Testumgebung des Buchshops.

    Eventuell finde ich ja den Verursacher des Problems mit dem reCaptcha-Plugin und kann eventuell dann auf die gleiche Weise auch den (eben eventuell gleichen) Verursacher im Foodblog lokalisieren.

    Das wird etwas Zeit in Anspruch nehmen. Ich berichte über (Miss-)Erfolge. 🙂

    Bleibt gesund!

    Grüße aus Hamburg

    Thobie

    Thread-Ersteller Thobie

    (@thobie)

    Moin,

    zuerst gab es Probleme mit meinem Hoster. Testumgebung für Buchshop, okay.

    Testumgebung aktualisieren im Foodblog wurde zwar als erfolgreich bestätigt, aber es gab viele Fehlermeldungen. Hintergrund: Da der Foodblog sehr umfangreich und mächtig ist, wurde zwar durch die Testumgebung nicht der maximal verfügbare Webspace bei meinem Hoster, aber die maximale Anzahl von Dateien von 260.000 in meinem Hosting-Paket überschritten. Fazit: Testumgebung des Foodblogs ließ sich nicht starten.

    Jetzt habe ich aber das reCaptcha-Plugin in der Testumgebung des Buchshops aktiviert. Und siehe da, brat‘ mir doch einer einen Storch, es funktioniert. Somit habe ich es auch der Live-Umgebung aktiviert. Dort funktioniert es auch.

    Dann habe ich es auch im Foodblog aktiviert und siehe da, es funktioniert auch dort.

    Jetzt muss ich die kommenden Tage mehrmals prüfen, ob sowohl Frontend als auch Backend bei beiden Websites funktionieren.

    Mögliche Fehlerquelle: Ich habe die Konfiguration des reCaptcha-Plugins auf dem iPad konfiguriert. Und auch dort durch Tippen mit dem Finger die Schlüssel für das Plugin in meinem Google-Account kopiert und auch eingefügt. Eventuell hat das Fehler verursacht. Denn dieses Mal habe ich es auf meinem Büro-Computer durchgeführt. Und wie gesagt, im Moment funktioniert es.

    Bleibt gesund!

    Grüße aus Hamburg

    Thobie

    Hallo,
    danke für die Info. Ich würde mir allerdings bei diesen Problemen und den von dir beschriebenen Umständen Gedanken machen, ob es dann nicht besser ist, eine lokale Entwicklungsungebung (Beispiele hatte ich oben genannt) einzurichten.
    Wir haben u. a. eine Webseite mit z. Zt. ca. 5450 Veranstaltungen, 800 Beiträgen sowie einer Karte mit knapp 400 Freizeitangeboten. Diese Seite hat sehr viele Zugriffe. Bei gravierenden Dingen (z. B. Plugins, die mir die Seite zerschießen können, so dass beispielsweise der Veranstaltungskalender nicht mehr funktioniert) teste ich immer erst auf der lokalen Entwicklungsumgebung und danach sogar noch auf einer weiteren nicht lokalen Testumgebung. Erst danach erfolgt die Änderung (Pluginaktualisierung, etc.) auf der produktiven Webseite.
    Viele Grüße
    Hans-Gerd

    Testumgebungen sind immer geboten!
    Würds aber sogar beim selben Hoster und nicht lokal machen – dann sieht man gleich, ob es mit der Liveinstanz auch Probleme gibt, da selbe Serverconfig!
    Lokal ist das dann doch immer ein bissl „Wettbewerbsverzerrung“ 🙂

    Hallo @souri

    Würds aber sogar beim selben Hoster und nicht lokal machen

    das sehe ich anders: eine lokale WordPress-Instanz habe ich über ein Bash-Script mittels WP CLI ziemlich flott wiederhergestellt und kann da ganz andere Dinge testen. Wenn es dabei meine Instanz schreddert, ist das überhaupt kein Problem.
    Daher teste ich kritische Dinge erst lokal, dann auf einer Testumgebung beim gleichen Hoster und dann erst auf der Produktivseite. Das klappt in der Regel ziemlich gut.
    Viele Grüße
    Hans-Gerd

    ziemlich flott wiederhergestellt

    Dafür brauch ich bei guten Hostern kein wpcli, sondern da reicht ein Mausklick.
    Zudem kann ich da über mehrere Tage hinweg den Status wieder herstellen – also den Zustand von zb vor 10 Tagen.

    dann auf einer Testumgebung beim gleichen Hoster

    Wir arbeiten in der Firma komplett mit Testumgmebungen remote am gleichen Server (bzw der gleichen Hardware), wo auch die Liveinstanz liegt.

    Die Latenzen spielen heutzutage keine Rolle mehr.
    Und da wir alle keine Einzelkämpfer sind, haben wir keine Probleme mit Sync o.ä.
    Sondern gehen immer vom selben Stand aus.

    @souri na ja, jeder wie er will 😉

    natürlich 🙂

    Da gibt es so viele mögliche Ansätze und unterschiedliche Motivation. Es ist sicherlich etwas anderes, wenn du in einem Team arbeitest und alle Entwickler/-innen die gleiche Basis haben sollen. Da macht es auch Sinn, Docker Container aufzusetzen und im Team zu teilen. Für einen Einzelnen ist das völlig überzogen.

    Für den Support hier hab ich mir einen Raspberry Pi mit diversen WordPress-Instanzen aufgesetzt. Hier kann ich auch sehr abwegige Dinge ausprobieren, fatale Programmierfehler und Sicherheitslücken einbauen, ohne dass ich anschließend einen (begründeten) Anruf von einem Webhoster bekomme. Um mal rasch für ein neues Projekt Themes auszuprobieren und mit Plugins zu experimentieren ist das auch toll. Dass das für ein Unternehmen nicht in Frage kommt (und die ein anderes Budget haben, um auch einen richtigen Staging-Server zu fahren), ist völlig klar.

    „Ich entwickle immer direkt auf dem Server“ ist ein Satz, den ich schon oft gehört habe. Wahrscheinlich handelt es sich dann aber nicht um ein billiges Shared Hosting ohne SSH-Zugang, auf dem sich weder WP-CLI noch Cron-Jobs mit Git pull einrichten lassen. Gerade wenn du für ein Kleingewerbe arbeitest, bei dem nicht mehr als 5€/Monat an Webhosting drin sind, klingt dieser Satz etwas abgehoben. 🙂

    Was war jetzt die ursprüngliche Frage? 😉
    (Ist ja glücklicherweise bereits beantwortet.)

    Docker ist komplett überbewertet
    Auch für ein Team find ich Docker die falsche Infrastruktur, gibt besseres, schnelleres, einfacheres und sicheres zum Entwickeln.

    ohne dass ich anschließend einen (begründeten) Anruf von einem Webhoster bekomme
    Not gonna happen! Also net von „guten“ Hostern.

    Wahrscheinlich handelt es sich dann aber nicht um ein billiges Shared Hosting
    Im Endeffekt ginge das ohne Probleme beim Webhosting von Hetzner, der ab einer gewissen Stufe alles dabei hat, was der managed Server auch kann.
    Da gehts dann ohne Probs, live, staging und test (Server) einzurichten. Zu sehr kleinem Preis.
    Inkl SSH, SSL, WPCLI, CRON usw usf…

    Docker ist komplett überbewertet – YMMV. Ich finde DevKinsta eine sehr attraktive Lösung, nutze Docker aber sonst auch nicht.

    … (begründeten) Anruf von einem Webhoster bekomme
    Not gonna happen! Also net von „guten“ Hostern.

    Wenn du Pentesting auf Shared Hostin betreibst, wird im einfachsten Fall die IP blockiert. Ich kann mir aber vorstellen, dass das auch die „guten“ Hoster nicht lustig finden.

    Im Endeffekt ginge das ohne Probleme beim Webhosting von Hetzner …

    Viel Spaß mit den Kunden, die bei Str…to sind und auch unbedingt da bleiben wollen, weil die doch so tolle Werbung machen. Klar kann man mit den Kunden endlos disktuieren, das ein guter Webhoster viel Unterschied macht … oder einfach auf den Auftrag verzichten.

    Ich kann mir aber vorstellen, dass das auch die „guten“ Hoster nicht lustig finden.
    Was ich auf meinem eigenen Server mit eigener IP mach, hat meinen Hoster noch nie gestört. (BC Mining ausgenommen)
    Kann also das Gegenteil behaupten.

    Viel Spaß mit den Kunden, die bei Str…to
    Habe andere Kundenstruktur, daher ist das nicht mein Prob.

    Klar kann man mit den Kunden endlos disktuieren

    Solche Kunden hab ich nicht!

Ansicht von 15 Antworten - 1 bis 15 (von insgesamt 17)