Beiträge von b3317133

Zitat von neWPendant

Wo sind diese Zeilenumbrüche, die Du meinst, sehe die nicht.

Siehe oben, vor [FONT=Courier New]<?php[/FONT] oder nach [FONT=Courier New]?>[/FONT] in der inzwischen gelöschten Datei [FONT=Courier New]wpsite/wp-config.php[/FONT]

Tipp: Es liegt nicht am Theme, wenn überzählige Zeilenumbrüche in der wp-config.php landen...

Funktioniert es denn mit PHP 7.2 auf dem Zielserver?

Dank dem endlich zur Verfügung gestellten Link zu Deiner Seite in der geposteten Fehlermeldung kann man feststellen:

Die Links auf der wpsite Startseite zeigen nicht in den [FONT=Courier New]wpsite[/FONT] Ordner, Umzug mit Ersetzen hat nicht geklappt, probiere es mit Duplicator.

Bei nicht gefundenen Seiten im Ordner [FONT=Courier New]wpsite[/FONT] wird einfach nur der Text "Page not found" ausgegeben, das ist keine standard WordPress 404 Seite, ausser das Theme würde sowas machen, probiere es mit Twenty Seventeen Standardtheme.

Durch die [FONT=Courier New]wp-config.php[/FONT] Datei werden drei 0x0a Zeichen = Zeilenumbruch ausgegeben, das führt zur "Cookies" Fehlermeldung. Offenbar wurde dort manuell irgendwas eingegeben z.B. vor [FONT=Courier New]<?php[/FONT] oder nach [FONT=Courier New]?>[/FONT] oder es ist ein Trojaner, schlecht programmierte machen sowas auch ganz gern...

PS. Das ist ein öffentliches Forum, wo alle Mitleser aus Fehlermeldungen lernen, extra Daten per PN zuzusenden nutzt dabei niemandem etwas. Für Dinge, die nicht öffentlich sein sollen, bitte die Jobbörse nutzen.

Wenn es ansatzweise mehr Infos geben würde, könnte man Dir vielleicht helfen. Du könntest das Verzeichnis der Plugins temporär umbenennen, die PHP Version prüfen usw.

Steht da evtl. noch was auf der Login Seite? Link zur Login Seite? Was steht im Error Log des Hosters?

Mit SSL hat das erstmal gar nichts zu tun.

Funktioniert es denn mit Duplicator?

Und was genau bedeutet "komme nicht ins Backend"? Link zur Seite?

Und befinden sich .htaccess Dateien im WordPress Ordner oder in übergeordneten Ordnern?

Am Rande: Die "Lösung" oben mit "Zeile 404 der load.php" ist keine echte Lösung des Problems, sie nutzt jetzt hardgecodete Strings anstelle von undefinierten Konstanten. Auch der "Fix" im trac Changeset ist nur Kosmetik, der nutzt hardgecodete Leerstrings für alle Felder. Ein echter Fix würde [FONT=Courier New]new wpdb( .. )[/FONT] gar nicht erst aufrufen, wenn die Konstanten nicht definiert sind.

Probiere es mal mit "Einstellungen > Permalinks speichern".

Alternativ mit einem Plugin wie z.B. Duplicator, das für Umzüge zwischen Servern gedacht ist und das alles nötige Ersetzen in der Datenbank automatisch erledigt.

Dein genanntes "Generator" Plugin macht was anderes, lies nochmal nach.. ein Child Theme Gerüst hast Du schon beim Theme Kauf mitgeliefert bekommen.

Wahrscheinlich hilft ein [FONT=Courier New]wp_reset_postdata()[/FONT] am Ende des Shortcodes, siehe z.B. die "Note:" im ersten Absatz hier, und auch die Code-Beispiele.

Zitat von Lencer

Leider wurden dann schon alle registrierten Personen auf der Mailliste über den neuen Beitrag informiert.

Wende Dich ggf. mal an den Autor des Plugins, das diesen automatischen Versand macht, dort wäre eine solche Funktion mMn. am besten aufgehoben.

Änderungen in Parent Theme-Dateien werden bei jedem Theme Update überschrieben. Änderungen dort musst Du manuell in das Child Theme übernehmen.

Änderungen im Backend (z.B. Theme Einstellungen, das Feld "Zusätzliches CSS" im Customizer usw.), die in der Datenbank gespeichert sind, müssen bei Wechsel zum Child Theme in der Regel neu eingerichtet werden. Für viele Themes klappt das mit einem (älteren) Plugin Inherit Theme Mods ganz gut, bei anderen muss man manuell tätig werden. Kommt ganz auf das Theme an. Backup machen, experimentieren...

Gibt es vor Beginn der Installation ggf. bereits eine Datei wp-config.php im Verzeichnis der WordPress Dateien? Oder im übergeordneten Verzeichnis? Falls ja, benenne diese Dateien mal um. Welche genaue WordPress Version wurde hochgeladen? Wurde die WordPress Version von hier heruntergeladen? Ist das Zielverzeichnis auf dem Server vor dem Upload ansonsten komplett leer?

Zitat von Foma

Wäre es möglich, dass die alte evtl. verseuchte WP Installation die neue WP installation ebenfalls versucht hat?

Das ist durchaus möglich.

Die Datei north-wp-child.zip enthält das gesuchte Child Theme Gerüst.

Das Plugin ist wieder verfügbar, die Gründe für die Sperrung kann man hier nachlesen. Offenbar ging es nur um eine Formulierung bzgl. GDPR / DSGVO in der Pluginbeschreibung.

Ob man wegen sowas ein "fast 1 Mio. aktive Installationen" Plugin wirklich sperren muss und v.a. die Nutzer über die Gründe erstmal komplett im Unklaren lässt, das wäre eine andere Frage.

Auch die Tatsache, dass bei einem anderen Plugin auf Anraten der Plugin Repository Administratorin (ipstenu) eine Ergänzung von entspr. Formulierungen sogar im Plugin Titel vorgenommen wurde, verwundert etwas, aber da darf und soll sich natürlich jeder selbst eine Meinung bilden.

Falls ihr das Plugin verwendet, kurzer Hinweis, es wurde gestern im wordpress.org Plugin Repository gesperrt.

Zitat

Dieses Plugin wurde am 29. November 2018 geschlossen und steht nicht mehr zum Download zur Verfügung.

Gründe werden leider keine angegeben, man muss also selbst Schlüsse ziehen, warum, wieso, weshalb.

In der Vergangenheit wurden Plugins mit Sicherheitsproblemen ähnlich behandelt, habe aber keinen Hinweis darauf, dass es hier auch so ist.

Ergänzung: Der wordpress.org Support wird vorerst keine Angaben zu Gründen machen und empfiehlt "if this is too uncertain" eine Deinstallation des Plugins..

Was willst Du denn erreichen? Was genau soll wann passieren?

Wird das Theme von hier verwendet? Welche exakte Theme Version?

Der Code bei [FONT=Courier New]accesspress_parallax_bxslidercb()[/FONT] wird in diesem Theme über [FONT=Courier New]add_action( .. )[/FONT] aufgerufen. Um eine eigene Version davon zu nutzen, kann man theoretisch (ungetestet) im Child-Theme sowas probieren:

function b3317133_accesspress_parallax_bxslidercb() {
?>
<h1>Neue Funktion, ersetzt komplett die alte accesspress_parallax_bxslidercb() ...</h1>
<?php
}


function b3317133_init() {
    remove_action( 'accesspress_bxslider','accesspress_parallax_bxslidercb', 10 );
    add_action( 'accesspress_bxslider','b3317133_accesspress_parallax_bxslidercb', 10 );
}
add_action( 'init', 'b3317133_init' );

Variante 1: Du hinterlegst eine eigene Version in Deinem Theme als searchform.php

Variante 2: Du ergänzt im Child Theme functions.php einen Filter wie z.B. sowas hier, ungetestet:

function b3317133_get_search_form( $form ) {
    $form = str_replace(
        ' name="s" ',
        ' name="s" maxlength="50" ',
        $form
    );
    return $form;
}
add_filter( 'get_search_form', 'b3317133_get_search_form' );

Zitat von DDKEY

Wenn mir einer sagen könnte ob mein CONTENT...also alle SEITEN, BEITRÄGE usw. die ich geschrieben haben NICHT KOMPROMITTIERT sind, wäre ich beruhigt.

Kann man ohne Einblick in die Datenbank nicht sagen.

Zitat von DDKEY

Ich werde nun folgendes Ausstauschen:

Vergiss nicht die Dateien im WordPress Hauptverzeichnis, die werden auch gern infiziert, Besonderheit hier ist wp-config.php, die sollte man nicht einfach löschen wg. der Datenbankzugangsdaten und den Security Keys, dafür manuell ganz genau anschauen, oft verstecken sich Trojaner z.B. gaaaaanz weit rechts eingerückt in der ersten Zeile, manchmal auch ähnlich in einer Zeile irgendwo in der Mitte oder auch gaaanz weit unten nach vielen Leerzeilen o.ä., im Zweifel mal mit der wp-config-sample.php vergleichen.