Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenBei der Nutzung von Elementor sollte man nach Umzügen dessen CSS neu generieren lassen, siehe Elementor Dokumentation: Regenerate CSS, hilft das?
Die [FONT=Courier New].htaccess[/FONT] Datei passt so und hat mit den Problemen nichts zu tun.
Bei Fragen zur Darstellung Link zur Seite posten, sonst ist Hilfe ein Ratespiel, siehe auch Forenregeln, Punkt II.
Entferne die Datei [FONT=Courier New]index.html[/FONT]
Wende Dich dafür an den WordPress.com Support, dieses Forum ist nur für selbstgehostetes WordPress von WordPress.org, die Unterschiede sind z.B. hier erklärt.
Beim verlinkten Website ist unter Einstellungen > Lesen eine "statische Seite" mit dem Namen "Startseite" als Startseite eingestellt.
Stelle "Deine letzten Beiträge" als Startseite ein, dann wird das "Beitrag auf der Startseite halten" auch funktionieren.
Oder rufe die bei Einstellungen > Lesen ggf. eingestelle "Beitragsseite" auf.
Auf Kategorieseiten funktioniert das oben halten nur mit extra Plugins.
Die Parameter von [FONT=Courier New]border-collapse[/FONT] sind falsch, versuche es z.B. damit:
border-collapse: collapse; border: solid #0000ff;
Wenn damit kein Rahmen angezeigt wird, liegt es an anderem CSS, dann kann man nur mit Link zur Seite weiterhelfen, siehe auch Forenregeln, Punkt II.
Dass nur die Info verschickt wird, ist schon klar. Aus der Grösse des Dateibackups könnte man ggf. ableiten, ob alles durch eine dadurch verursachte hohe Serverlast bzw. Dauer beim Ablegen des Backups in Timeouts rennt o.ä., nochmal die Fragen mit mehr Details:
Lt. Log kann für die Ermittlung von Benutzerdaten zum Versand der E-Mail nicht auf den Datenbankserver zugegriffen werden, das dürfte den E-Mail Versand verhindern.
Vielleicht hilft auch dieser Thread mit einem ähnlichen Problem im WordPress.org Support Forum weiter, mit Verweis auf diesen Lösungsansatz.
Siehe damaliger Thread:
Das allgemeine Vorgehen bei einem Hack ist z.B. hier beschrieben, das könntest Du mit jemandem mit WordPress Erfahrung bei Dir im näheren Umfeld zusammen durchgehen.
Dabei am Wichtigsten wäre, die für den Hack genutzte(n) Lücke(n) zu ermitteln, damit das nicht wieder passiert.
Was also muss ich machen das die frische Installation auch die Daten meiner Homepage wieder findet ?
Keine Tabellen löschen, die [FONT=Courier New]wp-config.php[/FONT] aus der alten gesicherten Version hochladen, fertig.
Natürlich kann die Ursache für Dein "nicht mehr richtig laufen" auch irgendwo in der Datenbank oder im Falle eines Hacks auch in der [FONT=Courier New]wp-config.php[/FONT] selbst sein, das wäre dann herauszufinden.
Es handelt sich um das gleiche Problem wie hier vor ca. 5 Wochen, nur diesmal mit Spitzwegerich statt mit Dost.
... Und entferne den id bei der Auflistung der Links, leere dafür das Feld auf dem Screenshot rechts bei "HTML Anker", ein id darf nicht doppelt vorhanden sein.
Diesmal fehlt beim vermutlich als Ziel gewünschten Absatz "Echter Dost origanum vulgare" die Eingabe "Dost" bei HTML-Anker. Also runterscrollen, den Absatz anklicken und dort den HTML Anker eingeben.
Ähnlich wie bei Deinem vorherigen Problem stimmt etwas mit der Einstellung der Permalinks bzw. des Servers nicht.
Die einfachste Lösung wäre, genau das rückgängig zu machen, was jetzt (wieder) zu einem solchen Effekt geführt hat.
Wende Dich am besten an die Person, die Deinen Server technisch verwaltet und lasse das prüfen, entspr. Hinweise zu Deinem Server z.B. hier in der WordPress Dokumentation.
Ergänzung: Vermutlich ist irgendetwas mit dem 404 Handling defekt.
Was genau geht mit dem Plugin nicht? Und entgegen welcher Angaben? Das Zitat ist einfach ein Text, der ausgegeben wird, bevor eine Liste vermeintlich ungenutzter Medien ausgegeben wird. Was stimmt daran nicht?
Solche Plugins sind "Skripte", die alle möglichen Szenarien des Vorkommens von Bildern durchprüfen.
Mit dem Filter 'Nicht angehängt' kann ich nicht arbeiten, da ein Page Builder installiert
Daher brauchst Du ein Skript bzw. ein Plugin, das genau weiss, wie/wo Dein Page Builder jegliche seiner Bilder einbindet.
Und falls auf dem Website noch Plugins verwendet werden, die auch auf Bilder verweisen, z.B. ein Slider o.ä., muss dieses Skript bzw. Plugin auch dessen Speicherorte und Datenbankstrukturen usw. genau kennen und auswerten.
Und falls Dein Theme irgendwelche Theme Optionen hat, die auf Bilder verweisen, gilt das gleiche auch für Dein Theme bzw. Child Theme.
All das ist relativ aufwändig und daher kostet es in der Regel Zeit und Geld, sowas zu entwickeln und zu nutzen.
Bislang ist weder Page Builder, Plugins noch Theme bekannt. Siehe auch Forenregeln, Punkt II
Über die eigentlich dafür gedachte und oben verlinkte WordPress API würde man an die Bilder dieses Plugins ganz einfach z.B. so kommen, da sich das Plugin über entspr. Hooks transparent in die WordPress API integriert.
$allemitglieder = get_users( array( 'orderby' => 'display_name', 'order' => 'DESC' ) );
foreach ( $allemitglieder as $mitglied ) {
echo get_avatar( $mitglied->ID, 250 );
}Deine lokale Datenbank Version akzeptiert den im SQL angegebenen default Wert nicht, diverse Lösungsansätze sind hier beschrieben, z.B.
SET GLOBAL SQL_MODE ='ALLOW_INVALID_DATES';
Kann aber nicht sagen, wie/wo das bei Deinem lokalen Mac anzupassen ist.
ich musste danach die wp_options anpassen und einen neues WP user über die datenbank anlegen um ins backend der seite zu kommen
Offenbar wurde im Punkt 1. der Anleitung dieser Absatz übersehen:
If your site is moving location (i.e. changing URL), then you will also want to add WP_HOME and WP_SITEURL parameters to the wp-config.php file. See here and here. (If you do not, then you will not be able to log in).
Weiterhin die o.g. Ergänzung zum [FONT=Courier New]$table_prefix[/FONT] beachten.
Die Beiträge und Seiten sollten erscheinen, wenn gemäß Punkt 3. der Anleitung die DB.gz des Backups in die Datenbank importiert wird.
Ergänzung: Wenn sie trotzdem nicht erscheinen, ist möglicherweise ist das sog. [FONT=Courier New]$table_prefix[/FONT] Deiner frischen lokalen Installation anders als in der DB.gz bzw. der gehackten Installation, passe in dem Fall in der lokalen [FONT=Courier New]wp-config.php[/FONT] das Präfix entsprechend an, mehr dazu z.B. hier unter Advanced Options.
Und was genau funktioniert daran nicht? Link zur Seite wo man das ansehen kann? Siehe auch Forenregeln, Punkt II
Folge z.B. der "manual restore" Anleitung in der UpdraftPlus Dokumentation.
mal mit der Permalink-Struktur rumprobiert aber leider immer die selbe Ausgabe.
Was genau hast Du probiert?
/%category%/%postname%/