Beiträge von hrybak

  • Ländersperre über .htaccess

    Hallo,

    nach meinen Information ist eine Ländersperre gemäß EU-Vorgaben aus Wettbewerbsgründen untersagt - Ausnahmen gelten wohl nur, wenn Urheberrecht betroffen ist.

    Deswegen werden die entsprechenden Steuermodule von den Server-Providern erst gar nicht angeboten - so z.B. bei IONOS.

    Wir haben uns jetzt so beholfen, dass wir ganze IP-Bereich blockieren - z.B. Sperren wir durch Require not ip 112.0.0.0/6 unsere chinesischen, indischen, vietnamesischen , indonesischen, . . . "Datenfreunde" aus dem asiatischen Raum. Leider ist es mit einer einzigen derartigen Anweisung nicht getan und setzt entsprechende Analyse der Server-Logfiles voraus.

    Geht nach unserem Wissen nicht anders.

    Aber auch wir sind natürlich für jeden weiterführenden Hinweis dankbar.

  • Problem mit dem Tiny MCE nach Firefox-Update

    zu WM-Loose: absolut richtig !!! Viele Nutzer von Joomla schätzen wie ich die vielfältigen Möglichkeiten zur Gestaltung einer Webseite. D.h. aber nicht automatisch, dass auch das notwendige Wissen vorhanden ist komplexere Programmieraufgaben oder Fehlerbehebungen in zumeist unbekanntem Umfeld umzusetzen.

    Ich selbst habe da auch meine Limitationen und kann allenfalls Hinweise geben, wo aus meiner (beschränkten) Sicht die Ursache gefunden werden könnte (siehe #14).

    zu bembelimen: was soll dieser sinnfreie und aus meiner Sicht überflüssig polemische Kommentar? Ja sicher ist Fachwissen von Vorteil - aber muss ich dazu gleich HTML-, CSS-, PHP-, JS- etc.-Experte sein??

  • Webseite wurde immer langsamer, immer mehr Abbrüche, jetzt ist die Seite nicht mehr erreichbar.

    Seite war erst da - dann weg und seitens Firefox wegen Zeitüberschreitung abgebrochen - jetzt (14:35) wieder da inklsive Aufruf der Unterseiten (Firefox, Edge).

    Ist das ggf. ein Serverproblem? Denn jetzt (14:38) kommt nach Seitenrefresh relativ schnell die Meldung, dass der Server nicht erreichbar ist.

    Und jetzt (14:42) geht's wieder - für 2 Minuten.

    Sehr merkwürdig.

  • Kommerzielles Facelifting

    In der Tendenz stimme ich vor allem Rolf und Shuffle zu: denn jede zusätzliche Extention (und dazu gehören auch Frameworks) birgt das Risiko, dass der Entwickler aus verschiedensten Gründen (z.B. Alter, veränderte Prioritäten, mangelnde Zeit, . . .) die Arbeit an der Extention einstellt.

    Mir bzw. uns ist das in den letzten 10 Jahren mindestens 5 Mal passiert, was jedes Mal mit großem Aufwand verbunden war und in 2 Fällenl wegen des nicht weiterentwickelten Frameworks sogar ein völliges Redesign der betroffenen Seite erforderte.

    Daher mein/unser Fazit: soweit wie nur möglich den Jooomla-Standard verwenden. Ganz ohne Extentions wird es je nach Komplexität der Seite und der Aufgaben wahrscheinlich dennoch nicht gehen. Daher sorgfältig abwägen was wirklich erforderlich ist.

    Zugegeben: CSS- und ggf. auch JS-Anpassungen sind dabei am Ende mehr oder weniger erforderlich (auch bei Verwendung eines Frameworks nicht völlig vermeidbar!!!) , aber auch hier sorgfältig abwägen, was nötig ist. Hängt natürlich viel von den eigenen Vorkenntnissen und den eigenene Anforderungen ab, aber wie von meinem Vorschreiber gesagt: hier im Forum wird andererseits sehr gut geholfen.

    Und noch eine weitere Empfehlung: alle eigenen Anpassungen gut dokumentieren, damit auch nach Jahren für einen selbst und für eventuelle Co-Entwickler nachvollziehbar bleibt, was aus welchen Gründen getan wurde.

  • Webseite fällt aus "„proxy_fcgi:error“ - Hat Jevents was damit zu tun?

    Wenn du diese IP-Adresse bei whois.com eingibst erhälst du u.a. die Information über den gesamten von hetzner genutzten Bereich

    Code
    % Abuse contact for '116.203.208.0 - 116.203.223.255' is '@hetzner.com'

    Damit ist klar, dass der Bereich 116.203.213.0 bis 116.203.213.255 zu hetzner gehört. Beide Werte eingegegeben bei https://iamroot.tech/cidr/ als lower und upper address ergibt als cidr-code

    116.203.213.0/24

    und als Anweisung für die htaccess

    Require not ip 116.203.213.0/24

    Du kannst natürlich auch beide Werte aus whois.com benutzen, also 116.203.213.0 und 116.203.223.255, erhälst dann aber als cidr-code 116.203.192.0/18 und bist damit erst einmal ausserhalb des von whois angegebenen Bereiches und weisst halt nicht, wenn du unnötigerweise ebenfalls aussperrst. Da hilft dann nur ausprobieren bzw. prüfen. Im konkreten Fall wäre das ebenfalls hetzner und ein Sperrung würde keine Seiteneffekte haben, was im Zweifel unangenehm wird, wenn sich z.B. Nutzer der Telekom oder Vodafone beschweren, dass sie nicht mehr auf die Webseite zugreifen können.

    Will damit sagen, dass geprüft werden muss, wer hinter der IP-Adresse steckt. hetzner habe ich persönlich nicht ausgeschlossen, da nur selten (im Vergleich zu den Chinesen etc.) bei uns zugegriffen wird. Das kann aber auch am Charakter der Webseite liegen.

  • Webseite fällt aus "„proxy_fcgi:error“ - Hat Jevents was damit zu tun?

    Zitat von eumel1602

    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/

  • Webseite fällt aus "„proxy_fcgi:error“ - Hat Jevents was damit zu tun?

    Zitat von eumel1602

    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.

  • Untermenüs nicht mehr permanent sichtbar

    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.

  • sidebar-left schmaler machen?

    Für den ersten Einstieg ins Thema schau mal hier

    Thema

    Cassiopeia Grid anpassen

    Hallo zusammen,

    nach der Migration auf J4 will ich das veraltete Template in Cassiopeia nachbauen und kämpfe mit dem Cassiopeia-Grid.

    Das Layout hat zwei schmale Icon-Menüs links, die ihre Position und Breite nicht verändern. Ich merke gerade, dass ich auch nach Lektüre einiger Tutorials (z.B. von Astrid) und Ausprobieren auf der Stelle trete.

    Die grid-template-areas habe ich in .site-grid auf ". side-l side-r comp comp ." für alle Auflösungen angepasst. Das hat funktioniert.

    Fehlt noch die…
    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