Beiträge von Raphael

    Ich betreue eine WordPress-Website mit folgender Konfiguration:

    • WooCommerce
    • WooCommerce PayPal Payments
    • WooCommerce Stripe Gateway
    • Germanized für WooCommerce Pro
    • Shiptastic inkl. DHL-Integration

    Es sind keine separaten Analytics- oder Marketing-Plugins installiert.

    Meine Frage: Ist bei dieser Konfiguration ein Cookie-Consent-Plugin wie Borlabs Cookie rechtlich erforderlich? Insbesondere interessiert mich, ob die von Stripe verwendeten Cookies _stripe_mid und _stripe_sid sowie mögliche Cookies von PayPal eine vorherige Einwilligung erfordern, oder ob sie zur Zahlungsabwicklung bzw. Betrugsprävention als technisch notwendig gelten.

    Hat jemand Erfahrung mit genau dieser Konfiguration und kann auf eine verlässliche Dokumentation oder rechtliche Einschätzung verweisen?

    Danke vorab!
    Raphael

    PS: Mist, hätte doch besser Rechtswissenschaften studieren sollen, bevor ich Webseiten mache. ;)

    Also ich würde mal die Plugins alle deaktivieren, bzw. ev. nur das eine, das den Bug verursacht und sehen, ob die Seite dann wieder läuft. Deaktivieren kannst du die Plugins (falls du nicht mehr ins Backend kannst) über FTP. Entweder den Pluginordner umbenennen (betrifft dann alle Plugins) oder das eine Problemnplugin eine Ebene höher stellen. Dann in WP wieder ganz normals einloggen.

    Falls du alle Plugins deaktiviert hattest, benenne den Ordner wieder korrekt und aktiviere die Plugins eines nach dem anderen. Das "Problemplugin" als letztes.

    Der Fehler kann mehrere Ursachen haben, das Errorlog wäre - Wie threadi bereits sagte - die sichere Basis. Mit Trial and Error kommt man aber auch hin.

    Viel Erfolg!
    Raphael

    makoto_k  JABA-Hosting hat bereits geantwortet. Das Thema ist nicht: Wer möchte Barrienfreiheit? Das Thema ist: Wer ist gesetzlich dazu verpflichtet? Und das ist eben nicht mein Kundenkreis. (Bilanzsumme > 2 Millionen, mehr als 10 Angestellte)

    Bei meinen Kunden (typischerweise Freelancer, klekine Firmen) frage ich dann auch meist, ob sie Barrienfreiheit wollen, aber das interessiert die meisten nicht.

    Es gibt einige Generatoren im Web. z. B. https://medienkonzepte.de/barrierefreihe…rung-generator/ oder https://siteboard.io/tools/barriere…rungs-generator

    Ich betreue selbst keine Kunden, bei denen das relavant wäre, meine Kunden sind kleiner. Aber ich würde - wenn es für meine Kunden relevant wäre - die Generatoren ähnlich einsetzen wie derzeit Generatoren für Texte zum Datenschutz. Und natürlich bei Änderungen immer anpassen.

    Aber die Anpassungen sind sekundär, auch hier ist es wie beim Datenschutz: Wenn der Kunde etwas ändert, muss er es selbst dokumentieren, wenn ich etwas ändere, trage ich es anschließend in der Erklärung ein.

    Dazu wäre eine Art Wiki nötig. Nach rund 20 Jahren Erfahrung mit WordPress lerne ich immer noch Sachen bezüglich WordPress, welche ich gerne teilen möchte.

    Ja, das halte ich für eine gute Idee. Aber besser noch als einfach ein Wiki oder irgendwas Anderes zu starten, wäre es wahrscheinlich sich in einer kleinen Gruppe zu treffen um zu sehen, was man machen kann, wieviel Aufwand es ist und was es bringt. Ich habe mich in meinen Urlaub mit medienkobold getroffen, von anderen war nicht so viel Interesse an einem Videomeeting. Vielleicht ist das ja nach der Urlaubszeit anders. Ich wäre jedenfalls offen dafür. Was meinst du B-52 ?

    threadi ja klar. Andere Themes ausserhalb des Repositories funkltionieren ja auch mit auto-Updates. Da war ich zu schnell. ;) Um auf Avada zurück zu kommen: Also die Betroffenen sollen - falls sie das Avada via Themeforest bezogen haben - einfach bei Themeforest nach dem Updateplugin fragen.

    Weißt du ev. ob das extra kostet? Falls du es nicht weißt, ist es auch egal, wir werden es ja merken und ich kann dann hier berichten. :)

    Eine Verständnisfrage für mich, WP macht ein automatisches Update ohne das geschaut wird, ob die PlugIns kompatibel sind?

    Ja. Es wird einfach das Update aufgespielt. Ohne Prüfung. In der Praxis ist das oft nicht so toll, aber andererseits: Wenn eine Seite 40 oder 50 Plugins hat, kann das ja nicht mit allen vorher auf Kompatibilität geprüft werden. Und mit den Themes vielleicht auch noch.

    Der Fehler kommt nicht, wenn ich das twentytwentyfive-Theme nutze. Liegt dann wohl an dem Theme Sparkling von colorlib in Verbindung mit dem Plugin "Classic Editor".

    Oder wie würdest du das nun interpretieren?

    Ich würde mich an den Themehersteller wenden und bis zur Reparatur/ Update die von mir vorgeschlagene Form (über 2025) verwenden. (Oder probieren, ob es genügt den Classic-Editor kurzfristig zu deaktivieren, das Beitragsbild zu definieren und dann wieder den Classic-Editor aktivieren)

    Dazu einige Fragen:

    - Es lassen sich keine neuen Beitragsbilder in neuen Beiträge mehr erstellen oder es betrifft auch alte Seiten?
    - Das Problem trat sicher erst mit dem heutigen Update auf?
    - Hast du probiert, ob es auch auftritt, wenn du das twentytwentyfive-Theme nutzt? Ich denke, dass das WP-Team es mindestens bei den Standardthemes geprüft hat. Falls das dann mit 2025 möglich wäre, könntest du - bis zur Lösung - immer das 2025 aktivieren, das Beitragsbild erstellen und dann zurück auf dein Theme gehen. Wäre zwar umständlich, aber besser als gar nichts veröffentlichen.

    Ein freundliches Hallo in die Runde,
    ich habe gerade auf einer Seite, die mit Avada betrieben wird, einen Hack bereinigt. Jetzt härte ich die Seite, damit das nicht mehr vorkommt. Grund für den Hack war, vermutlich ein veraltetes Avada.

    Daher würde ich sehr gerne Avada auch in die automatischen Updates mit einbeziehen. Nach meiner ersten Recherche ist das aber schwierig und eigentlich gar nicht möglich, weil Avada nicht über das WP-Repository bezogen wird. Angeblich gibt es auf Themeforest ein Produkt, das die Updates dann für einen gewissen Zeitraum automatisch ermöglicht, aber nach 6 Monaten ist auch das angeblich wieder vorbei und der Hersteller empfielt Updates grundsätzlich manuell zu machen.

    Weiß da jemand mehr darüber, bzw. hat jemand praktische Erfahrung mit dem Thema? Themeforest ist ja leider nicht wirklich kooperativ bzw. an einfachen Abläufen nicht wirklich interessiert.

    Also wenn es 15 Seiten auf mehreren Hostings mit verschiedenem FTP und individuellen PW sind, könnten auch noch folgende Möglichkeiten des Zugriffs bestehen. Ich habe mal KI gebeten, die möglichen Zugriffsmöglichkeiten für diese sehr spezielle Form des Hackings zu listen. (s. u.)

    Was das Reparieren betrifft: Wie bereits erwähnt, ist das ein ziemlich lästiger Prozess. Du hast vermutlich irgendwo (auch in den Backups) ein Script sitzen, das immer wieder startet, auch wenn du es kurz mal deaktivieren kannst. Daher musst du wirklich einen sehr genauen Prozess durchführen, Grob gesagt: Alles ausser den Ordener Uploads komplett ersetzen und aus verlässlichen Quellen neu installieren. (WP-Core, Plugins, Themes...) Den Uploadordner nach Dateien untersuchen, die dort nicht sein dürfen, die Datenbank nach Malcode durchsuchen. Alle Passwörter ändern. (FTP, DB, Login etc.) Das wird bei 15 Seiten wahrscheinlich ziemlich aufwändig.

    Hier potentielle Orte, über die die infektion auch passieren könnte (laut Perplexity):
    1. Dein Rechner oder Browser ist der gemeinsame Faktor. Es wird über deinen Rechner Folgendes abgegriffen:
    - WordPress-Sitzungscookies und gespeicherte Browserpasswörter.
    - Passwörter aus FTP-/SFTP-Programmen, SSH-Clients oder Passwortmanagern.
    - Zugangsdaten zum Hosting-Panel, zu E-Mail, DNS, Cloudflare oder Backup-Systemen.
    - API- und Application-Passwords.
    - Browser-Erweiterungsdaten und möglicherweise SSH-Schlüssel.

    2. Gemeinsamer Dienst oder gemeinsames Plugin
    Prüfe, ob auf allen Websites dieselben Komponenten installiert sind:
    - Theme
    - Page Builder, Backup-, Migration-, SEO- oder Security-Plugin.
    - Management-System wie MainWP, ManageWP, InfiniteWP oder ein Hosting-Tool.
    - Gemeinsame externe API, automatische Deployment- oder Backup-Verbindung.

    3. Gemeinsames Hosting-Konto oder Serverzugriff
    „Mehrere Hoster“ heißt nicht unbedingt „vollständig getrennte Zugänge“. Prüfe, ob mehrere Installationen über Folgendes verbunden sind:
    - Derselbe Hoster-Account oder dieselbe zentrale E-Mail-Adresse.
    - Derselbe Reseller- oder Agenturzugang.
    - Gemeinsames cPanel-, Plesk-, SSH- oder API-Konto.
    - Gemeinsame Backup-Ziele.
    - Gleiche DNS-/Cloudflare-Zugangsdaten.
    - Mehrere Websites im selben Webspace oder Dateisystem.

    Also wenn das das ganze Problem ist, dass du nur sehen willst, wie es "nicht eingeloggt" aussieht, wenn du eingeloggt bist, dann könnte man vermutlich einen Hack coden, den du aktivierst, wenn du nachsehen willst. Noch einfacher wäre aber, wenn du die Seite in einem anderen Browser aufrufst. Also ein Browser zum eingeloggt Arbeiten und ein anderer Browser für das Ergebnis. Kein Aufwand, funktioniert sofort.

    Ich entwickle zwar keine Plugins, aber ehrlich gesagt, würde ich nicht anraten ein Plugin mit KI entwickeln zu lassen und dann gar nicht zu verstehen, was da genau passiert, bzw. was im Code steht. KI als Unterstützung beim Entwickeln ist was anderes, als alles von der KI machen zu lassen.