Beiträge von Clemens-XS

Danke dir! Das war das i-Tüpfele für die ganz großen Displays.

Wow! Herzlichen Dank dir! Dass der stets von Joomla übergeordnete Container "blog" heißt, wusste ich nicht.

Für den geöffneten also komplett angezeigten Artikel heißt entsprechend der übergeordnete Container ".item-page" Damit konnte ich den unerwünschten Link auch bei geöffnetem Artikel ausblenden.

Alles prima jetzt! Vielen Dank!

Auf meiner neuen Website (ist auf XAMPP in Entwicklung, daher leider kein Link), zeige ich meine Artikel / Beiträge entweder in einem Modul von RokSprocket, sodass der Artikel in einem div container von RokSprocket angezeigt wird. Oder ich zeige den Artikel / Beitrag ganz normal über Joomla Blog-Ansicht mit Intro-Text und auf Klick "mehr anzeigen" eben die ganze Länge.

Der Besucher hat beide Möglichkeiten der Beitragsansicht, je nachdem, ob er über das Menü kommt oder die Webseite mit dem RokSprocket-Modul aufruft.

Was ich erreichen möchte ist, dass ein Link im Introtext nur dann angezeigt werden soll, wenn der Artikel im Modul von RokSprocket gezeigt wird und dass der Link ausgeblendet wird (display: none;), wenner als „ganz normaler Artikel” in der Joomla-/Template-Umgebung angezeigt wird.

Wie könnte ich das rein mit CSS-Mitteln verwirklichen, also ohne JS zu bemühen?

In meinem CSS stckte doch noch ein Bug betr. @media min-width und @media max-width. Deshalb jetzt noch mal meine jetzt vorgenommene Unterteilung als CSS in vollem Umfang, damit andere es ggfs. einfach kopieren können:

Die Übergänge und Relationen zwischen den Prozentsätzen und den Pixelwerten in den @media-Queries habe ich durch Ausprobieren gefunden mit dem Ziel, dass die Sprünge in der Bildgröße zwischen zwei Media-Breiten nicht so extrem ausfallen.

Bitte den vorigen Post ignorieren! Ich habe per copy n paste ins falsche Thema geschrieben. Sorry!

Vielen Dank dir! Die von mir im vorigen Post gezeigte Lösung entspricht genau deinem zweiten Link. Und wenn ich die Prozentzahlen in Verbindung mit der Media-Query geschickt wähle, erreiche ich zugleich als „Nebenwirkung”, dass der Textbereich neben dem Bild nie unsinnig schmal wird, oder aber dass rechtzeitig, bevor er endgültig zu schmal würde, die Eigenschaft "float-left" rausgenommen wird.

Herzlichen Dank für deine Unterstützung! Ohne die hätte ich wahrscheinlich noch lange herumprobiert.

Hab weiter versucht, aber dieses Mal unter der Annahme, dass sich der Prozentsatz der KLasse ".cl-art-img" nicht auf das Maß des Bildes bezieht, sondern immer auf die Gesamtbreite des darüber liegenden Container. Dieses kann der Container des Artikels sein, den das Template bereit stellt oder auch (wie bei mir im zweiten Anwendungsfall) die Showcase-Definitionen des Modul RokSprocket.

Mit den folgenden CSS-Definitionen komme ich dem schon nahe, was ich ursprünglich visuell erreichen wollte:

Der Haupt-Unterschied besteht darin, dass die Prozentzahl KLEINER wird, je GRÖßER die Breite in der @media-Regel ist. Das hatzte ich bei den bisherigen Versuchen umgekehrt gehalten. Genau dies war die Ursache für die bisherigen Fehlversuche.

Vielen Dank für deine Geduld mit meinen Wissenslücken und deine schnelle Antwort!

Ich hab gerade das ausprobiert, was du vorgeschlagen hast und Varianten davon – leider ohne den gewünschten Erfolg, wie die angehängten Screenshots zeigen.

Zunächst habe ich in der CSS-Datei das img-Tag mit width 100%; height: auto; definiert. Im HTML der Artikel habe ich in den Aufruf eines Bildes keine weitere Klasse eingefügt, also <img src=....jpg"/>

Dem Bild-Aufruf habe ich vorangestellt: <div class="cl-art-img">

Dann habe ich drei verschiedene @media-Definitionen für die Klasse definiert, sodass die CSS so aussieht:

Die Border-Definitionen habe ich eingefügt, um im Browser sehen zu können, ob und wie sich die @media-Regeln auswirken. Dies sieht man in den drei Screenshots "A-Versuch_...."

Dann habe ich die @media-Regeln vereinfacht auf eine einzige, damit das Ganze übersichtlicher und evtl. verständlicher wird:

Das Ergebnis ist in den drei Screenshots "B-Versuch_..." zu sehen. Die gewünschte Skalierung entsteht nicht durch die @media-Regel, sondern durch die Begrenzung durch den Viewport!

Und es ist sichtbar, dass sich der Prozentsatz in der Defintion der Klasse ".cl-art-img" auf den gesamten verfügbaren Platz des übergeordneten Containers bezieht während das Bild nicht skaliert, solange der verfügbare Raum der View-Breite ausreicht.

Keine Ahnung, wie das nun weiter gehen kann. Im Firefox-Inspector habe ich nicht erkennen können, dass mir hier eine CSS-Vererbung einen Streich spielt. Ich fand aber Definitionen wie z.B. ".mobile_showcase img". Vermutlich gilt diese Definition für das img nur dann, wenn das img in Verbindung mit der KLasse ".mobile_showcase"?

Vielleicht sollte ich meine img-Definition an meine zugehörige Klasse ".cl-art-img" binden, um übergeordnete / vererbte Einfüsse auf das img-Tag auszuschließen?

Genau das habe ich gerade versucht. Ich habe für die Bilder z.B. definiert:

und das Ergebnis ist, dass das Bild nun so breit wird, wie der Viewport bzw. ein darüber liegender Container eines Modul usw.

Die Prozentsätze beziehen sich also immer auf die maximal jeweils verfügbare Breite und nicht auf die Bildbreite.

Eingefügt habe ich im HTML: <img class="cl-art-img" src="images/....jpg">

Was mache ich falsch?

Vielen Dank! Ich stand wohl „auf der Leitung” und hab es unnötig verkompliziert....

Es funktioniert jetzt wie gewünscht, gilt aber nun leider für alle Bilder auf der Website, was wiederum unerwünscht ist. Es soll ja nur für diejenigen Bilder gelten, die in einer bestimmten Gruppe von Artikeln sind.

Ich habe mal um das Bild einen div-Container herum gemacht. Pech: Das Bild skaliert zwar, aber der Container bleibt immer so breit, wie das nicht skalierte Bild, während sich die Höhe des Containers der neuen Bildhöhe anpasst.

Es ist wohl ein ziemlicher Unterschied, ob ich auf die Vererbung setze und das Bild in einen div Container platziere oder ob ich eine zuvor definierte Klasse mit in das img-Tag einbaue, al la <img class="clemens-img" src:....>

Mich stört nichts an Media-Queries, sondern der Aufwand, alle Bilder in zwei bis drei Auflösungen zu erstellen. Mit max-width hatte ich noch nicht probiert, würde aber weiterhin mehrere Bilder erforderlich machen.

Da ich auch mit LazyLoading arbeite, kann ich es mir leisten, auch höher aufgelöste Bilder, als für den Viewport nötig, auszuliefern, wenn sie sich denn nur passend skalieren würden! Damit meine ich im Idealfall das Verhalten eines Bildes, das allein im Viewport steht und sich bei Verschmälerung der Breite automatisch in Breite und Höhe anpasst. Genau diese Anpassung eines Bildes wünsche ich mir, jedoch sollte sie in dem eingangs beschriebenen Zusammenhang erfolgen: z.B. ab einer Mediabreite unterhalb von 900px soll das Bild bei weiter sich verringernder Mediabreite proportional immer kleiner werden bis hin zu einer CSS-definierbaren min-width des Bildes.

Die Experimentier-Website ist zurzeit auf einer XAMPP-Installation, daher aktuell kein Link verfügbar.

Eigentlich… ja eigentlich müsste es ganz einfach sein:

Ich erstelle einen Artikel in Joomla, der links oben mit einem Bild beginnt, also top: 0px; left: 0px; und float: left; hat. Der Text fließt also rechts am Bild entlang und je nach Textlänge auch unterhalb des Bild weiter. Damit der Text Abstand vom Bild hat, erhält das Bild nach rechts und unten einen margin zugewiesen.

Nun möchte ich mir die Mühe sparen, für jedes Bild zwei oder sogar drei Auflösungsvarianten bereit zu stellen und diese abhängig von der Breite des Viewport durch zwei bis drei @media -Abfrage einzubinden. Ich fand nach einiger Suche im Web die Möglichkeit für Bilder "transform: scale(0.5, 0.5); zu nutzen. Das wäre eine äußerst elegante Lösung.

Resultat ist aber, dass der Platz für die ursprüngliche Bildgröße reserviert bleibt und das Bild in diesem reservierten Bereich zentriert und mit dem vorgegebenen Maßstab verkleinert erscheint. Was ich brauche, ist aber, dass das Bild weiterhin links oben in der Ecke beginnt.

Also hab ich das Bild mitsamt seiner Skalierungs-Definition in einen Div-Container gepackt und dessen Position auf top: 0px; und left 0px; gesetzt. Hat aber auch nix gebracht.

Frage: Gibt es eine Lösung mit "transform: scale(…)" oder bleibt es mir nicht erspart, zwei bis drei Bildvarianten bereit zu stellen?

Re:Later :

Pech, es klappt doch noch nicht ganz: Wenn ich scrolle, bis das nächste Bild erscheinen sollte, geschieht zunächst nichts und das erwartete Bild erscheint nicht. Beginne ich dann erneut zu scrollen, brauche ich nur wenige Pixel Bewegung und schwupp ist das vermisste Bild zu sehen.

Dieser Fehler ist jederzeit reproduzierbar. Der Cache von Joomla und der des Server (htaccess) sind deaktiviert und der Cache des Browsers ebenfalls. Von daher habe ich also keine Verfälschungen.

Ist ein Bild einmal angezeigt worden, so bleibt es anscheinend eine Zeit lang ohne LazyLoad verfügbar, wenn ich hin- und her scrolle. Ist diese Zeit abgelaufen, wirkt das PlugIn wieder und der oben beschriebene Effekt tritt wieder auf.

Da du dieses PlugIn anscheinend gut kennst, könnte es ja sein, dass dir dieses Verhalten bekannt ist und evtl. auch eine Abhilfe dazu?

Nun ja, ich gestatte mir den Luxus, es in diesen Dingen genauer zu nehmen. Das bringt schon mein Beruf mit sich (nur noch Linux und Win7 nur noch in VMs, alle DSGVO-Daten auf verschlüsselten Platten usw. usf.

Bin dann mal gespannt auf Joomla 4.

Schau mal:

https://www.privacy-handbuch.d…/privacy-handbuch_win.pdf

https://www.heise.de/ct/downlo…/3/0/1/9/0/5/firefox2.pdf

https://www.kuketz-blog.de/empfehlungsecke/

https://www.kuketz-blog.de/fir…firefox-kompendium-teil3/

https://julia-vicentini.de/blo…-fuer-die-htaccess-datei/

https://webbkoll.dataskydd.net/de

OK, ich hab's noch mal überprüft und Einträge in der php.ini vorgenommen.

Betr. Apache2Handler kann ich aber nix machen bzw. sehe keine Möglichkeit, etwas zu ändern.

Hab deine Links beachtet.

Eigener Eintrag in PHP.ini ist nun:

upload_max_filesize = 500M

post_max_size = 500M

memory_limit = 512M

max_execution_time = 120

max_input_time = 100

Jetzt OK?

So, hab's ausprobiert. Es funktioniert hervorragend und auch bei allen Inhalten, die von RokSprocket gezeigt werden. Mit dem Firefox-Inspector und der Netzwerkanalyse kann man sehr schön sehen, wenn ein Bild in den Viewport kommt und geladen wird – und das auch noch mit einem Fade-In-Effket von jQuery.

Wenn die Site veröffentlicht wird, bekommt Herr Vogel eine Spende von mir! Klasse PlugIn!

Herzlichen Dank an Later und GHSVS für den guten Tipp!

Ich schrieb ja, dass die neueste Version (Pro) kostenpflichtig ist. Und ja, es gibt das anscheinend ältere PlugIn weiterhin kostenfrei. Und ich schrieb auch, dass ich mir das gerade herunter geladen habe, um es auszuprobieren. OK?

Gerade stelle ich fest, dass die Unsitte, Code von CDNs oder Google-Fonts sowie JQuery usw. während des Seitenaufbaus nachzuladen, auch in Templates und Extensions um sich greift!

Ist denn nicht mittlerweile bekannt, dass die Besucher der Website bei jedem Seitenaufruf ihre IP-Adresse und evtl. auch weitere personenbezogenen Daten an irgend welche Server weiter leiten, die meist im Ausland stehen? Ist nicht bekannt, in welch gigantischem Ausmaß Google sein Spionagenetz immer trickreicher auslegt, indem z.B. Webfonts von dort eingebunden werden, dafür natürlich aber die Daten der Besucher abgezogen werden?

Also entweder nehmen wir die DSGVO und darüber hinaus bereits beim Erstellen einer Website ernst und verzichten auf das Nachladen (das ja auch ein Sicherheitsrisiko darstellt, weil alle zentral vorgehaltenen Daten ein attraktives Angriffsziel für Hacker sind) oder…???

Ich habe bisher alle meine Joomla-Sites ohne in Templates oder Erweiterungen eingreifen zu müssen, so gestalten können, dass von keinem einzigen CDN oder Google oder anderen Quellen Code nachgeladen wurde und konnte nur deshalb in meiner htaccess die Sicherheitsmerkmale Header set Content-Security-Policy und Header set X-Frame-Options "SAMEORIGIN" verwenden.

Jetzt aber wird das immer aufwendiger, da ich nicht nur CSS-Code und JS-Code, sondern nun auch noch die PHP-Dateien durchsuchen muss, wo denn die URLs zum Nachladen versteckt sind. Und manchmal funktioniert danach nix mehr richtig!

Es müsste im Backend bei den Erweiterungen und Templates einfach eine Möglichkeit vorgesehen sein, dass man das Nachladen komplett deaktivieren kann, ohne einen Funktionsverlust zu bekommen. Scripte usw. kann man ja auch manuell bei Erstellung der Site herunter laden und in der Site-Installation zentral speichern.

Vielen Dank für deine Erklärungen! Leider komme ich da mangels Fachkenntnissen nicht mit. Wenn du die Funktionsweise des von mir ganz oben zitierten Script analysieren willst, kann ich nur auf den zweiten Link verweisen, den ich im zweiten Beitrag angegeben hatte:

https://www.robinosborne.co.uk…-dont-rely-on-javascript/

Der Autor erklärt dort recht genau, wie sein Script arbeitet. Und ich kann das nur entweder glauben oder sein lassen.

Natürlich habe ich derzeit damit experimentiert, die umständlichen src und data-src Aufrufe im Editor in das HTML des Artikel einzufügen und musste dazu auch die HTML-Prüfung des JCE-Editor deaktivieren. Und ich habe mich dabei genau an die Vorlage gemäß des o.g. Autors gehalten.

Nun sagte "Later", dass die Verwendung von LazyLoad-Scripten innerhalb von Bildern in einer Slide-ähnlichen Anwendung evtl. nicht funktionieren könnte, weil die Bilder bereits "fertig geladen" hinein gelangen. (So hab ich's jedenfalls verstanden.)

Nutze ich eine Erweiterung, wie das empfohlene PlugIn von KubikRubik, so könnte dies evtl. dies ja gerade dieser Problematik unterliegen, wohingegen ich im HTML des Artikels selbst (also sozusagen am Ursprung) den entscheidenden Code (src / lazy / data-src) eingefügt habe.

Ich werde dennoch jetzt mal RubikKubik ausprobieren. 100 EUR Jahresbeitrag für die neueste Version sind mir aber reichlich viel, denn weitere Extensions von ihm benötige ich wohl nicht.