Beiträge von ArtCore7

    Hört auf mit Abuse...


    Meine NAS hat den Netcup Mail SMTP gespamt (Fehl Konfiguration meinerseits) und am 25.07 um 20:43 hat dann der Abuse Mitarbeiter gerechtfertigt mein Webhosting gesperrt.


    Ahhhh


    Jetzt heißt es warten bis der wieder frei ist ?


    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.

    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 :


    Zitat

    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.

    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.

    Notebooks sind das einzige, was wir nicht von denen haben ^^ Da gibts nur Lenovo.

    Anfangs hab ich auch mit der Stirn gerunzelt, aber kann mich sonst eigentlich nicht beklagen :)

    Wir mussten von IBM / Lenovo auf Fujitsu wechseln weil die Chaoten die Ausschreibung gewonnen haben. Die 12/13" und 15" Geräte gehen von der Verarbeitung gerade noch so. Aber bei den 14" Modellen die zum Einsatz kommen <X. Ich bin froh das ich aktuell noch das letzte Ultrabook welches noch von Lenovo kam im Einsatz habe und hoffe auf neue Ausschreibungen ;)


    Gleich mal in die Datenbank gucken was whoami0501 im Einsatz hat und ein wenig drüber lachen :evil:

    Auch gut finde ich die damals ja aktuellen Zeichen im <title> - = Netcup = - :D

    Kannst ja für dich übernehmen :D


    WordPress Seite und schlechte Performance bei Netcup im Webhosting... Ich glaub dieses Lied wiederholt sich langsam zu oft.


    Ich werde auf jedenfall die Tage ein Ticket an den Support aufmachen. Es kann doch nicht sein, dass der Webspace echt gut läuft und die Datenbank Server wohl über die Grenzen hinaus komplett überbucht sind.


    PS: Ja es liegt zu 95% am DB Server von Netcup


    [netcup] Felix P. : Eventuell kann man hier mal was dazu sagen. Ich will ja nicht die Performance wie auf meinem VPS500 mit einer DB. Aber Ladezeiten bis 10 Sekunden (im schlechtesten Fall) im WordPress Backend verkrault eben eure Kunden (siehe Thread Starter)

    Gleiche Probleme habe ich auch festgestellt und kann dir nun mit Sicherheit sagen es liegt bei WordPress an den Datenbank Servern.


    Da ich noch einen ungenutzten VPS500 hatte habe ich dort mal die DB hingezogen und siehe da. Ich hab Query Monitor Zeiten von unter einer Sekunde im Backend. Da macht das Arbeiten wieder Spaß.


    Bin grad am Handy, aber hier auch ein Screenshot aus Query Monitor im Dashboard.


    Screenshot_20200624-070655_Chrome.jpg

    Gerade nochmal mit


    mysqld  Ver 10.2.32-MariaDB-1:10.2.32+maria~bionic for debian-linux-gnu on x86_64 (mariadb.org binary distribution)


    getestet, hier tritt der Fehler nicht auf.


    Edit: War wohl ne Sekunde schneller :D

    Gerade gefunden bei meinem Pagebuilder .... die haben es wohl gefixt. Ich hab es nicht upgedated (Lizenz ausgelaufen)


    Bug Fixes

    • Fixed database query issue when duplicating layouts on MariaDB 10.3+


    PHP
    // @codingStandardsIgnoreStart
    $wpdb->query( "INSERT INTO {$wpdb->postmeta} (post_id, meta_key, meta_value) values ({$new_post_id}, '{$meta_key}', '{$meta_value}')" );
    // @codingStandardsIgnoreEnd


    Trotzdem bleibt ja der Fehler bei UNION ALL bestehen.

    Version in meinem Fall:


    Code
    mysqld  Ver 10.4.13-MariaDB-1:10.4.13+maria~focal for debian-linux-gnu on x86_64 (mariadb.org binary distribution)


    Hab dann auch noch schnell getestet:


    'fl_builder_data' als erstes SELECT ausführen, und danach die anderen "kurzen" Daten.

    - Auch beim ersten SELECT mit den langen Daten wird das ganze gekürzt.


    'fl_builder_data' mit "Lorem ipsum" Text ersetzen und erneut versuchen.

    - Auch mit Lorem ipsum Text wird das ganze gekurzt. Also auch kein Problem mit meinen Daten.

    Werde später noch ein wenig rumspielen und mal gucken ob es mit "Lorem ipsum" Text zu den selben Problemen kommt. Nur aktuell leider keine Zeit.


    Geplannte Versuche:

    • 'fl_builder_data' als erstes SELECT ausführen, und danach die anderen "kurzen" Daten.
    • 'fl_builder_data' mit "Lorem ipsum" Text ersetzen und erneut versuchen.
    • PHP Script umbauen, das er jedes Query einzeln an die DB schickt <- Workaround. (Nach Update des Pagebuilder immer wieder dran denken <X)