Beiträge von bembelimen

    Wenn ich es richtig sehe, bringt 4.2 eine Reihe wichtiger Verbesserungen mit sich, die aber auch die Bedienung von Joomla teilweise stark ändern.

    Welche siehst du denn? Und welche ändern die Bedienung?


    Es gibt alle 6 Monate eine neue "Minor"-Version (also 4.2, 4.3, 4.4, ...) und alle 2 Jahre eine neue Hauptversion (4, 5, 6, ...). Zwischen den Minor-Versionen gibt es von der Bedienbarkeit kaum unterschiede. Die Versionen sind auch voll Rückwärts-Kompatibel.

    Also starte mit 4.1 und wenn du dich sauber an die Standard hälst, sollte es keine Probleme bei Updates auf 4.2, 4.3 etc. geben.


    Nachtrag:


    Der Link ist mittlerweile obsolet, da sich einige Sachen anders priorisiert haben.

    Eine Alternative (die ich bedeutend schicker finde, da man dann auch mit Modulen etc. arbeiten kann) ist es, den Home-Menupunkt (und alle anderen Sachen, auf die man nur nach dem Login kommen soll) auf "Registered" zu stellen + einen "Login-Link" anzulegen.


    Zusätzlich kann man in der Globalen Konfiguration die Standard-Zugriffsebene auf "Registered" stellen, macht das Pflegen bedeutend einfacher (und man muss nicht dran denken).


    Damit versperrt man sich nicht der Option sein System Offline nehmen zu können, wenn es nötig ist.

    Der Aufwand sei wegen der massiven Änderungen bei der Jommla 4 - Authentifizierung wesentlich höher als bei Joomla 3.

    In Joomla! 4 hat sich zu Joomla! 3 so ziemlich genau nix geändert bei der Authentifizierung...und auch nix bei den Plugins.

    Gruppe "Skill" anlegen => Kategorie "Skills" anlegen => Permission in der Kategorie für "Edit Own" auf "Erlaubt" (Rest auf Vererbt) => Für jeden User einen Artikel anlegen und den entsprechenden User als Ersteller eintragen.


    Damit kann jeder User nur seinen Artikel bearbeiten.

    Du benötigst definitv das Artikeltext-Feld.


    Um eine Textarea anzubieten, kannst du entweder den Editor auf "none" stellen (eventuell bietet sich auch "Code Mirror" an, da man dann auch Zeilennummern und Farben hat) oder in deinem Override den Typ des Artikeltextes auf "Textarea" setzen.


    Ich würde ersteres empfehlen.


    Du kannst natürlich das Feld auch mit CSS wegblenden...

    H Captcha hat seinen Standort in Kalifornien, ich bezweifle, dass man da Datenschutzmäßig einen Unterschied merkt.


    Prinzipiell würde ich auf Captchas verzichten, besonders Recaptcha und H Captcha sind für nicht sehende Menschen unter aller Sau (probiert dazu mal bei Recaptcha die Sprachlösung aus oder bei HCaptcha das ganze ohne Maus zu bedienen).


    Captchas sind, wenn man darüber nachdenkt, auch psychologisch der falsche Ansatz. Anstatt die Bösen auszusperren müssen sich die Guten beweisen, dass sie gut sind => Schuldumkehr...


    Lösungen:

    - Zeitsperre (u.a. auch per JS dann den Task/Session Token erst nach X Sekunden setzen um zu schnelle Absender ins leere laufen zu lassen)

    - Verbotslisten

    - Honeypot (eventuell auch mit Wert befüllen, der nach X Sekunden geändert wird)

    - Nachladen von Elementen per AJAX

    - Zeitbeschränkung wie oft ein User ein Formular absenden darf

    - etc.


    Alles von dem ein normaler User nichts mitbekommt in der Regel barrierefrei sind und relativ gut schützen.

    Hallo,


    interessantes Problem. Spontan habe ich auf extensions.joomla.org nichts gefunden, aber vielleicht hast du mit anderen Suchwörtern mehr Glück.


    Ich habe sowas ähnliches schon mal mit einem Plugin gelöst. Kommt jetzt ein bisschen darauf an, wie es um die Programmierfähigkeiten steht. Grob umrissen sehe ich da 2 Bereiche, die behandelt werden müssen. Hierbei bietet sich com_ajax an.

    Bereich 1: im Backend (?) die Userliste um die Links zu versenden. Dort kann per Plugin ein Button eingebaut werden, was bei Klick den Hash generiert (irgendwo speichert) und an die gewählten Benutzer die Email mit Link (z.B. https://example.com/index.php?…group=system&hash=xxxxxxx) versendet (theoretisch könntest du hier auch das Passwort neu setzen und diese nochmals mitschicken...je nach Bedarf). Den Link würde ich wie gesagt über com_ajax laufen lassen. (eine kleine Idee meinerseits: hier könntest du auch einen zweiten Button einbauen, der einen QR-Button anzeigt, mit dem dann die Teilnehmer sich live vor Ort einloggen können, falls sie die Email nicht parat haben)


    Nun geht es darum den Klick auf den Link zu verarbeiten. Einen User einzuloggen ist relativ einfach in Joomla: zuerst wird der User authentifiziert (was die "authentication" Plugins erledigen) und dann autorisiert (das erledigt dann das user/joomla Plugin).

    Wir überspringen das authentifizieren, da wir ja nicht den normalen Loginprozess verwenden sondern landen direkt im Autorisierungs (und somit Login-)prozess. Nachdem du über den Hash den richtigen User aus der Datenbank geladen hast, kannst du diesen Einloggen.


    Wir reden hierzu von folgener Stelle: https://github.com/joomla/joom…Application.php#L902-L932

    Diesen Code übernimmst du in dein Plugin.


    Zusammengefasst könnte der Code im Plugin in etwa so aussehen (umschlossen natürlich in der entsprechenden Methode, die über com_ajax getriggert wird):


    Sorry, aber außer die "Public" Zugriffsebene ist jede Core-Usergruppe/Ebene wie eine eigen erstellte. Da gibts codetechnisch absolut keinen Unterschied und man kann diese ändern/löschen oder neue anlegen. Wichtig ist nur, dass man am Ende die Zuweisung in den Einstellungen aktuell hält und schaut, dass man sich nicht aussperrt.

    Code
    php cli/joomla.php core:update

    Damit kannst du über die Konsole/Cronjobs Updates fahren.


    (Die CLI hat noch einiges mehr auf lager: "php cli/joomla.php list")