Beiträge von zero24

    PS das zweite Plugin welches uns hier vor Spam in diesem Fall in den Benutzerprofilen schützt ist das auch von uns geschriebene und veröffentliche Plugin "[WCF] Anti-Spam Benutzerprofil"


    https://pluginstore.woltlab.co…anti-spam-benutzerprofil/

    https://github.com/zero-24/wcf-antispam-userprofile


    Dieses Plugin folgt dem selben Ansatz und blockiert das Benutzen von besagten Zeichen im Benutzerprofil welches uns zu Hochzeiten des Spams auch massiv betroffen hat.

    Traust Du dem Plugin von Woltlab "Antispam Extended" diesbezüglich nicht so viel zu?

    Doch denn das ist das Plugin welches wir genau für unser Forum und zu diesem Zweck geschrieben und im Woltlab Store veröffentlicht haben. ;)


    https://pluginstore.woltlab.co…2-wbb-anti-spam-extended/

    https://github.com/zero-24/wbb-antispam-extended

    das klingt interessant. Das heißt, dass man gar keine Einträge mit chinesischen oder kyrillischen Schriftzeichen machen kann?

    Jein alles was nicht ascii ist wird hier automatisch unpublished (siehe hier), dieses Plugin enthält auch einige allowlists welche darüber hinaus dann noch expliziert u.a. im deutschen gebräuchliche Zeichen erlaubt: https://github.com/zero-24/wbb…istener.class.php#L26-L37


    Im Speziellen sei hier gesagt das diese erweitere Überprüfung in diesem Forum lediglich auf Beiträge von Benutzergruppen angewendet wird welche unter 50 Punkte haben also in erster Linie auf neue Benutzer. Das konnte zumindest bei uns schnell zu einer deutlichen Reduzierung jeglicher Spamposts führen ohne legitime Posts zu blockieren und dadurch unnötigen Moderativen Aufwand zu produzieren.


    Um deine Frage also richtig zu beantworten ganz neue Benutzer können es nicht du könntest es schon da du bereits über den 50 Punkten bist. ;)


    An sich eine gute Idee, ich könnte das ebenfalls in ECC+ integrieren.

    Ein Joomla Plugin mit diesem Ansatz existiert bereits: https://github.com/zero-24/plg_contact_antispamextended und kann gerne genutzt und erweitert werden.

    Dabei handelt es sich um eine Datei welche Joomla anlegt wenn man versucht Joomla auf einem remote Datenbankhost zu installieren. Die Datei kann man im Ordner "installation" finden.


    Die Meldung sollte diese sein

    Zitat

    Um die Eigentümerschaft zu bestätigen muss die Datei „_JoomlaxH97KlPjwxqa59NyjGdul.txt“, die soeben im „installation“-Verzeichnis von Joomla! erstellt wurde, wieder gelöscht werden.


    Der Grund ist das ohne eine solche Abfrage jeder eine Webseite (und das darunterliegende Hosting) mit einem noch nicht ausgeführten Joomla Installer übernehmen könnte.

    Was Joomla und seine Drittanbieter-Erweiterungen betrifft, stellt sich sowieso mal wieder die Frage, inwiefern ich da die pgsql-Datenbanken noch beachten sollte.

    Kann ich verstehen. Ich würde es so halten die Joomla Datenbank API zu nutzen dann sollte "nur noch" der install, deinstall und update Pfad für DDL Änderungen manuell geregelt werden müssen. Ich persönlich würde es für pgsql und mysql machen aber auch die Statistiken zeigen keine große Verbreitung von pgsql: https://developer.joomla.org/stats/db_type

    Ich habe mal einige beliebte Erweiterungen durchgesehen. Die unterstützen nahezu alle keine pgsql-Datenbanken mehr. Da verwundert es mich ein wenig, dass bei Joomla 4 noch daran festgehalten wird. Aber das ist ein anderes Thema.....

    Naja (fast) alle Plugins und Module ohne eigenen Datenbanktabellen welche die Joomla Datenbank API benutzen sollten auch ohne Probleme auf pgsql laufen. Komponenten werden eher das Problem sein da diese eine install/deinstall/update SQL brauchen für die Datenbanktabellen.

    Das sehe ich hier doch etwas anders zero24, in Joomla 3 wird sich hier hier nichts mehr ändern. Aber man muss es im Auge behalten. Ein Model zu laden und zu nutzen ist auch kein problemloser Garant für Updatefestigkeit und rechtfertigt nicht unbedingt den Mehraufwand.

    Naja das Model stellt auch sicher das all das ausgeführt wird welches auch beim "manuellen" drücken der Button passiert samt plugin trigger (u.a. action log) so kann man gut nachvollziehen was passiert und es wird alles korrekt verarbeitet. Außerdem kümmert sich das Model darum das cache geleert wird und das die einträge richtig geordnet sind.


    All das bekommt man dadurch "geschenkt" natürlich kann man auch direkt auf die Datenbank eingreifen ich würde nur dringend davon abraten :)

    Hi,


    um einen Eintrag auf "unfeatured" zu setzten bzw. um irgendetwas an Tabellen zu ändern die nicht zu deiner eigenen Erweiterung gehören bitte nicht direkt in die Datenbank eingreifen das führt ganz schnell zu Dateninkonsistenzen. Um Änderungen zu machen bitte immer das Model der Komponente (hier com_content) benutzen.


    Dann werden alle Abhängigkeiten auch welche potenziell in Zukunft hinzukommen berücksichtigt.

    Wenn man dort den Nutzernamen und das Passwort eingegeben hat, verschwindet die Seite vom Bildschirm und kann auch nicht mehr aufgerufen werden. Habe das mit den Browsern Edge, Firefox und Opera getestet. Immer das gleiche Problem. Woran kann das liegen? Ich nutze die aktuellste Version von Joomla, das Formular ist das Standardmodul. Kann mir da jemand weiter helfen?

    Hmm hast du ggf eine login Weiterleitung eingerichtet, was passiert wenn du falsche Zugangsdaten nutzt und was steht nach dem Login in der Browser Console und was in der URL Zeile?

    2. Falls man das ändern muss, gilt das dann für alle Passwörter, oder ev. nur für Administratoren?

    Musst nichts ändern wird die Einstellung übernommen die du hinterlegt hast. Nur der Default wird angepasst für neu Installationen.


    3. An die Entwickler: Bleibt das so bis zum Erscheinen der Stable-Versionen?

    Was meinst du? Es sind keine Änderungen in der Hinsicht geplant.

    1. Sollten Joomlas (produktive Seiten), die erst später mal auf J4 umgestelt werden sollen, auf der letzten 3.9 bleiben oder kann/muss man diese mit Erscheinen von 3.10 auf 3.10 updaten?

    Man sollte auf 3.10 updaten, verhält sich wie ein 3.9.xer update nur das die Version angehoben wird und der Pre Upgrade Checker da ist.



    2. Wie verhält es sich, wenn Sicherheitspatches von J3.9 oder 3.10 veröffentlich werden müssen. Werden diese jeweils weiter hochgezählt?

    Wird nur noch 3.10 mit Sicherheitspatches versehen, oder auch noch 3.9?

    Mit dem Release von 3.10 geht 3.9 EOL (so wie immer wenn eine neue Minor raus kommt) d.h. nur 3.10 und 4.x werden mit Patches versorgt.


    Bleibt die Frage, ob 3.10 ein Pflichtupdate wird und auf produktiven Seiten genutzt werden kann (Performance-Probeme?), oder nur in Verbindung mit der J4-Umstellung kurzfristig genutzt werden muss.

    Was für Performance Problem erwartest du denn? 3.10 ist ne 3.9+ Pre upgrade Checker und der ist "nur" im Backend im Updater.


    Und ferner, wie das mit Sicherheitspatches gehandhabt wird, sollten welche nötig sein. 2 Jahre ist eine lange Zeit.

    Wie gesagt nur 3.10 und 4.0 werden dann noch sicherheitspatche bekommen aber das ist das ganz normale vorgehen bei jeder Minor Version. Für 3.10 ist es auch nicht ausgeschlossen das noch Bug Fixes kommen nur wahrscheinlich nicht mehr so häufig wie bei 4.x ;)

    Da scheinen auch noch schließende '}' zu fehlen oder der Auszug ist nicht vollständig.


    $this->eventranking scheint ein array zu sein wo stdClass Objecte drin sind, warum auch immer scheint es ID 0 nicht zu geben..


    $this->eventranking[1]->[0]->div_name ggf.?


    Sonst pack $this->eventranking doch mal in nen foreach und schau was dann raus kommt im debugger als key + value

    Ich kann dir nicht ganz folgen wo genau versucht du das aufzurufen?


    Wenn ich das richtig sehe ist $this->eventranking ein array mit dann einen stdClass drin? Versuch mal $this->eventranking[0]->div_name dann solltest du den erste bekommen.


    und mit nem foreach loop über $this->eventranking dann alle.