Beiträge von danielgoehr
-
-
Wie genau sieht denn das "in eine Homepage verwandeln" aus?
Ein Blog ist ja nichts anderes als eine Homepage. Wenn du den vorhandenen Blog ohnehin wieder integrieren willst, warum erstellt du dann nicht einfach statische Seiten und ergänzt so quasi den bestehenden Blog zu einer Homepage?
PS: Du solltest dringend deine Installation aktualisieren. 3.9.25 ist wirklich argh alt. Normalerweise solltest du WP, Plugins und ggf. auch Theme möglichst immer aktuell halten.
-
BackWPup und/oder Duplicator. Mir gefällt die Struktur der Updraft-Backups persönlich nicht so gut. Letztlich machen die aber alle (ungefähr) das gleiche.
-
Ja, kann man.
Privat (also nicht kommerziell) als iFrame, kommerziell über die Google Maps API (mit API-Key und am einfachsten z.B. mit einem entsprechendem Wordpress Plugin).
Dabei ist aber zu beachten, dass das so seit der DSGVO ohne weiteres höchstwahrscheinlich nicht mehr Datenschutzkonform ist.
-
Ich würde mich @mensmaxismus anschließen.
Wenn man alle rechtlichen und technischen Anforderungen berücksichtigt, ist Woocommerce im Grunde schon fast so etwas wie eine "Minimal-Lösung".
-
@truetext:
Man kann das so machen. Das Problem ist aber, dass du dann die Templates bei einem Update ggf. erneut anpassen musst, wenn sich in Woocommerce etwas ändert. Besser ist es, für solche Anpassungen die vorhandenen Hooks zu verwenden (sofern möglich). -
Vielleicht hilft dir das weiter:
https://www.wpbeginner.com/wp-tutorials/h…s-in-wordpress/Das behandelt eigentlich genau dein Problem. Zumindest, wenn ich es jetzt richtig verstanden habe ...
Du solltest dann aber tatsächlich vorher dringend ein Child-Theme anlegen, bevor du solche Änderungen machst:
https://www.elmastudio.de/ein-wordpress-…-gehts-richtig/Und zur Sicherheit, gerade wenn du eher unsicher bist, was solche Änderungen angeht, solltest du vorher am besten auch ein Backup der Seite erstellen (z.B. mit Duplicator oder BackWPup).
-
Deswegen hatte ich nach dem Grund gefragt. Dein Problem hat für mich ehrlich gesagt nichts mit der Fragestellung zu tun. Die Suchergebnisse bleiben dann ja genau die selben, ganz unabhängig davon, ob du den Parameter änderst, umbenennst oder wegnimmst...
Was möchtest du denn konkret erreichen? Sollen die Branchenbucheinträge nicht in der Suche erscheinen? Oder die Blogbeiträge nicht? Oder zwei separate Suchen?
-
Ich wüsste nicht, wie es viel einfacher gehen könnte.
Da mir aber auch kein wirklich plausibler Grund einfällt, das zu ändern, wird es vermutlich auch keine Plugins dafür geben (zumindest ist mir nichts bekannt).Alle o.g. Änderungen sind aber Updatesicher, solange ein Child-Theme verwendet wird. "Futsch" wäre es also nicht :)
-
Habe ich mir schon gedacht, dass ich mich nicht richtig ausgedrückt habe :)
Wenn ich im Blog etwas suche, kommen die Ergebnnisse mit der URL https://blogdomain.tld/?s=Berlin
Ich hätte es aber gern, dass https://blogdomain.tld/Berlin kommt
Also ohne das ?s=Das wird so nicht funktionieren, befürchte ich. Woher weiß denn Wordpress dann, dass es sich dabei um eine Suche oder einen Suchbegriff handelt? https://blogdomain.tld/Berlin wäre ja erstmal ein "normaler" Permalink, so dass Wordpress erstmal davon ausgehen würde, dass es sich um eine Page, Post oder eine Kategorie (o.ä.) handelt.
Warum genau möchtest du denn den Parameter weg haben?
Theoretisch könnte der von dir genannte Asatz mit dem Code-Schnipsel schon so funktionieren. Aber du müsstest Wordpress dann zusätzlich "beibringen", dass /suche/[Suchbegriff] die Suchseite ist und er [Suchbegriff] als Parameter für die Suche nutzen soll.
Alternativ könnte man die Suche vielleicht auch einfach von GET auf POST umbauen, indem man das Suchformular auf POST ändert und dann auf der Suchseite dafür sorgt, dass er statt der GET-Variable die entsprechende POST-Variable nimmt. Welcher Hook dafür am ehesten geeignet ist, müsste ich jetzt aber auch testen. Ich würde es jetzt zunächst wahrscheinlich mit wp_head oder request oder vielleicht pre_get_posts probieren.
-
Schau Mal hier:
https://www.stewright.me/2016/03/disabl…rd-subscribers/Da werden die verschiedenen Varianten (jeweils mit passendem Code-Schnipsel) erklärt.
-
Keiner eine Idee?
Ehrlich gesagt... Ich habe es zwar gelesen, aber nicht verstanden, was du machen möchtest.
-
Da Avada ein Premium Theme ist und der Fehler in einer der Avada-Dateien entsteht, ist die Frage bei deren Support wahrscheinlich am besten aufgehoben...
-
Ausser "silence is golden" index.php sind da in der Regel keine, eine Prüfung sollte also sehr schnell gehen, daher die Frage.
/wp-content/uploads/mc4wp-debug-log.php (gehört zu MailChimp for WordPress)
/wp-content/index.php
/wp-content/uploads/backwpup-XXXXXX/index.php
/wp-content/wflogs/rules.php (gehört zu Wordfence)
/wp-content/wflogs/ips.php (gehört zu Wordfence)
/wp-content/wflogs/config.php (gehört zu Wordfence)
@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.ä.?Ah, die Info hatte ich überlesen. Den Cron hatte ich aber tatsächlich noch nicht überprüft. Das habe ich aber gerade nachgeholt und kann nichts verdächtiges entdecken.
-
Welche .php Dateien ausser Themes und Plugins gibt es in wp-content/ denn noch?
Möchtest du die konkrete Liste? Dann müsste ich morgen nachschauen. Das weiß ich nicht aus dem Kopf.
Aber es gibt ja z.B. die index.php Dateien ("silence is golden"). -
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)?
Jein. So einfach ist es ja (leider) nicht.
Für wp-includes und wp-admin und das Root-Verzeichnis (bis auf wp-content.php): Ja.
Für das Theme und Plugins: Ja.Das Child-Theme und eigene Plugins habe ich mit verschiedenen "alten" Backups abgeglichen (von denen ich zumindest weitgehend sicher bin, dass sie sauber waren). Hier besteht natürlich aktuell noch ein Restrisiko.
Das gleiche gilt für das (leider sehr umfangreiche) wp-content Verzeichnis. Hier habe ich auch diffs mit meinen Backups erstellt und zumindest alle PHP Dateien soweit geprüft. 100% ausschließen, dass es unter den neueren Dateien noch z.B. manipulierte Bilddateien gibt, kann ich aktuell nicht.
Im Moment überwache ich Datei-Änderungen und schreibe mir dazu Logs mit timestamps um sie dann ggf. mit den Access Logs abzugleichen. So habe ich die bisherigen Zusammenhänge der o.g. Dateien herstellen/reproduzieren können. Da aber, wie gesagt, aktuell keine Veränderungen mehr stattfinden, sammel ich so gesehen auch keine brauchbaren Informationen mehr.
Ich muss aber auch ehrlich sagen, ich habe schon einiges an Hacks gesehen und bereinigt. Sowas habe ich bislang noch nicht gesehen. Sonst kommen solche Hacks ja eher etwas plump daher. Hier hat sich jemand auf jeden Fall mal ein paar Gedanken gemacht. Vielleicht hätte ich bislang aber auch einfach nur Glück ;)
-
@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.
Das war nur als Hinweis gemeint, diese Dateien hängen (zumindest bei meinem Hack) alle ziemlich eindeutig und nachvollziehbar zusammen. Es ist auch nicht als Lösung gemeint, sondern eher als schnelle, erste Abhilfe. Natürlich muss die Ursache gefunden werden. Aber das ist halt manchmal nicht so einfach. Ich schreibe gerade Logs und überwache Veränderungen in verschiedenen Verzeichnissen und konnte so bislang den Zusammenhang dieser Dateien feststellen. Es kann beim TE natürlich anders sein. Aber es ist trotzdem nicht verkehrt, diese Dateien Mal gezielt unter die Lupe zu nehmen.Genullte Themes und Plugins kann ich sicher ausschließen. Wordpress, Plugins und Theme sind aktuell und werden seit Jahren regelmäßig aktualisiert.
Zu 1. & 2. Es müssen immer ausnahmslos ALLE WordPress-Dateien, Theme- & Plugin-Dateien (auch nicht aktive) ersetzt bzw. abgeglichen werden, siehe Link oben.
Das sollte ja relativ klar sein, bzw. wurde ja auch schon erwähnt. Deswegen meinte ich ja, meine Informationen sind eher als Zusatz zum bereits empfohlenen/gesamten zu sehen.
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.
Ok, das ist richtig. Insofern korrigiere ich mich und würde auch eher empfehlen, sie nicht blind zu löschen, sondern einen Diff zu erstellen. wp-advanced-cache.php gehört meines Wissens nach zu WP Super Cache. Ist das nicht installiert, sollte das löschen ungefährlich sein. Ist es installiert, ist das ersetzen durch die Original-Datei natürlich der bessere Weg.
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.
Es ist ein Einzelfallbericht, der exakt die gleichen Symptome zeigt, die der TE beschreibt (gleiche Manipulation der wp-load.php, tnd.png im wp-includes/Images Verzeichnis). Die "Installation" dieser beiden Dateien und auch der Datei ms-advanced-cache.php in wp-includes erfolgt über die manipulierte wp-advanced-cache.php durch einen Aufruf mit dem angehängten Parameter "root" (nachvollziehbar und reproduzierbar). Die index.php im Theme-Verzeichnis scheint die Quelle der wp-advanced-cache.php in wp-content zu sein. Die Dateien hängen also schon relativ eindeutig zusammen und es nicht nicht unwahrscheinlich, dass es beim TE genauso ist. Es sind nicht einfach zufällig unterschiedliche, manipulierte Dateien.
Ich hätte mich zumindest gefreut, wenn sich diese Zusammhänge damals hätten ergoogeln lassen. Hätte mir viel Zeit gespart.
Ich bin mir weitestgehend sicher, dass es keine weiteren manipulierten Dateien mehr gibt. Die Dateien wurden alle erstezt und werden fortlaufend mit den Originaldateien abgeglichen.Nur die Quelle der manipulierten index.php im Theme Verzeichnis is ist mir bislang ein Rätsel. Da aktuell aber nichts mehr passiert, komme ich hier zumindest aktuell nicht weiter bei der Analyse.
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.Es gibt, zumindest in meinem Fall, keine inaktiven Themes oder Plugins.
Wie gesagt. Ich meinte das auch nicht als Lösung des Problems, sondern eher als schnelle erste Hilfe zur Bereinigung und als Anhaltspunkte für den TE. Das habe ich vorhin vielleicht etwas zu knapp/missverständlich formuliert. Wenn es beim TE am Ende ganz anders ist, hilft das natürlich nicht weiter. Ich vermute aber weiterhin, dass es quasi der gleiche oder zumindest ein sehr ähnlicher Hack ist.
-
Da ich vor kurzem (bzw. eigentlich immer noch) mit ziemlich exakt dem gleichen Hack zu tun hatte/habe:
1.) Ersetz das gesamte wp-includes Verzeichnis gegen die Orginal-Dateien.
2.) Ersetz die wp-load.php im Wordpress-Root gegen die original-Datei.
3.) Lösche (zusätzlich) folgende Dateien:
wp-content/wp-advanced-cache.php
wp-content/themes/index.php
4.) Prüf das webroot auf eine Datei "0.php". Wenn vorhanden -> löschen.
5.) Verhinder per htaccess den Zugriff auf die unter 3 und 4 genannten Dateien.Ansonsten alle "üblichen" Maßnahmen durchführen, die die anderen auch schon empfohlen haben. Leider weiß ich bis heute die Ursache nicht und beobachte noch. Aber bislang scheint es, zumindest vorübergehend, zu wirken.
-
In der robot txt sollte zumindest das hier stehen:User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpNur aus Interesse... Warum? Bzw. was hat das mit der Frage bzw. mit dem Problem des TE zu tun.
-
Wir sind nicht Europa
Ohne jetzt im Detail geprüft zu haben, ob eure Seite GDPR-Konform ist: Es ist vollkommen unerheblich, wo euer Firmensitz oder eure Seite gehostet ist. Solange sich euer Angebot oder eure Informationen (auch) an EU-Bürger richten, seid ihr zur Einhaltung verpflichtet.
Vielleicht trifft das auf euch nicht zu, ich wollte es trotzdem erwähnt haben...