Beiträge von hrybak

    Kann mir einer den bevorzugten code nennen um sie auzuschließen... ? ich geh mal on den IPs aus oder?

    Dazu folgendeer Nachtrag: die Anweisung zur Sperrung wäre Require not ip IP-Adresse

    Das hat allerdings den Nachteil, dass für jede einzelne IP.Adreese eine Anweisung in die htaccess eingetragen werden müsste. Sinnvoll ist daher die Sperrung ganzer IP-Bereiche wie z.B. durch Require not ip 62.113.113.0/24. Dadurch werden in diesem Beispiel gleich mal 255 IP-Adressen von Huawei gesperrt. (Trotzdem waren bei Huawei immer noch ca. 25 dieser Anweisungen erforderlich)

    Die IP-Bereiche lassen sich ermitteln über https://www.whois.com/whois/ für IP4. Leider werden hier IP6-Adressen nicht analysiert. Die Syntax einer Bereichsdefinition wird entweder auch dort angegeben oder kann ermittel werden über https://iamroot.tech/cidr/.

    IP6-Adressen werden übrigens sehr häufig von deutschen Telekomfirmen (Telekom, Vodafone, Deutsche Glasfaser, ...) verwendet und die sollten nicht gesperrt werden, da sonst die Webseite im Zweifel nicht mehr errichbar ist. Ich benutze dazu sehr zuverlässig https://www.geolocation.com/

    so was wie meta-externalagent taucht da auf... aber eben immer wieder links von jevent...

    Viviana hat es gesagt: meta ist extrem aggressiv und hatte bei uns vorletztes Jahr jede einzelnen über JEvents verwalteten Event mehrmals pro Sekunde über mehrer IP-Adressen abgefragt. Das Datentransfervolumen war dann teilweise 400 GB am Tag groß und der Provider (IONOS) hat dann unsere Seite einig Tage wegen Überlastung gesperrt. Geholfen hat zunächst die Sperrung der IP-Adressen über die htaccess. Das ist leider eine mühsame Arbeit aber nach unserer Erfahrung der einzige Weg.

    Das Gute: meta beachtet offenbar die robots.txt - das hilft spürbar

    Das Schlechte: es gibt noch viele weitere agressive Datendiebe: Chinesen, Vietnamesen, US-Americaner, Briten, Franzosen, OpenAI, . . .

    Im Zusammenhang mit JEvents wird überall jeder einzelen Event abgefragt. Diese Erfahrung haben auch andere machen müssen (hat hier im Forum auch jemand in den letzten Tagen berichtet) . Bei uns ist das besonders gravierend, da wir als Tanzsportverein ein sehr große Zahl von Veranstaltungen haben.

    Aber wir haben es im Griff - u.a. durch regelmäßige Kontrolle der log-Files und Update der htaccess bei Bedarf.

    Unter Version 5.3.3 haben wir auf unser Webseite (http://www.tsg-dacapo.de) der sidebar-left mehrere Navigations-Module zugeordnet. Einige davon verfügen über Untermenüs, die permanent sichtbar sind (siehe rechts - sichtbar zur Zeit nur für die Vereinsadministration mit besonderen Rechten. Lediglich das Untermenü "Beantragen" soll öffentlich zugänglich werden und permanent zu sehen sein, damit z.B. Interessenten sofort sehen, dass sie auch online eine Mitgliedschaft beantragen können.)


    In unserer Testumgebung (http://www.tanzeninebersberg.de) haben wir nun den Update auf Version 6.02 ausgeführt und müssen feststellen, dass die Untermenüs nicht mehr sofort sichtbar sind, sondern explizit geöffnet werden müssen.

    Ferner hat sich die Objektstruktur verändert (siehe ersten (J5) und zweiten (J6) Screenshot).

    Wir haben unsererseits diese Navigationsmodule nur insofern verändert, dass Textfarbe, Texthöhe und Zeilenabstand verändert wurden. Darüber hinaus wurde in den betroffenen Navigationsmodulen unter "Erweitert" für jedes Modul lediglich eine eigene CSS-Klasse definiert und das Layout auf "Standard" gesetzt.

    Dazu nun folgende Fragen:

    • Wie kann erreicht werden, dass ein Untermenü wieder permanent sichtbar wird. Die anderen Möglichkeiten zur Konfiguration des Layouts geben das nicht her und sind letztlich nur eine optische Variation.
    • Mit welcher Begründung wurde die permanente Darstellung aufgehoben? Denn dass dies absichtlich erfolgt ist zeigt die Definition der neuen Objektstruktur.

    Für den ersten Einstieg ins Thema schau mal hier

    Antonella
    28. Mai 2022 um 13:04

    Geholfen hat mir damals bei der Umstellung auf Cassiopaeia auch

    W3Schools.com
    W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript,…
    www.w3schools.com

    Kurz mal reingereicht:

    Das ist mir aufgefallen bei dem Mouseover beim Termin (geht über die ganze Seite):

    Problem habe ich noch nicht gefunden, woher es kommt.

    Vielleicht hat jemand anderes auch das Problem.

    Schwer zu beantworten ohne Kenntnis des JEvents-Themas (wir haben extplus und da geht es nach wie vor, sowohl für 3.6.91 als auch 92). Suchen würde ich aber auf jeden Fall in den Benutzerdefinierten Layouts und hier unter Monatskalender Tooltips (gelten auch für die Wochenansicht).

    Anworten kann letztlich aber nur JEvents selber, da die Tooltips sehr individuell angepasst sein können und bei uns in der Tat sehr angepasst sind.

    Habe ähnliches Problem mit Joomla 5.4 und JEvents 3.6.92 und IONOS als Hoster :

    Im Backend kann ich nicht mehr auf die RSVP-Templates zugreifen. Folgende Meldung erscheint:

    Im Frontend funktioniert das Template aber noch wie vorher.

    Ist bereits an JEvents als Bug gemeldet. Habe aber noch keine Antwort.

    Ups!

    Erst einmal danke für den Hinweis. Da muss ich mir dann die Fragen selbst stellen. Antwort fällt mir im Moment allerdings schwer, zumal meine Vorgehensweise beim Handling von Bildern auf Smartphones eine andere ist.

    Wenn ich eine Antwort finde, die von allgemeinem Interesse sein könnte melde ichmich noch mal.

    Mir ist erst jetzt aufgefallen, dass bei einer Displaybreite von unter 992px links bzw. rechts angeordneten Bildern automatisch die Klassen .imgleft bzw. .imgright zugeordnet werden.

    Kann mir jemand erklären, welchen Nutzen dieser Automatismus hat, der leider die eigenen float-Anweisungen in der user.css aushebelt.

    Ich konnte die entsprechende mit !important versehenen Anweisung in der template.min.css meinerseits durch eine entsprechende mit !important versehene Anweisung wieder rückgängig machen. Dennoch bleibt die obige Frage bestehen, zumal der beschriebene Automatismus erst einmal nur Verwirrung gestiftet hat.

    Weiterhin ist mir aufgefallen, das bei älteren Bildern dieser Automatismus nicht greift (siehe Bild von 2013). Weshalb?

    Ich kann das nur mit dem Beispiel eines JEvents-Templates (siehe https://www.tsg-dacapo.de/jeventstestlis…?filter_reset=1 ) erklären, das hilft aber vielleicht trotzdem.

    Aufgabe war, das eigene Feld Plflichtfeld * an die erste Stelle zu setzen. Es geht bei diesem Beispiel wie folgt:

    • In der user.css auf tbody der Tabelle mit den eigenen Feldern display: grid anwenden.
    • Die entsprechende Zeile ( tr ) mit dem eigenen Feld durch grid-row-start auf die gewünschte Position setzen. Erleichtert wird das Ganze durch Vergabe eine Klasse für das eigene Feld - im konkreten Fall ist das jev_start

    Bitte jetzt keine Kommentare der Art "Tabellen sind kein gute Lösung" etc.. JEvents arbeitet nun mal mit Tabellen und da heißt es Lösungen für finden.

    Außerdem dürfte grid-row start die entscheidende Antwort sein.

    Ich finde es grundsätzlich nicht gut als Lösung auf eine andere Extention zu verweisen, da der Wechsel erheblichen Aufwand mit neuen, anderen und vor Allem unbekannten Problemen (ich sage an dieser Stelle bewußt nicht "Herausforderung") mit sich bringt

    Lösungen sollten immer erst im Rahmen der gerade genutzten Extention gesucht werden. Das hilft den Betroffenen am besten.

    Ich weiß ehrlich gesagt nicht, was eine Alternative wäre.
    Das Particle-System war für uns völlig ausreichend, um per Modul mal etwas Spezielles in eine Seite direkt laden zu können - ich will keinen Pagebuilder wie JoomShaper oder Yootheme, dann holt man sich die nächsten Probleme und Abhängigkeiten ins Haus.

    Mit dem Update von Joomla 4 auf 5 hatte ich mich von Gantry verabschiedet und auf die Joomla-Standards konzentriert. Grund war im Wesentlichen ein ungutes Gefühl über die Zukunft von Rocket Theme - ausgelöst u.a. dadurch, dass z.B. ziemlich zeitgleich auch der ARK-Editor nicht mehr verfügbar war.

    Im Ergebnis hat sich die Entscheidung für Cassiopeia und TinyMCE als richtig erwiesen, zumal der Umstellungsaufwand deutlich geringer war als erwartet und gleichzeitig eben die Abhängigkeiten reduziert werden konnten. Insbesondere der Ersatz der Particles durch Standard-Module war völlig problemlos möglich und aus heutiger Sicht würde ich sogar sagen, dass letztere eh' die bessere Alternative sind.

    Zugegegeben: die betroffene Webseite (https://www.ig-lilienthal.de/) ist sicher nicht besonders komplex, soll an dieser Stelle aber einfach nur zeigen, dass die Standards gute Alternativen sein können.

    Vl. habe ich auch falsche Vorstellungen von Joomla.

    Ich will es mal vorsichtig ausdrücken: eventuell hast du falsche Vorstellungen, was den Aufwand des Webseitenmanagements als Webmaster betrifft.

    Vereinsvorstände haben in der Regel andere Aufgaben als sich um eine Webseite zu kümmern. Wie Rolf schon sagte, sollten die auf die Erstellung der Inhalte beschränkt werden und selbst dabei ist von Zeit zu Zeit Kontrolle erforderlich (z.B. bei ausufernder Länge von Artikeln, fehlende Betitelung von Bildern, unlesbare Schriftfarben und -typen und vieles andere mehr).

    Als hilfreich hat sich erwiesen, den Vorständen bzw. den Autoren Hinweise für die Gestaltung von Inhalten zu geben. Aber auch hier sollte nicht gehofft werden, dass das immer gelesen geschweige denn immer befolgt wird.

    Wichtig ist auch, bevor mit der Gestaltung der Webseite begonnen wird, mit den Vorständen abzustimmen, was sie denn auf der Webseite an Funktionalität benötigen und ggf. erst einmal einen Prototypen zu bauen.

    Wenn Du jetzt den Eindruck hast, da kommt ja was auf mich zu, dann ist dieser Eindruck richtig 8).

    P.S. das aus meiner mehr als 10jährigen Erfahrung mit "nur" 2 Vereinswebseiten bei einem Verein mit ca. 500 (https://www.tsg-dacapo.de/) und einem Verein mit ca. 50 (https://www.ig-lilienthal.de/) Mitgliedern.