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.
-
Verstehe...viel Erfolg weiterhin...
-
Um es nochmals aufzugreifen:
Nur so aus Interesse: welche Probleme erzeugt der UTF-8 Tag bei dir?
Was willst du ( Guri ) eigentlich erreichen? Vielleicht magst du mal ein bisschen ausholen was dein Ziel ist (weniger das "was" sondern mehr das "warum"). Weil aktuell fühlt es sich an, dass du hier Supportressourcen bindest für etwas was sehr fragwürdig 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.
-
Das unter dem Editor sind die "editor-xtd" plugins. Wenn die nicht sichtbar sind, einfach entsprechend die Zugriffsebenen einstellen oder komplett deaktivieren.
-
Wo bist du? Was machst du?
-
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.
-
Zwar ein anderer Kontext, aber den Code kannst du auch nutzen.
-
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.
-
Auch wenn bereits gelöst:
Achte unbedingt darauf, dass post_max_size mindestens genauso so hoch ist wie upload_max_filesize ! Am besten man stellt beide gleich hoch ein.
Oder ersteres sogar noch höher, weil man bei einem Formular ja meistens noch ein paar Daten mehr mitschickt und nicht nur die Datei.
-
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):
Code
Alles anzeigen############################################################# ###### Hier den Hash verifizieren und den Nutzer laden ###### ###### $juser = Factory::getUser($userId); ################## ############################################################# PluginHelper::importPlugin('user', 'joomla'); $userdata = [ 'username' => $juser->username, 'language' => '' ]; $options = [ 'action' => 'core.login.site' ]; // Try to login $results = $this->app->triggerEvent('onUserLogin', array((array) $userdata, $options)); if (in_array(false, $results, true) == false) { $user = Factory::getUser(); $options['user'] = $user; $options['responseType'] = 'Joomla'; // The user is successfully logged in. Run the after login events $this->app->triggerEvent('onUserAfterLogin', array($options)); // Do a redirect to where ever // $this->app->redirect(...); return; } // Login failed => Do cleanup $this->app->triggerEvent('onUserLoginFailure', array((array) $response)); // Do a redirect to where ever // $this->app->redirect(...); -
-
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.
-
joomla-cms/default.php at 4.1-dev · joomla/joomla-cmsHome of the Joomla! Content Management System. Contribute to joomla/joomla-cms development by creating an account on GitHub.github.comCode
$url = str_replace('https://example.com', '', $url);Und im Backend deinen "relativen URLs" ein "https://example.com" voranstellen.
-
Für uns gilt:
Jede manuelle Anpassung in Coredateien, die mit einem Update bereinigt werden, vor einem Update wieder rückgängig zu machen.
Wenn es genau die selben Änderungen sind, muss nichts gemacht werden. Das Update überschreibt die geänderten Dateien einfach...
-
-
Code
php cli/joomla.php core:updateDamit kannst du über die Konsole/Cronjobs Updates fahren.
(Die CLI hat noch einiges mehr auf lager: "php cli/joomla.php list")
