Beiträge von b3317133

    Dieser "Bilderklau"-Blockade Code - wenn er denn überhaupt so funktioniert - wird derzeit auf dem o.g. Website durch das Jetpack Plugin aktiv ausgehebelt, das alle Bilder auf irgendwelche externen Server in den USA oder sonstwo verteilt hat und von dort aus einbindet. Nebenbei verursacht das auch noch ein DSGVO Problem.

    Für spätere Mitleser:

    Die PHP Version bei Strato stellt man üblicherweise in diesem Menü um:

    Datenbanken & Webspace > PHP-Version einstellen

    Und bei einer manuellen Einstellung über .htaccess ist selbstverständlich dieses Leerzeichen nötig und korrekt, es trennt den Medien-Typ von der Dateiendung.

    Das erste Beispiel funktioniert hier am Beginn der .htaccess wie erwartet.

    Code
    example.com/meine-seite/blabla


    wird weitergeleitet zu

    Code
    example.com/subdirectory/meine-seite/blabla


    Oder meinst Du etwas anderes?

    Wenn dabei auch meine-seite ohne / am Ende weitergeleitet werden soll, lass den / in Deiner Regel weg, z.B.

    Apache Configuration
    RewriteRule ^meine-seite(.*)$ /subdirectory/meine-seite$1 [R=301,NC,L]


    Ansonsten poste echte Links und erkläre, was damit nicht funktioniert.


    ...... stimmt natürlich nicht!


    Was genau stimmt daran nicht?


    Kleiner Blick in einige wordpress.org Profile der zitierten Statements - daran ist wohlgemerkt nichts schlimmes, es ist vielmehr eine tolle Sache, wenn Mitarbeiter an einem Projekt auch hinter ihrem Projekt stehen und positive Rückmeldungen geben, wie gesagt, das nur am Rande zur Einordnung...

    Du hast wie vermutet die Datenbank der aktiven Installation bereits überschrieben. Die Daten sind nicht mehr in der Datenbank vorhanden.

    Lösungsmöglichkeiten siehe oben.

    Duplicator zeigt im Installationsverlauf eigentlich eine recht klare Warnung an, bevor Datenbanken überschrieben werden.

    Eine bestehende Installation zu kopieren und dabei das Datenbank-Präfix zu verändern, ist bei WordPress am Rande bemerkt mit Vorsicht zu geniessen, nicht jedes Theme bzw. Plugin kommt damit zurecht. Die Duplicator Pro Version hat wohl Funktionen dafür, aber auch das kann an Grenzen stossen, wenn irgendwas nicht den WordPress Standard einhält.

    Wurde installer.php von Duplicator verwendet?

    Möglicherweise hast Du für die Test Installation die Datenbank Zugangsdaten der aktiven Installation angegeben statt eine neue, eigene, zweite Datenbank zu verwenden. Das würde einen Effekt wie von Dir beschrieben zur Folge haben.

    Die aktive Installation wieder hinbekommen kann man so einen Fall durch das Einspielen eines Datenbank Backups der aktiven Installation in die zugehörige Datenbank und das Leeren des Browser Caches.

    Alternativ durch das Einspielen des ganzen Duplicator Paketes über domain.de/vw/installer.php als aktive Installation und das Leeren des Browser Caches.


    Liegt das Bild für den Beitrag vermutlich in

    ~/wp-content/uploads/2016/

    ein neues hochladen bringt das Bild aber in das Verzeichnis
    ~/wp-content/uploads/2022/


    Wenn man ein neues Bild über die Beitragsbildsfunktion in einem alten Beitrag von 2016 hochlädt, speichert WordPress das Bild im alten Verzeichnis des zum alten Beitrag zugehörigen Monats in 2016.

    Um ein Beitragsbild "URL-gleich" zu ersetzen, löscht man daher zunächst das bestehende Beitragsbild im Beitrag und Mediathek und lädt dann ein Bild mit dem gleichen Dateinamen über die Beitragsbildsfunktion im bestehenden alten Beitrag hoch. Danach ggf. Browser-Cache leeren, wenn noch die alte Version des Bildes gezeigt wird.

    Will man eine neue URL bzw. das Hochladen in den aktuellen Monatsordner bewirken, lädt man das neue Bild erst direkt in die Mediathek hoch und fügt es erst später in einen alten Beitrag ein.

    Ein Tausch über FTP ist nicht nötig.

    Am Rande bemerkt: Tauscht man ein Bild per FTP aus, muss man noch zusätzlich über ein Plugin o.ä. die restlichen Bildgrössen neu erzeugen lassen.