Hilfe bei Umzug WordPress zu netcup

  • Den Dokumentenstamm im Kundencenter stellst du auf das Verzeichnis, wo deine Wordpress-Installation liegt, also da wo die index.php ist.

    Erledigt, hatte ich vorher aber auch so verlinkt. Habe jetzt auch nochmal die Datenbank exportiert/importiert. User/PW kontrolliert. IP-Adresse statt DNS-Namen der Datenbank versucht. Mittlerweile habe ich nur eine weiße Seite :P


    Protokoll weiterhin mit:


    Code
    mod_fcgid: stderr: PHP Warning: Unknown: open_basedir restriction in effect. File(/var/www/web886/html/wp-content/nfwlog/ninjafirewall.php) is not within the allowed path(s): (/var/www/vhosts/hosting1x7.a2e5e.netcup.net/httpdocs/fokks/:/tmp/:/var/lib/php/sessions:/var/www/vhosts/hosting1x7.a2e5e.netcup.net/tmp) in Unknown on line 0
    mod_fcgid: stderr: PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0
    mod_fcgid: stderr: PHP Fatal error: Unknown: Failed opening required '/var/www/web886/html/wp-content/nfwlog/ninjafirewall.php' (include_path='.:/usr/local/php74/share/php74') in Unknown on line 0
  • Denke deine NinjaFirewall (Plugin?) macht hier noch Probleme.


    Nenne mal dein wp-content/plugins Ordner in wp-content/plugins.deactivate um und guck mal ob es dann geht. Wenn ja dann wieder zurück umbenennen und nur das NinjaFirewall Plugin im Ordner umbennen und nochmal probieren.

  • Kann es sein, dass /var/www/web886/html das Verzeichnis bei dem alten Hoster war?


    Jedenfalls ist /var/www/vhosts/hosting1x7.a2e5e.netcup.net/httpdocs/ das Netcup-Schema!


    Ich denke Deine DB enthält noch Verzeichnisse des alten Hosters. Das Problem ist, das PHP ein sehr eigenwilliges Serialisierungschema hat:

    Wenn Du /var/www/web886/html einfach durch /var/www/vhosts/hosting1x7.a2e5e.netcup.net/httpdocs/fokks im SQL-Dump ersetzt, kommst Du weiter, aber wahrscheinlich geht vieles auch kaputt.

    Vielleicht gibt es da ein Import-Plugin oder Export-Plugin das Dir helfen könnte...

    Produkte bei Netcup: Neues Webhosting (2018) / VPS G7, Debian Bullseye

  • Habe jetzt auch nochmal die Datenbank exportiert/importiert.

    Grundlagenwissen? Du wirst die betreffenden Teile der Datenbank schon anpassen müssen! Neu importieren bringt da wenig.


    Und ich dachte immer, Wordpress sei so einfach, dass es jeder kann.

    Es ist schon recht einfach. Aber dieses eine Plugin scheint irgendwo absolute Pfade zu nutzen. Da muss man dann halt schon mal in's phpMyAdmin gehen und das ausbessern.

  • Also mit Wordpress auf eine andere domain umzuziehen ist oft durchaus nicht trivial. (Kann ich aus eigener Erfahrung sagen ;))

    Insbesondere wenn man auf ein Webhosting umzieht, statt auf einen Server.

  • Da bin ich wohl verwöhnt. Domain und absoluter Pfad interessieren mich beim Umzug überhaupt nicht. Ich fluche schon wenn ich ein neues Verzeichnis und eine neue Datenbank dafür anlegen muss.

  • Vielleicht habe ich auch immer nur Pech gehabt, aber hier mal meine Erfahrungen bei meinen manuellen Umzügen: ;)


    Vor dem Umzug alle kritischen Plugins deaktivieren. (Alle die sich später an einem geänderten domainnamen stören könnten)

    (Ein Beispiel: Wenn man das beim Captcha-Plugin nicht gemacht hat, kommt man auch bei erfolgreichem Umzug u.U. nicht mehr rein und muss das Pluginverzeichnis temporär manuell umbenennen um wieder Zugriff zu erlangen)


    Bei Migration auf ein Webhosting muss als HOST die IP angegeben werden, statt localhost


    Nach einem manuellen Umzug muss man u.U. noch bei den Datei+Verzeichnisrechten nacharbeiten, sonst kommt u.U. das beliebte "forbidden"

    chmod -R a+r WP-PFAD

    find WP-PFAD -type d -exec chmod a+x {} +


    Wenn die neue domain nicht überall passt, kann man in die wp-config.php einfügen:

    define('WP_SITEURL', 'http(s)://WP-Verzeichnis');

    define('WP_HOME', 'http(s)://WP-Verzeichnis');

    Klappt meist, aber hier die Alternative

    https://www.netz-gaenger.de/bl…esse-oder-domain-aendern/


    Auch wenn alles gut aussieht, kann es sein das die ganzen Verlinkungen noch zur alten Seite zeigen, weil die in der DB verdrahtet sind.

    Um die zu ändern gibt es Plugins die das erledigen oder man macht es über die Kommandozeile mit wp-cli.phar

  • Grundlagenwissen? -> Mit Datenbanken hatte ich vor zehn Jahren mal was am Hut. Komme nicht aus der IT-Branche, muss mich daher immer wieder einlesen.

    wp-content umschreiben brachte leider auch nichts. Wollte jetzt via phpMyAdmin den Pfad zu "httpdocs/fokks/wp-content/nfwlog/ninjafirewall.php" anpassen, wusste jetzt aber nicht genau wo ich den Eintrag in der Datenbank finde.

    Habe auch schon überlegt ,WP direkt aus netcup neu zu installieren, um dort meine backups von "UpDraftPlus" zu ziehen.

    Ja, ich dachte das wird einfacher. CopyPaste, bissel was anpassen und Let`s go... falsch gedacht ;)

  • Ja, habe mal in den Link reingeschaut und bin wieder für ein Jahr kuriert. Umzugsservice 99,-€? Hrmpf. Ich habe mal eine Website zu Testzwecken auf 3 andere Hostings mit jeweils völlig anderer (Sub-)Domain dupliziert. Inklusive 5 GB Bilddaten. Ich glaub nicht mal, dass ich dabei irgendwo irgendeine Domain geändert habe, weil es eh alles Subdomains waren und ich mir die Umleitung auf www in der .htaccess deshalb sparen konnte. Haben auch alle Kopien sofort funktioniert. Ist das dann quadruplicate content? ^^:rolleyes:. Da wäre ich glatt auf deutlich mehr als 300,-€ Stundenlohn gekommen.

  • Ich würde mal die Anleitung von aRaphael durchgehen! Per ssh anmelden und die Befehle eingeben! Ob aber wp-cli.phar auf dem Server installiert ist, weiss ich nicht.


    Testweise kannst du alternativ zu wp-cli.phar den exportierten mysql-Dump vor dem Import mit einem Texteditor öffnen (nimm Notepad++) und /var/www/web886/html durch /var/www/vhosts/hosting1x7.a2e5e.netcup.net/httpdocs/fokks ersetzen - dann weist Du, dass es in diese Richtung gehen muss.


    Es gibt aber wirklich auch Migrations-Plugins! Habe ich schon mal gesehen, aber nie benutzt!

    Produkte bei Netcup: Neues Webhosting (2018) / VPS G7, Debian Bullseye

  • wp-content umschreiben brachte leider auch nichts. Wollte jetzt via phpMyAdmin den Pfad zu "httpdocs/fokks/wp-content/nfwlog/ninjafirewall.php" anpassen, wusste jetzt aber nicht genau wo ich den Eintrag in der Datenbank finde.

    Sollte in der "options" Tabelle sein. Den SQL-Query hatte ich hier schon gepostet.

    Auch wenn alles gut aussieht, kann es sein das die ganzen Verlinkungen noch zur alten Seite zeigen, weil die in der DB verdrahtet sind.

    Um die zu ändern gibt es Plugins die das erledigen oder man macht es über die Kommandozeile mit wp-cli.phar

    In so einem Fall würde ich das vorher einfach im Dump ersetzen.Aber die Domain soll hier ja garnicht geändert werden.

  • Gibt es das alte Hosting noch?


    Würde jetzt auf dem alten Host das Plugin NinjaFirewall komplett löschen (via WordPress - Plugins) und dann die DB nochmal exportieren. Oder man müsste mal gucken was diese php Datei macht die den Fehler produziert.


    Gerne kann ich auch mal drüber gucken, kenne mich mit WP Migrationen eigentlich sehr gut aus. Wenn gewünscht einfach PM.


    Gerade noch gefunden :


    Quote

    Aber Sie müssen vorsichtig sein:

    1. Migrieren (auf einen anderen Server umziehen) Sie NICHT Ihre Website mit installierter NinjaFirewall. Stattdessen exportieren Sie die Konfiguration, deinstallieren Sie Ninja­Firewall und migrieren Sie Ihre Website. Nach dem Migrieren installieren Sie Nin­ja­Fire­wall neu und Reimportieren Sie die Konfiguration. Das geht alles über das Dashboard.

    Wenn die alte Installation nicht mehr zugänglich ist müsste man die Firewall angucken was die macht beim Deinstallieren und diese Funktionen manuell durchführen.

  • Ja, habe mal in den Link reingeschaut und bin wieder für ein Jahr kuriert. Umzugsservice 99,-€? Hrmpf. Ich habe mal eine Website zu Testzwecken auf 3 andere Hostings mit jeweils völlig anderer (Sub-)Domain dupliziert. Inklusive 5 GB Bilddaten. Ich glaub nicht mal, dass ich dabei irgendwo irgendeine Domain geändert habe, weil es eh alles Subdomains waren und ich mir die Umleitung auf www in der .htaccess deshalb sparen konnte. Haben auch alle Kopien sofort funktioniert. Ist das dann quadruplicate content? ^^:rolleyes:. Da wäre ich glatt auf deutlich mehr als 300,-€ Stundenlohn gekommen.

    Naja, das ganze geht ja auch billiger (*Hust, Hust* Eigenwerbung.)


    Nicht jeder hat Zeit und Lust sich mit einem Wordpress Umzug herumzuschlagen. Wie man an diesem Post hier gut erkennt, kann das auch gerne mal komplexer werden und da der Threadstarter seit Montag keine erreichbare Webseite mehr hat, wären die angesprochenen 99€ wohl gut investiert gewesen ^^.

  • ArtCore7 Ja, Webhosting samt Daten auf FTP und Datenbank gibt es noch. Allerdings liegt die Domain ja jetzt hier bei netcup, komme daher auch nicht auf das Dashboard von WP weil halt "abgeschossen" Danke für das Angebot, behalte ich im Kopf.
    Könnte es dort nochmal auf eine andere Domain schalten, aber dann passen ja auch wieder einige Einträge nicht.

    NinjaFirewall: Ja, warum installiert? Haben mir diverse WP-Gurus auf Reddit bzw. anderen Foren empfohlen, daher die Installation ;)
    Das mit dem deaktivieren were ich mir für die Zukunft merken, da hab ich mich selbst gefailt.

    Es ist ein privater eSports-Blog von mir, war die letzte Zeit inaktiv, von daher kann ich die Downtime noch verschmerzen - auch wenn mich die bisherigen Stunden an Fehler suchen doch schon nerven ;)

  • Ich wollte damit nur sagen dass manche Sicherheitslösungen meistens mehr Probleme verursachen als das sie lösen.

    Und umso umfangreicher und toller, umso tiefer sitzen die im System drin und umso mehr Probleme erzeugen die oftmals.

    NinjaFirewall scheint mir da ein schönes Beispiel zu sein. Laut der Beschreibung klemmt der sich ja in jede Anfrage die an Wordpress geht.

    Das erscheint mir ziemlich gruselig und übertrieben.


    Wordpress ist nicht so unsicher wie alle immer behaupten. Nur gut gepflegte Plugins und Themes, starke Passwörter, vielleicht noch ein htaccess Schutz auf /wp-admin und fertig ist die Laube. Irgendein dahergelaufendes Securityplugin zu installieren reißt da wahrscheinlich mehr Lücken auf als das es stopft.


  • Hier mal der Uninstaller von NinjaFirewall


    Was du auf der neuen Seite mal schnell von Hand machen kannst:


    wp-config.php bereinigen:
    Öffne deine wp-config.php im Root Verzeichnis und lösche alles zwischen // BEGIN NinjaFirewall -> // END NinjaFirewall


    .htaccess bereinigen:

    Öffne deine .htaccess im Root Verzeichnis und lösche alles zwischen # BEGIN NinjaFirewal -> # END NinjaFirewall


    PHP INI bereinigen:

    Finde php.ini / php5.ini / .user.ini in dem NinjaFirewall Ordner und lösche alles zwischen ; BEGIN NinjaFirewall -> ; END NinjaFirewall


    Lösche NinjaFirewall Datenbankeinträge (wahrscheinlich in wp_options):

    Code
    delete_option('nfw_options');
    delete_option('nfw_rules');
    delete_option('nfw_install');
    delete_option('nfw_tmp');
    delete_option('nfw_checked');
    delete_site_option('nfw_options');
    delete_site_option('nfw_rules');
    delete_site_option('nfw_install');
    delete_site_option('nfw_tmp');
    delete_site_option('nfw_checked');

    Guck ob der Fallback Loader exestiert und lösche ihn.

    -> 0-ninjafirewall.php


    Zwar sind dann noch die Cronjobs von NFW da, aber die Seite sollte erstmal wieder gehen.