Beiträge von Re:Later

Glücklicherweise habe ich das vor dem Online-Gang noch mal auf vielen Browsern getestet.

Firefox zeigt ausnahmslos alle webp korrekt an, die in srcsets responsiv und mit loading=lazy hinterlegt sind.

Safari brav das Fallback-Bild.

Schrägerweise: Alle auf Chromium basierenden Browser (Vivaldi, Chrome, Edge, Opera) haben konstant Probleme und zeigen viele Bilder nicht an.

Selbst Bilder aus der selben Quelldatei in verschiedene webp-Größen konvertiert, werden teils angezeigt, teils nicht. Bei anderen Quelldateien werden dann wieder alle Größen angezeigt. Für mich ist keine Logik zu erkennen.

Kurz: Außer mit Firefox pure Lotterie.

Schade um 50% der damit verbrachten Zeit.

Zitat von Re:Later

Trotzdem lasse ich das jetzt in meinem Plugin drinnen, allerdings mit einem Häkchenfeld zum Deaktivieren

Häkchen geklickt und good-bye....

Wenn ein unentgeltlich arbeitender Dilettant, der glaubt, er sei superqualifiziert, weil er sich irgendwo Halbwissen angelesen hat oder schlechte Youtube-Videos angeschaut hat, meint, Punkte des #18 schriftlich, vertraglich festhalten zu müssen, schießt er sich in's eigene Knie. Selbst eine Zeitdauer muss man als Freiwilliger nicht angeben und sollte das auch nicht in einem Vertragswerk, weil die Kinder oder eigene Gesundheit von einem Tag auf den anderen wichtiger sein könnten.

Auf der anderen Seite sollten ""Dilettanten"" durch irgendwelche verquasten, angstmachenden Horror-Szenarien nicht davon abgehalten werden, ehrenamtlich tätig zu werden, um Erfahrungen zu sammeln und besser zu werden. Ein Unerfahrener sollte sich aber in keinem Fall aufgefordert sehen, sich zu weit aus dem Fenster zu lehnen, weil hier irgendein Qualifikations-Punktekatalog verbreitet wird, der zu berücksichtigen sei, mit Fachworten, die ich zu 1/3 als Autodidakt nicht verstehe.

Ein Unerfahrener sollte einfach ehrlich bleiben...

Der Titel und Inhalt des Threads sollte also klar machen, dass hier Profis diskutieren, ob sie sich auch bei ehrenamtlichen/unentgeltlichen Tätigkeiten irgendwie bis ins feinste Detail absichern sollten. Profis widerum sollten aber schlichtweg zum Rechtsanwalt gehen, wenn sie unsicher sind, da sie das von der Steuer absetzen können.

Ich persönlich mache einfach oder mache nicht (mehr) und kündige mein Ausscheiden frühzeitig an, z.B. wenn sich der Seiteninhaber als größeres menschliches Aloch herausstellt als ich es bin... Das beinhaltet der Begriff "Freiwilligkeit".

Ich bleibe beim Beispiel Fahrrad. Kein Unterschied. Wenn ich die Glühbirne versehentlich kaputt mache, ist der schuld, der mit dem Fahrrad fährt. Habe ich sie geklaut, ist immer noch der schuld, der damit fährt, aber er kann auf normalem Rechtsweg versuchen, mich irgendwie zum Zahlen zu bewegen, wenn er dadurch Schaden hatte. Man kann natürlich einen Glühbirnen-Quatschvertrag machen, in dem steht, dass geltendes Recht gilt.

Blick hier echt nicht mehr durch. Du leitest ein mit "freiwillig", "ehrenamtlich", "unbezahlt" und willst dann komplexe Vertragswerke aufsetzen, entwerfen, um dich vor irgendwas zu schützen.

Das Gegenteil wirst du erreichen!!!!!!!!

Wozu das? Du hast als Privatperson eine Sorgfaltspflicht, wenn du dem Nachbarn anbietest, sein Fahrrad zu reparieren und zu ölen. Wenn du mit dem Vorschlaghammer reparierst, weil er dir seinen kleinen nicht leihen will, bist selber Schuld, wenn du das trotzdem machst. Wenn er dir den kleinen nicht leihen will, reparierst es eben nicht und gut ist's. Tschüss. Geölt hast du es ja. Wenn es geklaut wird, weil du es nicht abgesperrt hast, bist du zumindest moralisch verpflichtet, es ihm zu ersetzen.

Ich bin doch nicht blöde und garantiere dem Nachbarn vorab schriftlich irgendwelche Qualifikationen bzgl. Bewertung von Öl-Qualitäten. Will er ein besonderes, soll er kaufen gehen, sonst ist es halt das Öko-Nämaschinen-Öl, das ich noch im Regal stehen habe, was ich auch für mein Rad nehmen würde. Wenn das nach einem Jahr verharzt, war Nachbar selber Schuld, wenn er dich nicht gefragt hat, welches du nimmst.

Bei einer Webseite macht man Sicherungen, hebt sie auf, spielt die Seite zurück, wenn man sie kaputt gemacht hat und legt ggf. sein Ehrenamt in diesem Bereich nieder und gut ist's. Kann man eine Webseite nicht restaurieren, die man kaputt gemacht hat, sollte man so Job einfach nicht übernehmen. Da macht eine Garantie, dass man es kann, die Sache nur noch heikler. Als Ehrenmann ist es mir klar, dass ich den Dienstleister, der bei Repraratur hilft aus eigener Tasche zahle. Genauso wie beim Fahrrad,

Ein Hinweis auf "stets sorgfältiges und vertrauliches Arbeiten nach bestem Wissen und Gewissen" kann nicht schaden.

Und was geht dich die DSGVO-konfomität der Seite an, wenn nicht gerade du der I-diot bist, der die beeinflusst/verändert? Das sind Dinge, in die man sich nicht einmischt abgesehen von Bin-kein-Rechtsanwalt-aber-denke-das-ist-ungut-Hinweisen. die man sich ebenfalls aufhebt...

Oder anders: Was sind denn das für "schräge Leute", für die du da kostenfrei arbeiten willst? Fang ich doch gar nicht erst an...

Das hängt davon ab, welchen Weg die Daten gehen. Alles sollte UTF-8 sein, also auch die verarbeitenden PHP-Dateien und ein HTML-meta-charset ist nicht unbedingt Gewähr dafür, dass der Server selbst keinen Quatsch macht.

Kurz: Wir wissen zu wenig über deinen Code und Umgebung etc.

Zur HelloWorld gibt es Schrittweise-Dokumentationen im Netz.

Ja, einige, wenn auch nicht alle Dateien benötigt eine ordentlich installierbare und ohne extrem großen Aufwand umzuprogrammierende Komponente schon. Die Hello-World, aber auch ein paar von den in Joomla installierten Komponenten zeigen den grundlegenden Aufbau (com_contact, com_banner), der den Vorteil hat, dass einem Joomla selbst zahlreiche Funktionen "automatisch" zur Verfügung stellt, ohne, dass man die dann auch noch selbst programmieren muss.

Es gibt auch so was hier: https://www.joomlacomponentbuilder.com/

Das ist eine Joomla-Komponente mit der man eigene Komponenten bauen kann.

Aber auch da braucht man etwas, entgegen der Jubelversprechungen dort, Skills. Ganz ohne Einarbeitung, v.a. in die Zusammenhänge und 1 bis x Wochen Trial&Error kommst nicht ans Ziel.

Zitat von Re:Later

Bei dem, was ich ingesamt rauslese, empfehle ich dir, das Helferlein-Plugin JQueryEasy zu verwenden und so einzustellen, dass JQuery aus dem "Framework" geladen wird, da wir deinen Gesamt-Code nicht kennen. Irgendwo hast einen größeren Fehler drinnen bzgl. Ladereihenfolgen der Skripte.

owlCarousel gibt es ja einige Erweiterungen, die das verwenden. Oder man bindet es selbst ein.

Die Ladereihenfolge muss in diesem Fall sein:

1. JQuery (einmalig für die gesamte Seite).

2. owlCarousel- Datei, die die Grundfunktion definiert

3. 1 oder mehrere owlCarousel-Init-Script(e), die in den meisten Fällen direkt im HTML-Seitenquelltext eingesetzt ist/sind.

So verhält es sich mit allen JQuery-abhängigen Skripten.

Ein Fehler wie deiner oben, führt dazu, dass nachfolgendes JavaScript, egal, ob das nun irgendwie Teil/Ursache des Hauptfehlers ist, nicht mehr ausgeführt wird.

Heutztage kann es auch Restriktionen, bspw. HTTP-Header-Regeln auf dem Server, die es nicht mehr erlauben, Javascript irgendwo "reinzuhauen".

Auf https versus http hat dich christine2 ja zusätzlich hingewiesen.

Ein Mehrfacheinbinden von JQuery führt in den allermeisten Fällen zu gravierenden Fehlern und ist zusätzlich (spätestens) heutzutage absolutes NoGo, da die JQuery-Bibliothek recht groß ist. Wenn ich in deinem falschen Link oben auch noch /kunde/ lese, hoffe ich, dass du das nicht wirklich für einen Kunden machst, der für deine Arbeit bezahlen soll

Zu 00000. Prüfe mal, was in der Konfiguration unter Datenbank > Typ eingestellt ist. Das sollte MySQLi sein, nicht was mit PDO.

Zur

.htaccess

Apache ist ja jetzt bestätigt.

Bist sicher, dass du die im Joomla-Stammverzeichnis liegen hast und tatsächlich mit einem Punkt vorne dran?

Und in der Konfiguration eingestellt hast:

- Suchmaschinen-freundliche URL: JA

- URL-Rewrite nutzen: JA

Und, dass es die originale htaccess ist. Sie sollte INHALTLICH für's erste so aussehen: https://github.com/joomla/joom…blob/staging/htaccess.txt

Das kann man über den Sprachstring machen

ein Modul Banner hat in der XML

<name>mod_banners</name>

In der Spachdatei en-GB.mod_banners.sys.ini

MOD_BANNERS="Banners"

Das ist der angezeigte Text im Feld "Typ".

Wichtig ist nur, dass unterschiedliche Module-Erweiterungen unterschiedliche <name>-Einträge brauchen.

Wie man sie dann per Sprachdateien übersetzt, ist egal.

Aufpassen muss man etwas, dass die .sys.ini und .ini an unterschiedlichen Stellen zum Einsatz kommen. Ggf. muss man also alle aller Sprachen anpassen. Das ist ein Nachteil, kann aber auch ein Vorteil sein, wenn man z.B. je nach Situation unterschiedliche Beschreibungen (MOD_BANNERS_XML_DESCRIPTION) anzeigen möchte. Das ist dann unter Erweiterungen > Verwalten beim "Hovern" über den Titel ggf. eine andere als in der Modulauswahl. Etwas verwirrlich, manchmal

Weswegen ich so was wie MOD_BANNERS_XML_DESCRIPTION immer nur in einer der beiden Sprachdateien Dateien habe. Frag mich nicht, welche. Weiß nicht auswendig. Und weiß auch nicht, ob das für <name> (Typ) auch möglich ist...

EDIT: Mit Sprach-Overrides kann man also auch den Typ anderer Module updatesicher anpassen.

Joomla hat dafür die Komponente com_ajax fertig dabei. Mit der kann man dann via Ajax-url

index.php?option=com_ajax ...

1) ins Framework eintauchen (JEXEC-Problem gelöst) und

2) Plugins bzw. Module zur Ausführung des Codes verwenden.

Das ist hier etwas (veraltet, aber grundlegend noch aktuell) zu lesen plus Links auf Demo-Plugin und Demo-Modul.

https://github.com/Joomla-Ajax-Interface/component

Auch in den docs.joomla.org gibt es eine Dokumentation so weit ich mich erinnere.

addStyleSheet übergibt man einen Pfad zu einer CSS-Datei.

addStyleDeclaration() übergibt man CSS-Code

Beachten muss man, dass natürlich ohne <style>-Tags

Factory::getDocument()->addStyleDeclaration(
    '.subform-table-sublayout-section .controls { margin-left: 0px }'
);

Heutzutage empfohlen NICHT mit <script>-Tags einbinden, sondern den gebastelten Code in den HEAD schicken, z.B. mit.

Factory::getDocument()->addScriptDeclaration(...)

Das selbe gilt für <style>-Tags

Factory::getDocument()->addStyleDeclaration(...)

Bei Joomla 4 kann man auch an's Ende vom BODY schicken. Siehe Beispiel Atum-Backend-Template am Ende der Datei index.php.

Zitat von Shor-ty

wieso die php Dateien nicht mit einem ?> enden?

Es ist sogar empfohlen, dass sie das nicht tuen, wenn die letzte Zeile PHP ist.

1) Die Ausgabe enthält dann nicht diverse, unnötige oder sogar ggf. (zer)störende Leerzeilen/zeichen, wenn die Datei bspw. HTML-Ausgabe erzeugt.

2) Es kann nicht dazu führen, dass der berüchtigte "headers already sent"-Fehler auftritt. Die Leerzeichen könnten als "Schon was ausgegeben" interpretiert werden und das Setzen eines Headers (header()) danach führt dann zu der Fehlerausgabe.

Und für mein erstes Joomla-4-Modul hatte ich das mod_banners als Vorlage genommen beim Umschreiben eines alten Joomla 3. Da ist dann auch schon so Namespace-Kram drinnen (in diesem Fall für den Helper in Ordner /src/), was man in der XML-Datei definiert (<namespace). Dann hat man das schon mal gesehen, wenn man's sehen mag

Danke! Super Hinweis, das mit dem PageSpeed. Frage ist, ob man tatsächlich weiß, dass es da um Geschwindigkeit bzgl. Seitenladung geht oder, ob das nicht ein "Hast-du-brav-gemacht-kleiner-Racker"-Bonus-Punkt ist. Manchmal habe ich bei dem PageSpeed-Tool den Eindruck, dass es nicht immer wirklich um "echten" Speed-Gewinn gehen könnte, aber große ??????

Ja, das Fallbackgebastel ist nervtötend, selbst, wenn man es dann final dynamisch aus JLayouts oder so lädt. Noch dazu, wenn man ja schon fertig war mit seiner "genialen" Plugin-Logik, die nie mit je 2 Bildern gerechnet hat Jedenfalls ekelhaftes HTML, was rauskommt...

Mindestens 1 Demo ist ja in von christine2 verlinktem Thread ja genannt. https://demo.corejoomla.com/surveys.html

Leider sind Klassen wie "mb-lg", "mt-md", "center" keine allgemein üblichen/bekannten. Ebenso sind Klassen wie "col-md-2" abhängig vom verwendeten CSS-System (flex, grid oder float).

Du wirst also wohl einen Link zeigen müssen, auch damit wir sehen, was für ein CSS-System überhaupt verwendet wird.

WebP ist ein Bilderformat, also so was wie JPG, PNG oder GIF, von dem Google behauptet(e) es sei sooooo viel besser, was Bilder-Optimierungen für das Web anbelangt. Also "verkleinern" des Speicher- und Ladebedarfs von Bilder im Internet. Ist ja schließlich eine Entwicklung aus dem Hause G. Muss besser sein.

Eh klar, dass dann aus diversen (Teils-Pseudo-)SEO-Ecken nach WEBP-Unterstützung geblöckt wird.

Also begab ich mich mal in die Herde:

Nach 3 Tagen testen unter realen Joomla-Verhältnissen mit einem meiner Joomla-Plugins, das auch für Bildoptimierung zuständig ist, sehe ich die pauschal versprochenen Effekte (25-30% Bildgrößenreduzierung im Vergleich zu z.B. JPG) NICHT.

Es ergaben sich WEBP-Bilder (aus einem großen JPG-, PNG-, GIF-Mischmasch einer Live-Seite),

- die sind etwas kleiner,

- andere sind größer,

- andere sind gleich

(bezogen auf die Speichergröße in kB).

Generell: Sehr große Bilder (> 1200px), kaum positive Effekte.

Einziges Format, wo ich sage "generell OK" sind PNG-Bilder im Fireworks-Format, die mir aber sowieso nur versehentlich auf den Server gelangen. Die habe ich aber auch nicht verglichen mit Umwandlungen nach JPG.

Dabei habe ich von allen Bildern 5 verschiedene Größen generieren lassen, jeweils im Originalformat sowie im WEBP-Format.

Nicht konstant der Fall, aber einige WEBP-Bilder sind erheblich verpixelter als die Pendants selber Größe. Umgekehrt ist das aber nicht der Fall.

Im Durchschnitt, bezogen auf Gesamtlade-Volumen einer Joomla-Blog-Seite mit vielen Einleitungsbildern, kann man nur milde lächeln über den dollen Effekt.

Einschränkend muss man (vielleicht) dazu sagen, dass ich natürlich bei meinen Versuchen bei einem 0815-Provider auf PHP-Bibliotheken angewiesen bin, die auf dem Server installiert sind. Also ein Versuch "unter realen Joomla-Verhältnissen" eines normalen Benutzers.

Es blieb nur GD, da IMAGEMAGICK bei dem Provider keine WEBP-Unterstützung bietet. Weiß aber auch nicht, ob das unterm Strich Unterschiede macht.

Als "ausführende Instanz" habe ich die PHP-Bibliothek http://image.intervention.io/getting_started/formats verwendet. Ein Hoch übrigens auf diese Bibliothek, nur nebenbei gesagt. Man lobt ja zu selten...

Weiteres Kriterium: Da nicht alle Browser WEBP unterstützen (derzeit z.B. Safari), muss man natürlich Fallbacks auf z.B. JPG-Bilder anbieten:

1) Ca. doppelter Speicherbedarf im Webspace für optimierte Bilder.

2) Mehr HTML-Code der ausgelieferten Webseite, da ja jedes Bild für den Fallback mehr davon braucht.

3) WEBP ist ein Format, das meine (zugegeben altertümlichen) Bilder-Anschau-und-Durchblätter-Programme nicht unterstützen.

Kurz: Der innere Zwang, dass man jetzt unbedingt WEBP-Bilder verwenden muss, weil Google was verspricht, ist bei der einen oder anderen Seite vielleicht angebracht, ein generelles Allheilmittel ist das aber nicht und man sollte Leuten misstrauen, die das bspw. im Zusammenhang mit SEO blind bejubeln.

Trotzdem lasse ich das jetzt in meinem Plugin drinnen, allerdings mit einem Häkchenfeld zum Deaktivieren Bis dann irgendwann mal MozJPEG (libjpeg-turbo) unter PHP zu neuen Tests einlädt

Zitat von IceEagle

Gibt es noch einen anderen Weg, um jQuery zu erhalten?

So ziemlich egal, wo in Joomla-Code, bspw. in der index.php des Templates

JHtml::_('jquery.framework');

lädt dir die nötigen Scripts.

Zitat von IceEagle

$doc->addScript('http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js');

Ist ja klar, wenn du http verwendest, dass du dann einen "gemischte Inhalte" bekommst. Aber so verursachst du eh doppeltes Laden von JQuery, was natürlich üble Performance-Einbuße ist.

Bei dem, was ich ingesamt rauslese, empfehle ich dir, das Helferlein-Plugin JQueryEasy zu verwenden und so einzustellen, dass JQuery aus dem "Framework" geladen wird, da wir deinen Gesamt-Code nicht kennen. Irgendwo hast einen größeren Fehler drinnen bzgl. Ladereihenfolgen der Skripte.

Das ist leider so, dass, wenn der Introtext beschnitten wird, also eine maximale Länge eingestellt ist, dass eben so Code auch abgeschnitten wird und er damit nicht mehr funktionieren kann.

Zusätzlich wird javascript unwirksam gemacht beim Kürzen. Und meist HTML entfernt. Dann bleibt eben nur ein spärlicher Hieroglyphenrest.

<img src="components/com_mycomponent/bild.jpg">

Den Rest erledigt Joomla (SEF-Plugin).

Vielleicht von Interesse. Als Untermauerung bzgl. meines Gemaules

https://seopressor.com/blog/go…meta-descriptions-length/

z.B.

Zitat

But look at what I’ve found today:

...

There’s a total of 222 characters for the meta description in this snippet, and none of the words is truncated.

...

The titles and meta descriptions on mobile have also increased and is even longer than the desktop.