Beiträge von b3317133

    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?

    Die Dateien werden jetzt im Ordner aufgelistet, führen aber zu einem 404 Fehler.

    Welche Rechte und Besitzer haben die Dateien jetzt? Screenshot? Wurden diese Dateien über WordPress Mediathek hochgeladen oder per FTP? Das kann bzgl. der Rechte einen Unterschied machen. Derzeit ist übrigens mindestens wieder das WPGlobus Plugin aktiv, alle Plugins sollten bei so eine Fehlersuche deaktiviert sein.

    Was steht in der Datei .htaccess im Ordner /public_html/ ?

    Wie man das Auflisten abstellt weiss Dein Hostinganbieter, bei den allermeisten Anbietern ist es standardmässig abgestellt.

    Leider sieht man auf Deinem Screenshot vom Server weder die Pfade noch die "Besitzer" Spalte. Ebenso wäre ein Screenshot des übergeordneten Ordners ggf. hilfreich.

    Wenn man die Ordnerpfade im Browser aufruft, ergibt sich derzeit folgendes (abgesehen davon, dass das Auflisten eigentlich abgestellt sein sollte):

    Code
    https://www.gabi-kunz.com/wp-content/uploads/2020/01/ - viele Dateien verden aufgelistet
    https://www.gabi-kunz.com/wp-content/uploads/2020/02/ - keine einzige Datei


    Ergänzung: Auch über die REST-API sind keine Dateien ab 01.02.2020 sichtbar:

    Code
    Dateien ab 01.01. (viele) https://www.gabi-kunz.com/wp-json/wp/v2/media/?per_page=100&orderby=date&order=desc&after=2020-01-01T00:00:00
    Dateien ab 01.02. (keine) https://www.gabi-kunz.com/wp-json/wp/v2/media/?per_page=100&orderby=date&order=desc&after=2020-02-01T00:00:00


    Die neuste Datei in WordPress ist offenbar vom 24.01.2020 und heisst gabiiquer.jpg - evtl. hilft das bei der weiteren Eingrenzung.

    Das steht z.B. in Step 7 bzw. Step 8 der verlinkten Hinweise.

    Auch zu beachten sind natürlich die restlichen Hinweise, v.a. zum Thema Backup.

    Falls Du damit eher wenig anfangen kannst, suche Dir ggf. lieber jemanden in Deinem Umfeld mit entspr. Erfahrung mit WordPress, damit nicht versehentlich der Website unwiederbringlich zerstört wird.