Beiträge von Baldini

    Also beispielsweise Kontaktformulare, die plötzlich keine E-Mails mehr versenden, fehlerhafte Buttons, defekte Links oder technische Probleme, die nach einem Update auftreten können.

    Mich würde deshalb interessieren:

    • Welche Tools nutzt ihr aktuell für solche Überprüfungen?
    • Habt ihr Lösungen gefunden, die auch Kontaktformulare zuverlässig testen?

    Auf uptimeshield.de der Monitor Mehrschritts Ablauf kann Formulare durchlaufen. Allerdings ist das je nach Captcha Schwierigkeits Grad + Honeypot Feldern am Ende so eine Sache. Der Monitor Inhalts Änderung kann beliebige Seiten überwachen, ganz oder nach bestimmten Feinheiten. Den verwende ich selber.

    Ich glaube, man muss bei deiner Frage etwas tiefer ansetzen. Nicht jeder, der WordPress nutzt, möchte automatisch Teil einer Community sein. WordPress ist ein Werkzeug und kein Gesellschaftsvertrag.

    Vielleicht liegt es nicht an den Uhrzeiten oder den Themen, sondern schlicht daran, dass der Mehrwert für manche nicht groß genug ist, um dafür einen Abend freizuhalten und eine Anfahrt zu Ort xy in Kauf zu nehmen. Fachlicher Austausch funktioniert heute schließlich auch online, oft gezielter und flexibler.

    Persönliche Kontakte und spontane Gespräche können ein guter Grund für ein Meetup sein. Sie sind aber kein Selbstzweck und müssen für die jeweilige Zielgruppe einen echten Mehrwert bieten. Nur zusammen in einem Raum zu sitzen, macht einen Austausch noch nicht automatisch wertvoll.

    Für mich wäre daher die entscheidende Frage: Was bietet ein Meetup, das ich online nicht genauso gut bekomme? Wenn die Antwort überzeugt, kommen die Leute vermutlich von selbst. Eine Community sollte schließlich nicht um ihrer selbst willen existieren, sondern ihren Mitgliedern etwas bieten.

    Es ist für mich dennoch unpassender Content für ein WordPress-Forum.

    Wäre ein Pool von 10 - 30 Usern, die täglich bzw. viel öffters posten - abgesehen von Moderatoren, ja - durchaus richtig. In der jetzigen Form, erstikt man damit aber einen Kanal, der Neu User gebracht und neue Threads - was auch für Gäste wesentlich ansprechender wirkte. Jetzt haste halt Tage zwischen jeweiligen Posts in der Übersicht.

    Das Forum hat derzeit weder inhaltlich noch visuell einen klaren Fokus, da aktuell alles als gleich wichtig dargestellt wird. Man sollte die Struktur schlanker gestalten: Die Hälfte der Unterforen ließe sich problemlos zusammenlegen und unnötige leere Bereiche wie International entfernen.

    • 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.

    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.

    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.

    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?

    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.

    Code
    .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.