Beiträge von Baldini

Zitat von medienkobold

• Projekte vorstellen: Hier sollten auch ausschließlich Projekte vorgestellt werden dürfen die auf WordPress basieren. Sonst läuft man Gefahr, das man hier (Werbe)-Beiträge aus allen möglichen Bereichen bekommt, die entweder mit WordPress rein gar nichts zu tun haben oder der User keinerlei Mehrwert bietet und keinerlei Interesse daran hat sich hier auch nur halbwegs am anderen Forengeschehen zu beteiligen. Frei nach dem Motto: "Ich hau da mal meinen Link rein, ansonsten interessiert mich das Forum eher gar nicht".

Naja, der überwiegende Grossteil dieser Rubrik hällt das Forum mit Inhalt am Leben. Auch wenn deine Haltung von der Ansicht durchaus richtig ist, würdest du einen Teil der Lebensader absticken.

Zitat von Loisel Unterwegs

Die erwarten doch nicht wirklich, das ich dass Piktogramm in die Bestätigungsmail einbinde.

Das Piktogramm muss gut sichtbar eingebunden werden. Die Richtlinie sieht vor, dass der Hinweis beim Produkt platziert wird. Die Info muss als Pflichtbestandteil auch in die automatische eMail nach Kaufabschluss integriert werden.

Dass bei dir alle paar Wochen neue Admins auftauchen und du ausgesperrt wirst, liegt schlicht daran, dass du die Ursache nicht beseitigst. Du spielst per Updraft das Backup ein, aber der Schadcode war zum Zeitpunkt der Sicherung wahrscheinlich längst auf dem Server. Du spielst dir die Hintertür also immer wieder selbst ein. Dazu kommt, dass ein paar Tage Wartezeit bei Plugin Updates den Bots völlig ausreichen, da bekannte Lücken binnen Stunden automatisiert abgeklopft werden.

Um die Kiste jetzt nachhaltig sauber zu bekommen, musst du als Erstes per FTP in den Ordner /wp-content/uploads/ schauen und dort rigoros jede php Datei löschen, denn dort gehören absolut keine Skripte rein. Danach solltest du nicht einfach nur Dateien überschreiben, sondern die Ordner wp-admin, wp-includes sowie deine Plugins komplett löschen und jungfräulich von WordPress neu hochladen. Hol dir anschließend neue Sicherheitsschlüssel für deine Config, um alle möglicherweise gekaperten Session Cookies zu killen. Solltest du Plugins von einem kleineren Entwickler verwenden, wo der Code vor php8 existiert hat bzw. wo 1 - 4x im Jahr Updates angeboten werden, geh den gesamten Code vor der Installation durch. Die sind inhaltlich häufig nicht auf maximale Sicherheit getrimmt.

Zitat von R560073

Hallo zusammen,

ich habe einen Fehler, wenn ich im Widget etwas ändern will.
Die Antwort ist keine gültige JSON-Antwort.
Im Forum ist darüber viel geschrieben worden, habe alles, soweit es mit möglich war, probiert, doch der Fehler bleibt bestehen.
Mein Anbieter IONOS kann oder will mir nicht helfen, er sagt, dass ist Anwendersache.
Jetzt bin ich mit meinem Latein am Ende.
Kann mir jemand helfen?
Vielen im Voraus.
Jürgen

Alles anzeigen

zB. Firefox --> F12 --> Netzwerkanalyse und inspektor und die Seite Neuladen. Dein Fehler Pfad sollte eingeblendet werden. Sollte nichts kommen, sind im Code wahrscheinlich Fehlerunterdrückende Passagen am Anfang eingebaut, unwahrscheinlich - aber klammere Sie dann aus. Fix das und mache den Ablauf nochmals. Hört sich nach schnellem Kleinkram an.

Der geschätzt über 10 Jahre alte Code funktioniert grundsätzlich, aber er ist an mehreren Stellen unnötig kompliziert und teilweise redundant. Die größere Schwachstelle ist aus meiner Sicht gar nicht die teilweise veraltete Agent Liste, sondern die Methode. User Agent Filter lassen sich trivial fälschen. Jeder Bot kann sich als was anderes ausgeben und die Sperre umgehen. Wenn das Ziel ist, Feeds gegen KI-Crawler oder Scraper zu schützen, ist das eher eine Komfortlösung als eine belastbare Sicherheitsmaßnahme. Die Upload Sperre macht mit der Methode noch am ehesten Sinn - allerdings nur erweitert.

Zitat von SilentAero

Die man dann nach jedem WordPress- und Theme-Update neu editieren muss?
Nein, sicher nicht.
Aber was Ihr macht, ist eure Sache.

Wenn du wie vorgeschlagen die Standardpfade per .htaccess auf neutrale Namen umleitest oder Versionsnummern und Meta-Tags über die functions.php entfernst, bleibt das zu 99 % auch nach einem Theme oder WordPress Update erhalten. Du bearbeitest schließlich keine wechselnden Inhalte, sondern greifst auf feste Platzhalter im Grundgerüst zu.

Werkzeuge wie WPThemeDetector, RSS-Aggregatoren oder Sicherheits-Scanner nutzen bevorzugt Google Cloud-Server. Das ist oftmals für das Thema Preisgünstiger. Sie steuern gezielt WordPress Pfade wie zB. /feed/ oder /comments/feed/ an, um im XML-Quellcode nach Versionsnummern, Themes und Plugins zu suchen. Dass weder User Agent noch Referer mitgesendet werden, zeigt, dass hier ein recht simples Skript ohne Browser-Emulation am Werk ist.

Komplette Google Cloud IP Bereiche per .htaccess zu blockieren, schießt über das Ziel weit hinaus und trifft schnell die falschen Dienste. Sauberer wäre es, Anfragen ohne User Agent gezielt abzulehnen oder ungenutzte WordPress Feeds direkt serverseitig abzuschalten.

Zitat

Nun ist mir aufgefallen, dass bei einer gewerblichen Seite eines Anbieters, der auch YouTube-Videos zu technischen Themen anbietet,
keine Plug-ins aufgelistet werden. Ich kann mir nicht vorstellen, dass auf einer Seite von Programmierern 0 (Null) Plug-ins installiert sein sollen.

Du könntest die normalen Pfade via .htaccess auf neutale Namen umleiten oder die Versionsnummern und Meta Tags via der functions.php strippen. Alternativ baust du dir ein Plugin selbst. So kommst du für extern zu Null Plugins.

Zitat

Ich werde die nächsten Tage mal versuchen herauszufinden, ob ich die einzelnen Pfade wie z. B.: "wp-content/plugins/" per .htaccess von
außen sperren kann.

Sperrst du den Ordner /wp-content/plugins/ per .htaccess komplett für externe Aufrufe, kann der jeweilige User Browser vorhandene css und JS Dateien nicht mehr laden. Deine Website sieht optisch, sagen wir mal kaputt aus und viele Skripte funktionieren nicht mehr. Der Browser ist in diesem Fall außen. Sinn?

Kommt auf den Inhalt und den Aufwand an, den du dafür betreiben möchtest.

Das ist automatisierter Bot Spam. Die interessieren sich leider nicht für NBs.

Dein Problem bei der Varable file_get_contents ist, dass nur html Code eingelesen wird. Eine Karte benötigt aber js + css, die bei dieser Variante fehlen. Da deine entwicklung.php ein html Dokument + head und body liefert, bindest du eine Datei in eine andere ein. Browser können diese Struktur nicht sauber verarbeiten und Pfade deiner Skripte laufen ins Leere, sobald sie in Kombination der Wp url aufgerufen werden. Darum lädt deine Karte nicht.

Das ist kein reiner Browser Fehler, sondern die Folge widersprüchlicher Anweisungen. In seiner CSS stehen sich eine starre und eine flexible Größenangabe ohne cover gegenüber, FF ist einfach nur so "brav" und führt beide gleichzeitig aus. Wie gesagt: Das lässt sich in paar Minuten selbst beheben. Der aktuell gemeldete FF Bug sorgt eben genau dafür, dass Bilder auf die gesamte verfügbare Fläche gestreckt werden, wenn flexibler Code auf veraltete Breiten und Höhenattribute trifft.

Es ist ungewöhnlich, wochenlang auf den Support eines Tools warten zu wollen, wenn sich das Problem in max fünf Minuten über den Editor selbst lösen lässt, aber das muss natürlich jeder selbst entscheiden. Ändere die Passage, die er dir rausgesucht hat wie folgt. Sollte in der Theorie Lücken im Chrome + Stauchung im Firefox beheben.

.wp-block-gallery.has-nested-images figure.wp-block-image img {
  display: block;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Firefox hält sich an deine festen Höhenangaben in deinem Code und erzwingt diese, egal wie breit das Bild gerade im Container gezogen wird. Edge und Chrome hingegen ignorieren die feste Höhe, um Verzerrungen zu vermeiden. Warum? Ist halt so. Da die Bilder aber unterschiedliche Originalformate haben, wirkt das Layout dort völlig uneinheitlich und gewürfelt. Ohne ein zB. klares "high: auto;" in deiner css wissen die Browser schlichtweg nicht, wie sie die Proportionen bei variabler Breite, das ist ein responsive Design, einheitlich behandeln sollen.

Deine Bilder haben feste Maße für Höhe und Breite, während das Responsive Design gleichzeitig 100% Breite erzwingt, um sich dem Bildschirm anzupassen. Dadurch werden die Bilder je nach Fenstergröße entweder gestreckt oder gestaucht, weil die Proportionen nicht mitwandern. Da im css Code zB. kein heigh: auto; hinterlegt ist (ich habe es beim überliegen nicht gelesen), fehlt der Schutz gegen diese Verzerrung.