Beiträge von b3317133

    Das kommt durch ein "Feature" von MySQL.

    Vermutlich verwendet Deine Installation für die entspr. Tabelle bzw. Spalte die Collation [FONT=Courier New]utf8_general_ci[/FONT] wodurch a und ä gleichgesetzt werden, übrigens auch mit á oder â und ähnlichem.

    Wenn die Tabelle oder Spalte die Collation [FONT=Courier New]latin1_german[COLOR=#ff0000]2[/COLOR]_ci[/FONT] hätte, würde die Suche nach ahlen keine Ergebnisse mit ählen bringen.

    Mit dem PHP Code in der WordPress Suche hat das also nichts zu tun.

    Ob / welche Nebeneffekte es gibt, falls man die voreingestellte Collation für die entspr. Tabellen oder Spalten verändert, kann ich Dir nicht sagen, das müsstest Du selbst testen oder nachlesen...

    Hat jemand eine Idee? Und was ist eigentlich passiert, wurden wir gehackt?


    Offensichtlich sind Inhalte in euerer Datenbank verschwunden.

    Das kann viele Gründe haben. Von Fehlern beim Hostinganbieter, über "Basteleien" eines WordPress Admin Benutzers, über Fehler in einem "Optimierungs"-Plugin, bis hin zu gehackt worden.

    Das gehackt worden kann auch unterschiedliche Tiefen haben, von "nur" Zugangsdaten der Datenbank abhanden gekommen (z.B. aktueller Fall hier), über Hack via PHP mit entspr. Backdoorscripts auf dem Server (dafür access logs beim Hosting sichern/prüfen), bis hin zu PC des Admins kompromitiert und alle Zugangsdaten von dort mitgeschnitten o.ä.

    Wenn es denn ein Hack war, dann ist er fehlgeschlagen. Erfolgreiche Hacks sieht man in der Regel nicht.

    Falls kein eigenes Backup vorhanden ist, wende Dich am besten an eueren Hostinganbieter frage nach, ob die sowas haben und ggf. (bei manchen auch kostenpflichtig) wieder einspielen können.

    Die Ermittlung der Ursache wäre das wichtigste, sonst wird das wieder passieren.

    Dein neu eingefügter Admin Benutzer hat vermutlich (noch) nicht die passenden Rechte, evtl. war die SQL-Anleitung unvollständig oder falsch, Link zu dieser Anleitung?

    Du nutzt derzeit vermutlich einen Mischmasch aus einer Installation auf einem externen Server (bei Domainfactory?) und lokal bei Dir, siehe auch der mMn. falsche siteurl Eintrag in #7.

    Schau Dir die aktuelle Seite mal mit einem anderen PC an, wo Du nicht WordPress lokal installiert hast, dann siehst Du, wie das derzeit für den Rest der Welt aussieht.

    Mit den # Zeichen sind die Beiträge in diesem Thead gemeint, die Nummer steht immer unten rechts.

    #4 Jede Zeile mit "Nicht getestest mit ..." kann Probleme verusachen, das Plugin WooCommerce ist veraltet.

    #5 Die WordPress Version passt nicht zur fast 2 Jahre alten Theme Version und die PHP Version vermutlich ebenso nicht.

    Es grenzt etwas an ein Wunder, dass die Seite überhaupt irgendwie läuft.

    Ergänzung:
    Eine Herangehensweise das alles zu bereinigen wäre Backups der Dateien und Datenbank erstellen und dann sukzessive Theme aktualisieren, dabei vorab prüfen, ob im Theme was manuell verändert wurde, das in die neue Version umbauen bzw. ein Child-Theme nutzen, dann WooCommerce aktualisieren, vorher prüfen, welche der vielen sonstigen extra WooCommerce Plugins man überhaupt braucht und prüfen, ob diese mit der neuen WooCommerce Version und der neuen PHP Version zusammenarbeiten, alle sonstigen Plugins prüfen, einige sind nicht aus dem Plugin Repository sondern aus anderen Quellen und dort gibt es ggf. neue Versionen wie beim wahllos zufällig recherchierten "Wonder Slider Lite" usw.

    Um das Login-Probem noch weiter einzugrenzen, was genau wurde denn gemacht, bevor das eingetreten ist? Und was steht im PHP Error-Log des Servers (das bekommst Du beim Hostinganbieter) wenn die nicht funktionierenden Loginversuche stattfinden.

    Die .htaccess sieht soweit ok aus, das stammt alles vom WP Rocket Plugin. Am Rande bemerkt, während einer Fehlersuche sollte man alle Cache- und Optimierungsplugins deaktivieren.

    Wenn man im Login-Dialog der Seite "Passwort vergessen" klickt, geht der Link ins Leere, Fehler 404, würde mal hier anfangen wenn man nach Login-Problemen sucht. Woher kommt dieser Link?

    Code
    https://[...]/lost-password/?page_id=1058

    Die restliche Problematik zu fehlender Kompatibilität, veralteten Plugins usw. steht ja bereits in #5 und in Deiner Liste in #4.

    Ich muss codeseitig prüfen ob ein custom post type editiert werden kann,


    Verwende sowas wie das hier, Pseudocode, ungeprüft.

    Code
    if ( post_type_exists( $dein_post_type ) ) {
    ...
      $post_type = get_post_type_object( $dein_post_type );
      ..
      if ( current_user_can( $post_type->cap->edit_posts ) ) {
       ...


    Und schau Dir die Links zum Bearbeiten der CF7 Einträge mal genauer an, vergleiche den Link, den Du generierst mit dem Link den das Plugin im Backend generiert.

    Ergänzung: Und noch ein Tipp, schreibe keine Werte in die Datenbank, die Du über ein Cookie oder GET Parameter bekommst... :oops:

    Meine letzte Änderung davor war diese : Ich habe ein Problem, dass Änderungen im dashboard nicht in den SQL-Datenbanken gespeichert werden. Der letzte Eintrag in wp_posts ist vom 14.02., seitdem tat sich nichts mehr.

    Wie gross ist die Datenbank, in der nicht gespeichert werden konnte? Screenshot phpMyAdmin der Tabellenübersicht mit Grössenangaben?

    Die aktuelle unter dem genannten Link erreichbare Seite hat derzeit als siteurl diesen Eintrag, das kann nicht funktionieren:

    Code
    http://localhost/sparenundauszahlen


    Wende Dich ggf. an die Person, die den Website ursprünglich für Dich auf dem Server eingerichtet hat, das sollte das Problem am einfachsten lösen.

    Ok, also verwendest Du WordPress 5.x mit einer älteren Version eines Themes, das lt. Changelog erst mit der Folgeversion für WordPress 5.x kompatibel gemacht wurde. Ebenso eine Reihe weitere Plugins mit unklarem Alter bzw. Kompatibilität. Und ein vergleichsweise sehr neues PHP.

    Daher ist das sehr schwer einzugrenzen.

    Welche .htaccess mit welchem Pfad genau wurde temporär gelöscht? Was steht drin? Auf welchem Website war das beschrieben?

    Hast Du testweise einen neuen Admin angelegt? Kann der sich anmelden?

    Link zur Seite fehlt leider weiterhin, manchmal ist auch "ein Blick von aussen" schon sehr hilfreich bei einer ersten Analyse.

    Falls der Austausch einer Bilddatei unter dem gleichen Namen wie bisher auf den CDN-Servern von Jetpack in den USA gemeint ist, das geht nicht ohne manuellen Eingriff des Jetpack Supports. Bei Interesse mehr dazu hier. Nebenbei bemerkt ist diese Auslagerung von Dateien usw. ein problematisches Thema bzgl. DSGVO.

    Tipps am Rande:

    • Wenn man WordPress manuell einen temp Ordner geben muss, ist erfahrungsgemäss noch irgendwas im Hosting nicht in Ordnung.
    • Ein temp Ordner in einem "von aussen" z.B. via Webbroser erreichbaren Ordner auf dem Server kann zudem ein Sicherheitsproblem sein.

    Die wp-login.php redirect Weiterleitung ist eine Standard Weiterleitung beim Aufruf von /wp-admin/

    Welche WordPress Version, welches Theme und Version und welche Plugins wurden eingesetzt?

    Ist die Seite auf irgendeine Art und Weise auch von aussen im Internet zugänglich? Link?