Beiträge von Clemens-XS

Rolf Dautrich Caniuse hatte ich damals konsultiert, ehe ich die media queries ausprobiert hatte. Caniuse ist nach meiner Erfahrung nicht zuverlässig, was Mobilbrowser betrifft.

markowski Danke für deinen Hinweis. An die Höhe hatte ich bei den media queries bisher nicht gedacht. Um möglichst jetzt schon eine Lösung zu erhalten, habe ich eine zusätzliche query eingefügt und zudem in YooTheme die Positionierung des Signets geändert auf "sticky when scrolling up". Dies gilt dann allerdings für alle Geräte und Portrait- sowie Landscape-Darstellung. Konkret ist das Signet beim Aufbau der Webseite oben positioniert. Scrollt man nach unten, verschwindet das Signet zusammen mit dem Inhalt der Seite nach oben. Sobald man auch nur ein bisschen wieder nach oben scrollt, schiebt sich das Signet wieder an die normale Position.

Die dank deines Tipps zusätzliche Query verringert die Breite und Höhe des Signet abhängig davon, ob bei einem bestimmten Bereich der Screenwidth eine bestimmte Höhe nicht überschritten wird:

.uk-logo img {
    @media screen and (min-width: 641px) and (max-width: 960px) and (min-height: 500px) {
    width: 60vw !important;
	min-width: 400px;
    max-width: 500px;
	margin: 10px 0 6px 5px !important;}
}
.uk-logo img {
    @media screen and (min-width: 641px) and (max-width: 960px) and (max-height: 499px) {
    width: 41vw !important;
	min-width: 200px;
    max-width: 350px;
	margin: -12px 0 -12px 5px !important;}
}

Dank dieser Lösung ist es mir nicht mehr so wichtig, das Signet immer sticky zu halten, ausgenommen bei Smartphone im Querformat.

Danke an alle, die mir hier geholfen haben bzw. Hinweise gegeben haben!

Danke für deinen Hinweis. Mit clamp() habe ich bereits vor knapp einem Jahr experimentiert, um die Fontgröße eines Textes zu variieren, die über einem Bild liegt (Overlay). Das Bild skaliert gut auf den verschiedenen Geräten. Aber die Schrift muss sehr genau angepasst werden, damit sie harmonisch passt und auch nicht wichtige Bildteile verdeckt.

Clamp hat bei einem guten teil der Browser nicht zuverlässig funktioniert.

Es gibt erstaunlich viele CSS Definitionen, die nicht wirklich in allen möglichen Browsern zuverlässig funktionieren. So hatte ich hier ja im Frühjahr versucht zu klären, wie man mit CSS appearance() die Mobilbrowser dazu bringen kann, die Formular-Eingabefelder und Option-Felder so darzustellen, wie ich das gerne hätte. Nada! Jeder Browser macht da was er will!

Aktuell definiere ich die Größe des Logo / Signet mittels media-query wie folgt:

    @media screen and (max-width: 480px) {
   width: 80vw !important;
    min-width: 300px;
   max-width: 400px;
    padding-bottom: 0px;
    margin-left: 6px;}
}

Die weiteren queries folgen diesem Prinzip. Das führt dazu, dass das Logo z.B. auf einem Tablet im Potraitmodus gut aussieht, aber auf einem Smartphone im Querformat, was ja ungefähr ein ähnliches Pixelmaß hat wie das Tablet, über ein Drittel der Bildschirmhöhe vom Signet eingenommen wird.

Mir fehlen also nicht Definitionsmöglichkeiten, die vom Pixelmaß abhängen, sondern das Kriterium ist: Smartphone im Querformat.

Und dann ist sogar die Bedingung "pointer: coarse" zu ungenau, weil sie ja auch für Tablets und Laptops mit TouchScreen gelten würde.

Ich fand (witziger Weise mit Hilfe der KI im BraveBrowser) folgendes Javascript, um Smartphones über den UserAgent zu erkennen:

const isMobile = {
  Android: function() {
    return navigator.userAgent.match(/Android/i);
  },
  BlackBerry: function() {
    return navigator.userAgent.match(/BlackBerry/i);
  },
  iOS: function() {
    return navigator.userAgent.match(/iPhone|iPad|iPod/i);
  },
  Opera: function() {
    return navigator.userAgent.match(/Opera Mini/i);
  },
  Windows: function() {
    return navigator.userAgent.match(/IEMobile/i);
  },
  any: function() {
    return (isMobile.Android() || isMobile.BlackBerry() || isMobile.iOS() || isMobile.Opera() || isMobile.Windows());
  }
};

if (isMobile.any()) {
  // Mobile!
} else {
  // Not mobile
}

Nun müsste dieser Code noch durch die Bedingung "if orientation = landscape" ergänzt werden. Oder durch "aspect-ratio".

Ferner bin ich bereits mit der vermutlich einfachen Aufgabe überfordert, die "if" und "else" Zeilen so zu ergänzen, dass der gewünschte Effekt "sticky" oder "non-sticky" zustande kommt.

Vielleicht findet sich ja noch jemand hier, der mir dabei hilft?

Matzeweb Hast du diesen Teil meines ersten Beitrags gelesen?

Zitat

Bevor ich diese jQuery-Lösung eingebaut habe, hatte ich versucht, die Aufgabe per CSS media-query zu lösen und verwendete z.B.

@media only screen and (orientation: landscape) and (pointer: coarse)

Leider werden diese media-queries anscheinend von vielen Browsern nicht beachtet, speziell nicht von Mobil-Browsern. Wenn es funktionieren würde, wäre es ja Klasse und ich müsste dann nur den CSS-Code aus der Klasse uk-sticky als Definition hinein kopieren. – Script-Lösungen kann ich leider gar nicht selbst basteln, weil ich nix davon verstehe.

Da diese media query anscheinend von manchen Mobilbrowsern ignoriert wird, wäre es doch eine clevere Idee, die Mediaquery durch Javascript erledigen zu lassen. Und dazu hatte ich ja den Codeschnippsel der bereits aktuell genutzte Teil-Lösung gepostet. Dieses Script setzt aber nur das "Attribut" 770px zur CSS-Klasse "uk-sticky", welche sich dann auf Elemente der Klasse tm-hedaer-mobile auswirkt.

Mein Wunsch ist, die Mediaquery durch jQuery oder anderes JS ausführen zu lassen, wodurch dann in dem gewünschten Fall "Touch-Device und Querformat" das Signet auf non-sticky gesetzt wird. Javascript-basierte Media-Queries funktionieren anscheinend zuverlässiger, als reine CSS-basierte.

WM-Loose hast du meine Frage verstanden? Ich beschrieb ja, warum eine einfache media-query mit der Screenwidth nicht zum gewünschten Ergebnis führen kann. Im Übrigen ist solch eine Query zurzeit auf der Website aktiv und funktioniert. Sie liefert aber bei einem Smartphone im Querformat nicht das gewünschte Ergebnis.

Wenn meine Frage also so grundsätzlich unverstanden blieb, was soll da noch eine URL helfen? – Aber bitte, daran soll's nicht liegen:
Clemens' Psychotherapie Weinheim – Startseite

Ich arbeite mit Uikit bzw. YooTheme Pagebuilder. Auf meinen Websites habe ich mein Signet immer oben sichtbar (=sticky) bzw. in der uikit-Sprache = uk-sticky

Das Signet verändert seine Größe abhängig vom Viewport, weil ich seine Breite per CSS mit vw und max-width definiert habe. Das sieht elegant aus, ausgenommen bei der Darstellung im Smartphone-Querformat. Moderne Smartphones haben eine derartig große Pixelbreite, dass das Signet dann mehr als 1/3 der Bildschirmhöhe einnimmt.

Um das zu vermeiden, wurde versucht, das Signet erst ab 770 Pixel Breite sticky zu machen. Eine nur von Screenwidth abhängige Unterscheidung reicht aber bei den heutigen Smartphones nicht mehr aus: So hat mein Google Pixel 8 ein Display von 412 x 915 px bei Faktor 2,63.

Mein Ziel ist:

Es soll erkannt werden, ob die Website auf einem Smartphone im Querformat angezeigt wird. Wenn ja, soll mein Signet "nicht sticky" angezeigt werden. In allen anderen Fällen der Darstellung soll es am oberen Rand stehen bleiben während der sonstige Inhalt der Webseite scrollt.

Einen jQuery-Lösungsansatz habe ich, leider nur mit dem einzigen Unterscheidungskriterium Screenwidth. Aber diesen Script-Schnippsel könnte man evtl. erweitern, sodass die gewünschte Funktion erreicht wird?

    jQuery(function($) {
     $('.tm-header-mobile .uk-sticky').attr('uk-sticky','media: 770');
     });

tm-header-mobile repräsentiert das Signet. .uk-sticky ist die CSS-Klasse im UIkit, durch die das Element fixiert wird.

Bevor ich diese jQuery-Lösung eingebaut habe, hatte ich versucht, die Aufgabe per CSS media-query zu lösen und verwendete z.B.

@media only screen and (orientation: landscape) and (pointer: coarse)

Leider werden diese media-queries anscheinend von vielen Browsern nicht beachtet, speziell nicht von Mobil-Browsern. Wenn es funktionieren würde, wäre es ja Klasse und ich müsste dann nur den CSS-Code aus der Klasse uk-sticky als Definition hinein kopieren. – Script-Lösungen kann ich leider gar nicht selbst basteln, weil ich nix davon verstehe.

Mit welchen Lösungen habt Ihr gute Erfahrungen gemacht?

Oh ja, ich muss vorher auf den Tab "Overrides" gehen. Sie erstellen eine neue Struktur, in der ich dann die "com_user" finde.

Ich danke dir herzlich!

Gestern hatte ich erst eine meiner Sites abgesichert. Heute wollte ich bei den anderen die Absicherung nachholen. Nun stelle ich fest, dass es bei drei weiteren Sites weder im Cassiopeia-Template noch im YooTheme-Template ein Unterverzeichnis "com_users" gibt. Eine dieser Sites wurde gerade erst frisch installiert und kann daher wohl kaum kaputt gefrickelt worden sein.

Wie kann das sein? Wo liegt denn in solch einem Fall die "com_users"?

Mir ist es schwer gefallen, die zu ändernde default.php zu finden. Ich habe die default.php per Override nun gefüllt mit:

<html> <head> <meta http-equiv="refresh" content="0; URL=/"> </head> <body> </body> </html>

und der Test mit den beiden oben im Thread stehenden Links verlief positiv: Nach kurzem Flackern landete man wieder auf der Homepage.

Herzlichen Dank!

Andreas24 Genau deshalb habe ich die Zahl 22 genannt, weil dieses Forum ja öffentlich lesbar ist. Wer sagt denn, dass ich wirklich 22 Stellen verwende?

Und wenn doch, rechne mal aus, wie viele Kombinationen es aus zwei 22-stelligen "Wörtern" gibt (Admin-Name 22-stellig und Passwort 22-stellig) und dann noch das Handicap, dass nach drei oder wie viel vergeblichen Versuchen bereits die IP durch BruteForceStop gesperrt wird. Besonders in Verbindung mit diesem Handicap dürfte es unrealistisch sein, hier eine Gefahr zu vermuten.
Da würde ich eher die Sorge haben, dass doch mal eine LogIn-Komponente den eingegebenen Code nicht 100% zuverlässig prüft und der Hacker dann doch eindringen kann.

Jedenfalls bin ich jetzt wieder beruhigt. Diskussionen wie die in dem o.g. Thread component users ausschalten nützen wenig, bringen aber "den Aufreger des Tages".

Nachtrag:
Immerhin hat die GHSVS-Accordion-Lösung den Vorteil, dass ich mir auch den Wunsch nach h2-Tags (oder anderen) für die Accordion-Title-Items erfüllen kann, damit es sich positiv auf SEO auswirkt.
Dass sich ein Text eines beliebigen Accordion-Item ausklappt, wenn dieses Item über einen Link angesteuert wird, sehe ich allerdings bei der GHSVS-Accordion-Lösung nicht.

Aber ich danke euch für die Anregungen, um diese Aufgabe lösen zu können!

Ich habe mich versucht, durchzuwursteln mit den Override-Empfehlungen usw. bin aber nicht wirklich weiter gekommen damit. Eine dieser Änderungen führte gleich zum Ausfall der Website. Nicht lustig!.

Nachdem ich die Empfehlung von WM-Loose gelesen habe, bleibe ich doch jetzt bei dem, was ich schon habe: Das Kubik-Rubik-Intrusion System macht exakt das, was das kostenfreie Plugin Brute Force Stop auch macht. Und das funktioniert schon seit Joomla 1.x für mich zuverlässig.

Ich habe doch sowieso immer im Backend eine LogIn-Möglichkeit für den Admin. Ob ein Angreifer versucht, darüber ins System zu gelangen oder über das Frontend, ist doch völlig Wumpe. Hauptsache, er wird nach 2 oder 3 Versuchen zuverlässig ausgesperrt. Allerdings sperre ich das Backend sowieso mit einer htaccess.

Solange Joomla im LogIn-Plugin keine Sicherheitslücke reinbaut, bin ich auf der sicheren Seite: Der Admin-Name / Benutzername besteht bei mir aus einem 22-stelligen passwort-artigen Gebilde und das Passwort hat ebenfalls 22 Stellen.

Solange jetzt keine Gegenargumente kommen von Menschen, die mehr KnowHow haben als ich, lasse ich alles so, wie es jetzt ist.
Wie seht Ihr das?

flotte Meine Datenbank läuft nicht voll, weil ich BruteForceStop so eingestellt habe, dass die Anzahl versendeter Mails begrenzt ist und dass nach mehrmaligem Login-Versuch mit der gleichen IP-Adresse, diese gesperrt wird. BruteForceStop ist da schon ziemlich gut.

Um die Problematik, dass trotz deaktivierter Benutzer-PlugIns für das Frontend dennoch über solch einen Link ein Anmeldefenster gezeigt wird, muss ich mich noch kümmern. Gemäß des o.g. Threads component users ausschalten habe ich aber noch nicht gefunden, wo ich mit einem Override eingreifen müsste. Ich nutze kein Cassiopeia sondern YooTheme Pagebuilder und evtl. liegen die zu ändernden Dateien woanders.

Danke liebe Christine! $expandFirst deutet aber darauf hin, dass nur das erste Accordion Item expandiert gezeigt wird. Mir ging es darum, aus anderen Artikeln gezielt auf ein Item im Accordion verlinken zu können und dieses würde dann geöffnet gezeigt.

Erleichtert wird die Sache nur dadurch, dass YooTheme die Accordion Items nummeriert und der zum Titel gehörende Text eine um 1 höhere ID-Nummer erhält. Das Label aria-expand"="false" wird als default gesetzt, weil ich es so im Layout definiert habe. Man kann auch alle Items geöffnet anzeigen lassen, aber blöder Weise z.B. nicht, dass nur das erste geöffnet ist und die anderen nicht usw.

Im von dir zitierten Beispiel von GHSVS wird ein Accordion-Modul dazu verwendet, die Artikel einer Kategorie jeweils einem Accordion-Titel zuzuordnen. Bei Klick auf den Accordion Titel, der dann ja zugleich der Artikel-Titel ist, klappt es aus und zeigt den Text des Artikels an. Das ist sicher eine tolle Funktion, allerdings bei mir schlecht anwendbar, weil es zu einer wahren Flut von Artikeln kommen würde.

Und wie ich die GHSVS-Lösung irgendwie in die Accordion-Lösung von UIkit umwandeln könnte, sehe ich nicht.

Seit ca. 1 Woche bekomme ich vom Plugin BruteForceStop Versuche gemeldet, dass jemand versucht, sich über das Frontend einzuloggen. Dies geschieht bei zwei meiner Websites. Das wundert mich sehr, da jegliches Frontend-Einloggen deaktiviert ist. Als Template nutze ich YooTheme Pro, das auf dem UiKit aufbaut. Auch über YooTheme nutze ich kein Element, das ein Frontend-Login ermöglichen könnte.

Bei diesen Versuchen wird die reguläre Homepage-URL genutzt und BruteForceStop meldet dann:

Benutzername:  \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
IP-Adresse:    5.42.107.248
Zeitpunkt:     2024-11-15 07:42:11
Quelle:        Frontend

Ungewöhnlich ist auch, dass BruteForceStop kein Passwort meldet, das bei dem Versuch genutzt wurde.

Ich habe den gerade erst laufenden Beitrag component users ausschalten natürlich auch gelesen. Aber es gibt ja keinen Hinweis darauf, dass diese Komponente für die von mir beobachteten Versuche genutzt wurde. Zudem finde ich diese Komponente bei mir nicht, da ich YooThemePro benutze.

Frage: Besteht hier Handlungsbedarf? Wenn ja, wo sollte ich eingreifen?

Danke für deinen Tipp. Mal sehen, wie ich den konkret verwenden kann.

Ich würde ja gerne zu einem Accordion-Item mittels der ID springen. das geht auch, weil YooTheme jedem Accordion-Titel sowie dem zugehörigen Textbereich eine ID zuweist. Die kann ich aus dem HTML-Source heraus lesen und dann an die URL der Webseite anhängen, auf der das Accordion platziert ist. Leider sind alle Accordion-Items normaler Weise geschlossen. Damit der Benutzer etwas davon hat, genau dieses Item anzuspringen, sollte genau dieses Item aber geöffnet angezeigt werden.

Aktuell sieht der Titel eines Accordion-Item in HTML bei mir so aus:

<a class="el-title uk-accordion-title" href="" id="uk-accordion-15" role="button" aria-controls="uk-accordion-16" aria-expanded="false" aria-disabled="false">Text für den Titel eines Accordion-Item</a>

aria-expanded="false" ist entscheidend dafür, ob das Item ausgeklappt erscheint oder nicht. Es wird vermutlich durch Javascript oder PHP an dieser Stelle eingefügt.

Kann ich unter diesen Voraussetzungen den Link für das Anspringen eines Accordion-Items so gestalten, dass das Accordion-Item in geöffnetem Zustand gezeigt wird? Ich müsste also irgendwie aria-expanded="true" mit dem Link zusammen übergeben können.

Nach langer Suche im Support-Forum von YooTheme fand ich endlich auch eine Anleitung, wie ich die Icons zum Öffnen und Schließen der Accordion-Items austauschen kann. Und weil ich die Titel des Accordions farblich unterlegt habe, müssen diese sowie der nachfolgende Text links eingerückt werden.

Wer YooThemePro einsetzt, kann hier meine CSS-Ergänzung direkt übernehmen, wenn die nötigen SVG-Icons herunter geladen wurden: (z.B. hier: https://css.gg/icon/)

/* Titel und Text in Accordions links einrücken (nur wichtig, wenn Accordion-Titel eine Hintergrundfarbe bekommt.) */
.uk-accordion-title {
    padding-left: 0.6em;}
.uk-accordion-content .uk-panel {
    padding-left: 1.0em;}

/* Wahl verständlicherer Icons zum Aus- und Einklappen des Accordions */
@internal-accordion-icon-close-image: "/images/svg/zoom-in.svg";
@internal-accordion-icon-open-image: "/images/svg/zoom-out.svg";

Vielen dank für deinen wertvollen Hinweis! ich habe auf mehrere Seiten Accordion verwendet. Bei manchen habe ich wohl den Hinweistext vergessen. Beim Datenschutz ist er drin.

Schade! – Ich muss mich wohl damit abfinden. Bei Elementor / WordPress hat man wohl eine Lösung dafür gefunden. Und ich bin nicht der Einzige, der sich so etwas bei UIkit wünscht. Ohne JS und Eingriff in den YooThemeCode ist wohl nix zu machen.

Danke dir für deine Antwort!

Herzlichen Dank!

Im Zuge der SEO-Optimierung meiner mit YooThemePro erstellten Website stellte ich fest, dass die Accordion-Titel nicht als CSS-Überschriften gekennzeichnet sind. Laut Support von YooTheme wäre dies eventuell nur mit einem weiteren kostenpflichtigen PlugIn eines anderen Anbieters realisierbar was wieder 30 Euro kosten soll. Ich finde das nicht lustig, wenn ich schon rund 130 Euro für YooThemePro investiert habe!

Über die Browserkonsole fand ich heraus, dass innerhalb eines Accordions alle Titel mit einer nummerierten ID daher kommen, wie z.B. id="uk-accordion-3". Die Nummerierung ist jedoch nicht fortlaufend. Nun versuche ich, in meiner custom.css folgende CSS-Regel einzubauen:

Immer wenn eine ID mit der Bezeichnung "uk-accordion-*" innerhalb der Klasse "uk-accordion-title" verwendet wird, soll der als Titel folgende Textinhalt mit "h2" ausgezeichnet werden und diese Auszeichnung soll natürlich so im HTML-Source wieder zu finden sein, damit Suchmaschinen dies als h2-Titel identifizieren können. Dieses "h2" müsste auch mit "!important" eingefügt werden, damit es nicht durch andere Definitionen überschrieben wird.

Meine CSS-Kenntnisse reichen leider – auch unter zu Hilfenahme der w3school nicht aus, um diese CSS-Regel korrekt zu erstellen. Es mag aber auch sein, dass das mit bloßem CSS gar nicht realisierbar ist.

Falls es realisierbar ist, bitte ich hier einen CSS-Kenner darum, mir diese CSS-Regel zu erstellen!