Beiträge von Martina-LadySolveig

Das habe ich schon verstanden. Aber gerade auch für kurze Tests finde ich meine user.css viel komfortabler 😊 Das meinte ich.

Bevor du dich mit inline css im Editor quälst, mach dir doch lieber zwei Tabs nebeneinander auf und nutze die user.css in deinem Template zu test zwecken. Ist doch sowieso viel bequemer

Auch Off-Topic für deinen eigentlichen und wichtigen Fehlerbericht, aber vielleicht eine kleine Erleichterung in deinem Workflow Norbert.R

Du kannst dir auch die joomla.asset.json aus dem Parent Template in das Child kopieren (wird nicht automatisch mit angelegt) und hier eine Version eintragen für das user.css asset.

Am besten gar nichts anderes verändern.

Die Version kannst du dann hochzählen wenn du eine Änderung gemacht hast. Das sollte den Browser auch dazu animieren neu zu holen und du brauchst nicht jedesmal ein neues Child Template.

Hier ein Beispiel aus einem Cassiopeia Child Template. (der Tag für Version ist nicht vorhanden, den kann man einfach hinzufügen).

{
    "name": "template.user",
    "description": "A file where a user can add their own css.",
    "type": "style",
    "uri": "user.css",
    "version": "1.0.3",
    "weight": 500,
    "dependencies": [
      "template.active",
      "template.active.language"
    ]
},

Zitat

Frage: Werden in den Childtemplates nur CSS-Anpassungen vorgenommen? Dafür ist doch eigentlich die user.css gedacht,

chr-hl Antwort (Off-Topic) Du kannst über die Childtemplates alles überarbeiten
- neue Overrides anlegen die es bisher im Parent Template noch gar nicht gibt
- Overrides noch einmal überschreiben die bereit im Parent Template vorhanden sind
- assets wie css und js hinzufügen und überschreiben (sogar die joomla.asset.json)
Und sogar die xml Anpassen.

Childtemplates erben alles was nicht vorhanden aus ihren Eltern, aber du kannst hier tatsächlich alles überschreiben was du benötigst, ist nicht auf Stile begrenzt.

Alternativ - eines der wenigen Dinge, für die ich tatsächlich immer einen Template Override habe.







Ich kann mich nicht erinnern, dass ich mal eine Fall hatte bei der die Liste hier für mich persönlich wirklich Sinn gemacht hat

Ein völlig anderer Blickwinkel - das Joomla CMS ist genau das was die Community draus macht.

Die Ursprungsfrage war, warum findet man in der öffentlichen Wahrnehmung außerhalb wenig über Joomla.
Das liegt daran weil zu wenige die es nutzen darüber sprechen/schreiben.

Umso weniger darüber sprechen/schreiben umso weniger wird es genutzt und früher oder später gibt es halt auch umso weniger die Aktiv noch weiter daran arbeiten.

Wer also Joomla gerne nutzt und das auch zukünftig weiterhin tun möchte, sollte auch drüber sprechen

Rolf Dautrich grundsätzlich bin ich da absolut bei dir. Ich sehe allerdings auch genau bei dem was Roesi anspricht wahnsinnig großes Potential. Sicherlich könnte man das auch im Rahmen des Community-Projekts unterbringen.
Muss man aber gerade was die Steigerung der öffentliche Wahrnehmung angeht gar nicht unbedingt.

Hier greift für mich so ein wenig der "Mein Nachbar hat mir das empfohlen" Effekt.
Wenn überzeugte Nutzer, über ihr Lieblings-CMS irgendwo etwas schreiben, ist das ein absoluter Gewinn für uns alle.

Hallo Roesi,

ich stimme da Andreas zu, Wordpress ist weiter verbreitet. Aber das weitaus Interessantere steckt ja schon ein bisschen in deiner eigenen Beobachtung.

Zitat

Das wird in meinen Augen nicht Kommerziell gemacht.

Ein weiterer Grund ist schlicht, dass es momentan kaum jemand tut. Die offiziellen Informationen sind verfügbar, daher sollte niemandem etwas im Wege stehen, diese auf den Kanälen zu verbreiten, auf denen wir unterwegs sind.
Ich glaube, jeder von uns, der von Joomla! als CMS überzeugt ist, könnte zu einer höheren Bekanntheit beitragen und langfristig dadurch auch mehr Adaption fördern.

Es ist übrigens auch ein großartiger Weg, das Projekt grundsätzlich zu unterstützen, zusätzlich zu den unzähligen offiziellen Möglichkeiten.

Wenn du im Oktober nach dem Update dann die Dropdowns mit mehreren Menü-Ebenen möchtest, kannst du einfach dein Override wieder löschen. Du verbaust dir hier nichts.

BBd_Muc Wenn du zur alten Ansicht komplett ohne Dropdowns zurück möchtest findest du hier eine Schritt-für-Schritt Anleitung.

Als zweiten Punkt (ein bisschen runterscrollen)
- How to make a sidebar menu without dropdown toggle

guide.joomla.org/user-manual/menus/keep-submenus-open

Zitat

Oder haben sie Ihren Zweck bereits erfüllt?

Diese Einschätzung ist absolut korrekt. Sie stören im Prinzip nicht, aber du kannst diese Dateien auch problemlos manuell entfernen.
Sie werden beim nächsten Joomla Update auch wieder entfernt.

Gilt für diese beiden Dateien

• filepatcher.php (Zuletzt geändert 16.07.2026)

• filepatcher.xml (Zuletzt geändert 16.07.2026)

  
  Leider hat es hier eine Überschneidung zwischen einem regulären Patch im Joomla Core und dem Hotfix gegeben, sodass es kurzfristig nur so zu lösen war. Zukünftig wird das auch bei einem Hotfix nicht mehr auftreten.

Ich habe mir kurz mal deine Seite angeschaut.

Das Verhalten, dass man von der Startseite aus den Button zum aufklappen nicht sieht, ist durch die bewusste Umstellung des Schalters **Untermenüeinträge anzeigen** ausgelöst.

Sobald du dann auf der Unterseite bist, siehst du den Schalter zum ein- und ausklappen für das Untermenü.

Wenn du das wieder auf **anzeigen** umstellst siehst du auch auf deiner Startseite den Button zum aufklappen.

Da du ein sehr langes Untermenü hast könnte ich mir auch gut vorstellen, dass es Sinn macht hier mit den Einstellungen der Ebenen zu arbeiten und lieber auf deiner Unterseite ein eigenes Modul (beginnend mit Ebene 2) zusätzlich zu haben (Hauptmodul dann letzte Ebene 1). Das ist jetzt aber eher so mein Gefühl und ist schon wieder eher Off-Topic was dein eigentliches Problem angeht.

Mmh... ich dachte man macht einen "Draft" nicht einfach nur so, sondern damit man eine Grundlage hat drüber zu reden ob das der Weg ist den man gehen will. Habe eben nur heute gesehen, dass dieser Thread hier wohl der Ursprung war und wollte mich einfach nur dazu austauschen. Aber dann halte ich mich wieder zurück.

Von da kam ich ursprünglich und habe mich die ganze Zeit schon gewundert woher die Idee kommt

Ich bin ehrlich, einem Entwickler fällt es jetzt nicht sooo schwer eine solche Funktion wieder nachzurüsten wenn sie gebraucht wird. Ich bin auch nicht sicher wie viele Nicht-Entwickler die Kontaktkomponente überhaupt einsetzen. Für jemanden wie mich ist sie ein super mächtiges Tool, aber viele setzen sie ja wahrscheinlich auch gar nicht ein und sind da bei einer gängigen Drittentwickler Extension. Ich habe mich nur gewundert, warum wir es entfernen statt es zu verbessern. Ich bin da also eher unparteiisch. Wollte nur in den Raum werfen das es durchaus noch andere Möglichkeiten gäbe - völlig Ergebnis offen. Wenn es dem Großteil der Nutzer lieber ist, es wird entfernt, ist das zwar Schade aber auch ok für mich.

Ich finde es auch Schade wenn die Option komplett verschwinden würde. Schließlich gibt es für com_contact so viele Möglichkeiten das einzusetzen und hier würde dann eine Funktionalität komplett verschwinden. Die z. B. im Kontext von bekannten "eingeloggten" Nutzern gar kein Problem darstellt. Vielleicht eher für "Gast" Benutzer ein opt-in davor?
Dann geht natürlich eine Nachricht raus um die E-Mail Adresse zu bestätigen, bevor die eigentliche Nachricht raus geht. Aber zumindest kann das "Textfeld" nicht mehr zum spammen verwendet werden.

Vielen Dank Rolf Dautrich!

axel.baxmann Antwort E-Mail ging gerade an dich raus. Ich freue mich darauf, dich und deine Website kennen zu lernen und das Problem aus dem Weg zu schaffen

Muecke82 ich sehe das wie agarbathi
Ich denke eines der wichtigen Dinge in Bezug auf SEO und KI in die Zukunft gedacht ist, dass das was du auf deiner Website anbietest auch maschinenlesbar gut aufbereitet ist.
Das heißt zusätzlich einfach die Schema.org Daten beispielsweise als wichtiges Kriterium.
Auch Google unabhängig von KI kommt öfter auf deine Seite wenn es "energiesparender" ist.
Also am Ende zählt sowohl für die KI als auch für Google
a) das deine Inhalte einen Mehrwert bieten und somit ausgespielt werden
b) das sie möglichst einfach für die Bots zu crawlen sind.

Also bist du mit Joomla oder egal welchem CMS eigentlich gut aufgestellt. Die Daten liegen in der DB und können je nach den Bedürfnissen aufgebereitet ausgegeben werden.
Das ist eigentlich der große Vorteil eines CMS.
Daten und Layout sind (im besten Fall) getrennt und können jederzeit genau so ausgespielt werden wie man es braucht und wie es sich eben entwickelt.

(Im besten Fall deshalb, da ich weiß das einige Layout- und Templatebuilder diesen Grundsatz ein wenig bewusst oder unbewusst umgehen. Aber das ist dann eben ein wenig an den Grundsätzen eines CMS vorbei gearbeitet )

Ich kann verstehen, dass das nicht deine Welt ist, aber am Ende wenn du optimieren willst wirst du dich wohl an die Funktionalitäten rantrauen müssen die Joomla dir ja glücklicherweise schon mitliefert. Wie beispielsweise eben das Schema.org Plugin aktivieren und hier die Daten angeben. Ebenso wie die Meta-Daten zu deinen Artikeln.

Bei der HTML Code Optimierung kommt es sehr stark auf das Template an das du nutzt.
Da lässt sich natürlich auch einiges Optimieren, fraglich ist wie groß das ins Gewicht fällt und ob sich das Kosten/Nutzen technisch dann überhaupt lohnen würde, denke ich.

Nur eine kleine Anmerkung, die du mir hoffentlich nicht übel nimmst eva2196

Ja ich stelle diese Extension sehr gerne der Community kostenlose zur Verfügung.

Ich habe sie urpsrünglich für mich selbst geschrieben, da ich mich nicht abhängig machen wollte von irgendwelchen anderen Abo-Services und eine Nextcloud Integration gebraucht habe.

Dann kam eine zusätzliche Zoom Integration dazu, die in Absprache einer meiner Kundinnen (die die Kosten der Entwicklung getragen hat) auch der Community direkt mit zur Verfügung gestellt wurde.

Also ja, ich bin dankbar über jeden Fehler der gemeldet wird und den ich bisher weder über e2e Tests abgefangen, noch selbst entdeckt habe und wenn ich das Angebot mache zu debuggen und es liegt an meiner Erweiterung ist es selbstverständlich, dass es auch nichts kostet.
Maintenace und support bleiben bei mir hängen, dass ist mir jederzeit bewusst wenn ich etwas der Allgemeinheit zur Verfügung stelle.

Sieger66 hat aber natürlich nicht unrecht, falls es was mit einer speziellen Konstellation zu tun gehabt hätte, hättest du wahrscheinlich auch von mir die Anfrage bekommen ob ich entgeltlich weiter debuggen und fixen soll oder nicht.
Also von daher ist mit ihm schon alles absolut in Ordnung.

Ich denke auch kostenlose Extension dürfen einem etwas "Wert" sein, vor allem wenn sie bei einem kommerziellen Projekt behilflich sind.
Auch z. B. über eine Google Bewertung oder das Angebot für eine persönliche Bewertung die man auf der HP veröffentlichen darf freut sich jeder Entwickler - es muss nicht immer Geld sein.
Wir kommen alle viel besser voran wenn wir uns Gegenseitig unterstützen - das ist zumindest meine Ansicht.

Vielen vielen Dank dir noch mal für den Fehlerbericht!

Super eva2196
vielen lieben Dank für die Rückmeldung.

Nur kurz als Rückfrage, die Uhrzeit war mit der Version 1.0.7 gesetzt und war dann nach dem Update auf 2.0.0 nicht mehr vorhanden, das hab ich richtig verstanden?

Das ist super hilfreich, danke für die Info.
Fix im Anflug
Schön das es jetzt bei dir funktioniert wie gewünscht.

Hallo eva2196,

ich habe gestern Abend noch die bereits im anderen Thread schon angesprochene Joomla! 5 Version online gestellt.
SimplySmart-OS

Da die Seite gerade im Aufbau ist gehe ich davon aus sie läuft auf der neuesten Joomla Version?

Hier läuft alles über den in Joomla! 5 eingeführten Joomla Dialog, also keine Abhängigkeiten mehr von Haus aus zum Bootstrap Modal oder UIkit Modal und sollte dementsprechend auch stabiler auf diversen Templates laufen.
(Kann aber natürlich über einen eigenen Layout Override jederzeit selbst wieder geändert werden wenn gewünscht).

Schau doch mal ob das schon das problematische verhalten in Verbindung mit dem Astroid Template behebt und gib gerne Feedback

Was mir jetzt gerade auch ins Auge gesprungen ist diese Zeile in der Fehlerausgabe der Console

/* `media/uikit3/js/uikit.min.js` minified by Astroid *//*! UIkit 3.15.12

Wenn dein Template die Uikit Modale nutzt statt Bootstrap gab es hier in der von dir installierten Version auch einen extra switch in den Plugin Einstellungen.



Wenn das alles nicht hilft, schick mir doch gerne noch mal eine E-Mail, dann sende ich dir einen Link, über den du mir ein Akeeba Backup der Seite zur Verfügung stellen kannst um das ganze mal direkt zu debuggen.

Viele liebe Grüße
Martina