Ich vermute, die Pfade/Adressierung passt nicht.
Was hast du bei Helix zum Parameter favicon eingestellt?
Kann man die Website online ansehen?
Ich vermute, die Pfade/Adressierung passt nicht.
Was hast du bei Helix zum Parameter favicon eingestellt?
Kann man die Website online ansehen?
Das Problem ist halt, dass sich Joomla nun ziemlich spät dazu entschlossen hat, auf Bootstrap 5 umzusteigen. Vielen Erweiterungen wird mit diesem Schritt der Teppich unter den Füssen weggezogen, weil BS 5 kein JQuery an Bord hat, und Erweiterungen sich nun selber um JQuery kümmern müssen.
Wo siehst du das Problem genau?
Wenn ich das hier richtig lese, dann ist jQuery weiterhin in Joomla verfügbar:
https://www.joomla.de/news/joo…a-7-jetzt-mit-bootstrap-5
Nach der Antwort hier, müssten die Erweiterungsentwickler nur einen Befehl einfügen:
https://github.com/joomla/joomla-cms/discussions/32242
Übersehe ich etwas?
Alles anzeigen
Ich glaube eine horizontale Anzeige des Menüs funktioniert so ohne Weiteres nur auf der Position menu - oder klappt das bei einem von auf der Position footer?
Was passiert, wenn eine Website, die mit einem Open-Source Content Management wie Joomla erstellt wurde, aufgrund eines Fehlers ausfällt?
Gewährleistungsansprüche sind im Open-Source-Bereich in der Regel ausgeschlossen.
Aber: Die Entwickler bei Open-Source-Projekt wie Joomla, bei denen viele aktiv mitarbeiten, finden und beheben Fehler schnell. Schon allein im eigenen Interesse: Die Mitglieder eines Open-Source-Projektes nutzen die Software meist selbst!
Das bedeutet aber auch, dass man mit einem seltenen Problem, dass nicht viele in der Community haben, alleine da steht.
Deshalb würde ich jetzt lokal schon Joomla 4 testen und Probleme melden.
Im Echtbetrieb würde ich aber erst eine stabile Version installieren. Allein, weil die Wahrscheinlichkeit größer ist, das viele die gleichen Fehler haben.
Aber als Einzelner bei der Testung an Alles zu denken, ist verdammt schwer
Das ist nicht nur schwer, sondern sogar unmöglich. Sogar für Maschinen.
Das der ideale Test nicht berechenbar ist, hat Howden 1977 bewiesen. ( ist beispielsweise hier auf Seite 18 erklärt: st02.pdf (uni-bielefeld.de) )
..
Man ist doch in Joomla 4 sooooo stolz auf das eigene undurchschaubare JavaScript-"Framework" ohne Doku für normale Benutzer, wenns denn überhaupt eine gibt.
..
Was meinst du mit eigene JavaScript Framework?
Was
Vielleicht teste ich einfach mal, nach und nach die Elemente im html-Verzeichnis zu deaktivieren und zu schauen, was dann passiert. Wenn sich nichts (Nennenswertes) ändert, entfällt der entspre
Ich würde die Overrides löschen, die nicht gebraucht werde.
Das hat den weiteren Vorteil, dass Änderungen in den Layouts der Joomla Core Datein auf deiner greifen. Andernfalls haben die veralteten Overrides Priorität.
Und man sollte SOFORT damit anfangen oder gleich mit den Nightly Builds und täglich updaten, weil sich da vieles Vieles geändert hat. Unter anderem erneut die Bootstrap-Version (CSS, JS).
Und das Ding mit Protostar. Wenn's dir nur um Rumprobieren/Üben geht, OK. Eine Migration alter Protostar-Templates und -Klone auf Joomla 4 ist aber generell Seuche. Lohnt eigentlich nicht wirklich vom Arbeitsaufwand her. Nimmt man besser das Joomla-4-Template und baut das um.
Das fällt mir gerade erst ein. Es gibt doch sicher welche, die von Protostar nach Cassiopeia wechseln möchten. Geht das?
Zu 1 hilft dir vielleicht https://www.mediaevent.de/css/background.html
Wie hast du die sql Datei erstellt?
Ich glaube, nicht übereinstimmenden sql_mode sind das Problem. (
Schau einmal in den Optionen des Template ob "compile less to css" aktiv ist und verändere die Einstellung zum Test.
Or ask in the English language forum:
Hast du es so gemacht wie hier beschrieben: Joomlaeigene Templates anpassen/ändern (z.B. Protostar, Beez3). Vorher eine Template-Kopie anlegen!
Um MariaDB und Joomla einzuordnen, finde ich diesen Blogbeitrag - inklusive Links und Kommentaren - hilfreich, auch wenn er in der Ursprungsversion 2 Jahre alt ist:
https://www.joomlashack.com/blog/joomlashack/mariadb/
Ich nutze Joomla schon seit Jahren unter Ubuntu.
Versuche es JEM-Forum https://www.joomlaeventmanager.net/forum/index , falls hier niemand helfen kann.
Falls jemand sich dafür interessiert, warum es 2014 zu den verschiedenen Versionen gekommen ist, findet unter https://www.akeeba.com/news/1558-info-about-fof-and-f0f.html die (einseitige) Erklärung von Akeeba.
Mir hat das einmal geholfen zu verstehen, was in welchem fof/f0f implementiert ist und warum.
Ich habe vor kurzem die PHP Version von 7.3 auf 7.4 umgestellt. Ich meine eigentlich hat alles danach einwandfrei funktioniert,
Ich gehe davon aus, dass es an der PHP Version liegt. Zunächst hat es wahrscheinlich funktioniert, weil noch etwas im Cache war.
Gibt es bei dir das Modul "IconicModLatest" und was passiert, wenn du das deaktivierst?
Ich finde der Kulturbanause hat den Begriff hier gut erklärt:
Adaptive Website vs. Responsive Website | kulturbanause® blog
Für die Serienbriefe kann ich natürlich einen Workaround machen, indem ich in XLS "23:00:00" und "22:00:00" gegen "24:00:00" ersetze, aber ich wüsste doch gern, wo ich hier den Fehler drin habe?
Ich kenne die genannten Erweiterungen nicht, aber ich vermute, dass eine die Klasse JDate nicht korrekt implementiert.
Wenn diese Klasse korrekt genutzt wird, dann wird ein Datum immer in UTC in der Datenbank gespeichert. Das bedeutet, dass beim Speichern eines Datums immer die "aktuell aktive" Zeitzone in UTC umgerechnet werden muss. Beim Anzeigen des Datums geschieht dies umgekehrt: UTC wird in die "aktuell aktive" Zeitzone umgerechnet.
Ich finde das dieser Beitrag JDate gut erklärt:
How to use JDate - Compojoom Blog - compojoom.com
Hast du dir die gespeicherten Werte für die vermeintlich "falschen" Datumsangaben in der Joomla-Datenbank einmal angesehen?