Es ging hier aber nie um PHP-Updates, sondern um Wordpress- und Plugin Updates.
Egal, die Diskussion ist eh OT, ich wollte nur eine zweite Meinung zu deiner Aussage anbieten.
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenEs ging hier aber nie um PHP-Updates, sondern um Wordpress- und Plugin Updates.
Egal, die Diskussion ist eh OT, ich wollte nur eine zweite Meinung zu deiner Aussage anbieten.
Aber genau darum geht es doch in der Regel bei den Updates, diese besagten Lücken zu schließen.
ie sogenannten Sicherheitslücken kommen nur im Labor vor.
Das ist aber eine extrem steile These. Woher kommen dann die vielen gehackten Webseiten? Ich glaube es gibt wirklich tausende Quellen, die das Gegenteil belegen.
Nö. Wenn die IPs unmittelbar anonymisiert und nicht über den technisch notwendigen Nutzen hinaus genutzt werden
Aber wie stellst du als Betreiber der Seite (und Nutzer eines Dienstes) dies sicher? Man könnte sich sicher darauf berufen, wenn ein Anbieter dies behauptet (und schriftlich garantiert), aber meiner Erfahrung nach haben selbst die meisten Anbieter nicht verstanden, was die Umsetzung der DSGVO bedeutet und behaupten pauschal, sie wären konform (obwohl sie es in vielen Fällen ganz eindeutig nicht sind).
Aber bei der ganzen Thematik sind sich nicht einmal Anwälte und Richter einig.
Das ist aber genau genommen nur die halbe Wahrheit. Es stimmt zwar, dass nicht für alle Dinge eindeutig geklärt sind, was nun im Endeffekt erlaubt ist und was nicht. (Ziemlich) sicher ist aber, wenn man sich an das hält, was @b3317133 sagt, nämlich schlicht keine Daten an niemanden zu übermitteln, sofern es nicht absolut zwingend notwendig ist (Hosting z.B.), kann man schon davon ausgehen, die Anforderungen der DSGVO zu erfüllen.
Eigentlich sollte dein Code wirklich einen zuälligen Key zurückgeben, das heißt, alle Einträge berücksichtigen. Nur die 2 als zweiter Parameter in array_rand() ist in deinem Fall eigentlich überflüssig, weil du ja nur einen Key für dein Vorhaben brauchst und den zweiten ohnehin "ignorierst".
Folgendes sollte reichen:
Alternativ ging zum Beispiel auch folgendes (sollte zwar keine grundsätzlich anderen Ergebnisse bringen, wäre aber ein anderer Ansatz):
Oder auch
Ich meinte tatsächlich eher selbst schreiben (und dann entweder in die functions.php oder als eigenes Plugin einfügen). Das sollte eigentlich mit ein paar Zeilen erledigt sein.
In WordPress lassen sich Shortcodes relativ einfach selbst erstellen.
https://developer.wordpress.org/reference/functions/add_shortcode/
Verwendest du ein Child-Theme?
Warum soll es denn Javascript sein? Das wäre zwar auch möglich, aber in dem Fall scheint mir ein Shortcode in PHP (zumindest auf den ersten Blick) die bessere Lösung.
Nein das stimmt. Allerdings war ich davon ausgegangen, dass deine Frage mit den Antworten in #2 und #3 bereits beantwortet ist. Das mit Polylang war eher ein Nachtrag zu #3 von @threadi
OK, ich hatte mich gerade auch schon etwas gewundert.
Ich kann allerdings die kostenfreie Version von Polylang empfehlen. Verwenden wir viel und reicht für die allermeisten Fällen völlig aus...
Mit WPML kann man auch in der kostenfreien Version jeden Inhalt übersetzen und auch die einzelnen Sprachen mit eigenen Domains erreichbar machen.
Es gibt eine kostenfreie Version von WPML?
Hast du mal den Link parat?
Ich habe mir damit damals meinen Blog wunderbar abgeschossen. Oder gibt es das Problem mit dem Thema Serialisierte Daten (Serialized Data) in WoordPress nicht mehr?
Meine Antwort bezog sich auf das von @vriic genannte Plugin "Better Search Replace", das die serialisierten Daten berücksichtigt bzw. damit problemlos umgehen kann.
Ich wüsste zwar nicht was man heutzutage noch per http:// laden sollte
Es geht ja nicht nur um das Laden von externen Daten (obwohl auch hier natürlich nach wie vor http:// vorkommen kann). Es geht aber vor allem auch um Verlinkungen auf externe Seiten, die man damit unter Umständen auch unbrauchbar macht.
Hey, ich melde mich später per Konversation mit weiteren Informationen bei dir :)
Das macht ja einen sehr seriösen Eindruck o_O
Abgesehen davon ist Akquise hier im Forum nicht gern gesehen...
Nach http:// suchen und mit https:// ersetzen
Davon würde ich dringend abraten! Immer nach der vollständigen Domain suchen und ersetzen. Also http://www.example.com gegen https://www.example.com ersetzen.
Letztlich wird dir keiner ohne eingehende Analyse sagen können, wie und wodurch deine Installation gehackt wurde. Und ich befürchte, so eine Analyse lässt sich in einem Forum nicht durchführen.
Solange Wordfence manipulierte Dateien anzeigt, musst du jede dieser Dateien als Einfallstor behandeln. Es ist nicht eine Datei irgendwo, die deine Datenbank verändert.
Wordfance lasse ich auch gerade laufen, bringt aber leider nicht den gewünschten Erfolg weil es unzählige Dateien als High auflistet von denen man nur ahnen kann das sie vom Template sind.
Das ist aber eher ein schlechtes Zeichen. Normalerweise ist das nicht so. Das klingt tatsächlich so, als wäre deine Seite gehackt worden.
Poste Mal einen Screenshot dieser "High" Ergebnisse.
Das ist wohl eher etwas für die Jobbörse:
https://forum.wpde.org/forums/jobboerse.33/
Es erweitert Wordpress erstmal "nur" um Shopfunktionen, optisch ist da also noch nichts. Damit ist noch keine Website gebacken.
Tatsächlich bringt es auch die nötigen Templates und Stylesheets mit. Ob das dann optisch besonders ansprechend ist, ist eine andere Frage.
Woocommerce ist doch kostenlos. Ich glaube, am aufschlussreichsten ist es, wenn du einfach mal einen neue WordPress Installation erstellst und da dann Woocommerce installierst und ein bisschen damit "rumspielst".
Das Problem ist, wie @b3317133 schon sagt, selbst wenn du jetzt in Zukunft Auffälligkeiten in den Logs finden solltest (wovon ich ausgehe), ist es nicht gesagt, dass dies der "ursprüngliche" Hack ist. Oft werden vorhandene Hacks als Einfallstor genutzt um weitere Malware "nachzuladen".
Wenn du in der Vergangenheit keine Access Logs hattest (was ich eher ungewöhnlich finde, was sagt denn dein Hoster?), wirst du hier nicht viel erreichen können.
Das Auswerten der Logs ist zugegebenermaßen auch nichts, was man mal eben machen kann, ohne zu wissen, wie sowas tatsächlich aussieht und was legitime Zugriffe, unlegitime (aber unproblematische) Zugriffe und was wirklich problematische Zugriffe sind.
Soll heißen, dafür braucht man leider schon ein bisschen Erfahrung.
Insofern würde ich bei meiner Empfehlung bleiben: Updates machen und engmaschig beobachten. Wenn es dann wieder passieren sollte hast du zumindest die Logs aktiviert und bist vielleicht ein bisschen schlauer.
Wurde die Website denn regelmäßig aktualisiert? Erhalten alle Plugins und Themes, die du einsetzt noch Updates?
In den allermeisten Fällen liegt es an nicht aktualisierter Software, wenn eine Seite gehackt wird. Da du (aller Wahrscheinlichkeit nach) einen Webspace bei All-Inkl hast, bei dem der Webserver von All-Inkl gewartet wird, könntest du auch versuchen, die Seite wiederherzustellen, zu aktualisieren und dann regelmäßig Updates einzuspielen. Eventuell ist das Problem damit auch schon gelöst.
Du solltest dann aber ein genaues Auge auf deine Seite haben und prüfen, ob der Hack erneut passiert (bei sowas ist zum Beispiel auch die Prüfung der Datei-Integrität mittels Plugin, z.B. Wordfence ganz nützlich).
Auch solltest du deine Passwörter (vor allen die der User und der Datenbank) ändern.
Es gibt natürlich auch noch weitere Einfallstore (z.B. könnte auch der PC gehackt sein, auf dem du die Passwörter gespeichert hast bzw. mit dem du die eingibst, es könnte bisher unbekannte Lücken in Plugins geben, und vieles mehr). Aber wenn du das Problem selbst lösen willst (oder musst), wäre der o.g. Weg zumindest einen Versuch wert.