Beiträge von b3317133

Würde man wohl via CSS Shapes lösen, hier ein Ansatzpunkt.

Für bezahlte Hilfe setze am besten eine entspr. Anfrage mit Kontaktmöglichkeit in die Jobbörse.

Auf Basis des ersten Beispiels der Shortcode-Dokumentation würde das in etwa so aussehen:

function foobar_shortcodes_init() {
   // Kapselung in einer init action wg. Nutzung in einem Plugin


   function foobar_func( $atts ) {
       $result = "foo and bar";
       if ( isset($_GET['aktion'] || isset($_POST['aktion'] ) {


           // dein weiterer code usw.
           $result = "deine ausgaben";


       }
       return $result;
   }
   add_shortcode( 'foobar', 'foobar_func' );


}
add_action( 'init', 'foobar_shortcodes_init' );

Und auf der entspr. Seite im Editor steht dann [FONT=Courier New][foobar][/FONT], sonst nichts.

Wichtig: Innerhalb des Shortcodes darf kein direktes "echo" erfolgen, alle Ausgaben werden am Ende per [FONT=Courier New]return[/FONT] zurückgegeben.

Bei Nutzung von Shortcodes in einem Plugin sollte die Initialisierung innerhalb einer [FONT=Courier New]init[/FONT] Action erfolgen, habe das im Code ergänzt.

Ergänzend, WordPress stellt viele Datenbankfunktionen in der $wpdb Klasse bereit, die kann man auch für eigene Verbindungen zu anderen Datenbanken verwenden, siehe Suchmaschinen...

Würde erstmal versuchen, das mit dem bestehenden User Registration Plugin zu machen. Leider ist es nicht genannt, daher musst Du selbst nachlesen.

Evtl. sowas in der Art? (google.com)

Setze am besten eine entspr. Anfrage mit Kontaktmöglichkeit in die Jobbörse.

Dabei wäre es hilfreich, wenn z.B. Wordfence noch nicht installiert wurde, da es ggf. Dateien löscht, der aktuelle Stand sollte so weit es geht erhalten bleiben, damit man die Einbruchwege usw. so weit wie möglich nachvollziehen kann.

Das ist kein bekannter Fehler. Es deutet vielmehr darauf hin, dass euer Datenbank-Server sporadisch aussetzt.

Der Einsatz von Wordfence ersetzt nicht die beschriebene nötige Vorgehensweise. Wordfence verhindert einige übliche Einbruchversuche, aber bei Dir ist der Einbrecher bereits im Haus.

1. Offenbar ist beim Einspielen des Backups entweder der Virus erhalten geblieben oder die Lücke, über die er sich eingeschlichen hat, besteht nach wie vor.

2. So wie beim ersten Mal.

3. Sicherstellen, dass der Virus nach dem Einspielen des Backups nicht mehr vorhanden ist und - das ist der wichtigste Punkt - dass die Lücke, über die er sich einschleichen kann, geschlossen ist. Die Lücke kann z.B. aus zu einfachen Kennwörtern, Fehlern in Theme oder Plugins, oder auch Hintertüren in Theme oder Plugins, oder in hinterlassenen Trojaner-Dateien irgendwo in den Tiefen der Ordnerstruktur bestehen.

Eine generelle Kurzanleitung für jemanden mit grundlegender technischer Ahnung befindet sich hier.

Wenn Du etwas Ahnung hast, kannst Du das Problem selbst lösen. Professionelle Hilfe gäbe es z.B. über die Jobbörse des Forums, das geht öffentlich nicht/schwer, da FTP-Zugang usw. nötig sein wird.

jQuery wird bei WordPress mitgeliefert, es ist eine sog. Bibliothek aus Funktionen.

Derzeit wird vom Plugin "Thickbox" eine zusätzliche, alte jQuery Bibliothek geladen. Das ergibt mMn. Konflikte. Das Plugin "Thickbox" ist über 4 Jahre alt, nicht mit der aktuellen WordPress Version getestet und offenbar auch nicht kompatibel.

Die "DAU" Lösung wäre die gleiche wie eine normale Lösung:

1. Mindestens das Thickbox-Plugin aber besser erstmal alle Plugins deaktivieren. Dann sollen die aktuellen Scriptfehler nicht mehr auftreten.
2. Dann die Plugins einzeln aktivieren, um zu sehen, ob es a) Fehler gibt und b) die gewünschte Funktion damit erzielt wird.
3. Keine uralten Plugins verwenden.

Scriptfehler sieht man in der Browser-Konsole, wie man diese öffnet, steht im o.g. Link.

Lt. Browser-Konsole gibt es bei der Seite derzeit diverse Scriptfehler bzgl. jQuery, vermutlich wegen doppelter Einbindung der Bibliothek o.ä., die sollte man erstmal beheben. Im aktuellen Zustand wird wohl kein einziges Galerie-Plugin funktionieren (können).

Stellt Deine Seite auch andere Metadaten zur Verfügung, z.B. Opengraph o.ä.? Link zur Seite?

Ausser "silence is golden" index.php sind da in der Regel keine, eine Prüfung sollte also sehr schnell gehen, daher die Frage.

Bei Themes und Plugins sollte man übrigens am Rande bemerkt nicht alleine dem WordPress Backend trauen, durch die netten "all_themes" und "all_plugins" Filter sieht man da nicht immer zwingend alles, was tatsächlich vorhanden und ggf. auch aktiv ist.

@danielgoehr Fitzkogerd beschreibt übrigens "In der Folge kommt es dann zu neuen Dateien in wp_admin" (konträr zu Deinem Punkt 1. oben) und hat offenbar einen Trigger via wp-cron erkannt, das scheint dann ggf. eine andere Variante zu sein als bei Dir. Mal die Cron-Aufrufe geprüft, mit "WP Crontrol" o.ä.?

Welche .php Dateien ausser Themes und Plugins gibt es in wp-content/ denn noch?

Das heisst, in Deinem Fall ergibt ein Diff aller Dateien des gesamten Websites und einem Satz sauberer frisch entpackter zips der gleichen Versionen des WP Core und allen Plugins und allen Themes eine 100% Übereinstimmung (ausgenommen wp-config.php)?

Teste es doch einfach: Via phpMyAdmin Export aller Tabellen aus der alten Datenbank, Import in die neue, leere Datenbank, kurze Sichtprüfung in ein paar Tabellen ob der Import geklappt hat, Umschalten DB-Zugangsdaten via wp-config.php, Sichtprüfung des Websites, falls "zerschossen", Zurückschalten via wp-config.php, alles wieder wie vorher.

Ansonsten spezifiziere bitte mal genauer, was "auf einer MySQL 5.5-Datenbank, diese macht einige Probleme" heisst. Je nach "Probleme" ist ggf. nicht die Datenbankversion die Ursache / Lösung.

Wenn man z.B. nach dem Text [COLOR=#ff0000]a[/COLOR] für [COLOR=#00b300]Dezember 2017[/COLOR] sucht, ergibt das eine URL wie diese:

[plain]http://example.com/[/plain]wp-admin/upload.php?mode=list&attachment-filter&[COLOR=#00b300]m=201712[/COLOR]&filter_action=Auswahl+einschr%C3%A4nken&[COLOR=#ff0000]s=a[/COLOR]&action=-1&paged=1&action2=-1&affected&_ajax_nonce=XXXXXXXXX&ps

Passt man die URL an, indem man den Monat weglässt, also m=2017 statt m=201712, wird nach meiner Beobachtung im ganzen Jahr gesucht.

[plain]http://example.com/[/plain]wp-admin/upload.php?mode=list&attachment-filter&[COLOR=#00b300]m=2017[/COLOR]&filter_action=Auswahl+einschr%C3%A4nken&[COLOR=#ff0000]s=a[/COLOR]&action=-1&paged=1&action2=-1&affected&_ajax_nonce=XXXXXXXXX&ps

Ob / inwieweit dann noch die Pagination funktioniert, habe ich nicht getestet, ggf. unter "Ansicht anpassen" oben die Einträge pro Seite vorher entspr. hochsetzen.

Frage doch mal bei den Jetpack Autoren nach, die haben ihre ganz eigene Meinung zu GDPR (= englische Bezeichnung der DSGVO), hier am Beispiel Cookie-Checkbox:

Zitat

If you ... disagree with that decision, I would recommend that you deactivate Jetpack's Comment form option under Jetpack > Settings > Discussion in your dashboard. Your site will then display the default comment form again, that includes a checkbox.

Edit: genauere Bezeichnung Cookie-Checkbox

Zitat von Fitzkogerd

2. dann wp_includes und wp_admin löschen bzw. neu hochladen? Was bringt das, wenn im root the wp_load.php Datei geändert wird?

Bitte genau lesen, dort steht:

Zitat

Alle Systemdateien von WordPress ersetzen, dafür wp-admin/ und wp-includes/ komplett löschen.

Die Systemdatei [FONT=Courier New]wp-load.php[/FONT] (die meinst Du wahrscheinlich, ein [FONT=Courier New]wp_load.php[/FONT] gibt es in WordPress nicht) gehört natürlich dazu. Die beiden Unterordner löscht man vorher, weil beim einfachen Überschreiben der Ordner die vom Trojaner / Hack zusätzlich irgendwo eingefügte Dateien sonst erhalten bleiben.

Wenn man Jetpack einsetzt, braucht man sich um DSGVO eher keine Gedanken mehr zu machen, das Plugin verstösst praktisch mit jeder zweiten Funktion dagegen.

@danielgoehr Es ist in den seltensten Fällen nur ein Hack, erfahrungsgemäss sind es allermeist unterschiedlichste Kombinationen aus diversen Hacks und Trojanern, die über erratene Kennwörter oder auch über z.B. "genullte" Themes und Plugins o.ä. an Bord kommen.

Zu 1. & 2. Es müssen immer ausnahmslos ALLE WordPress-Dateien, Theme- & Plugin-Dateien (auch nicht aktive) ersetzt bzw. abgeglichen werden, siehe Link oben.

Zu 3. Die beiden genannten Dateien sind legitim und müssen nicht verseucht sein, das Löschen einer legitimen [FONT=Courier New]wp-advanced-cache.php[/FONT] kann unter Umständen das Frontend eines Websites lahmlegen.

Deine Liste ist ein Erfahrungsbericht eines Einzelfalls, und falls die unter 3. genannten Dateien wirklich verseucht waren, würde ich darauf wetten, dass es noch eine ganze Reihe andere Dateien gegeben hat oder auch noch gibt.

Ein Klassiker hier ist die erste Zeile der [FONT=Courier New]wp-config.php[/FONT] oder ein paar offiziell klingende [FONT=Courier New].php[/FONT] Dateien in einem Unterordner in einem inaktiven Twenty XXX Theme.