Hmm... auf Englisch interessanterweise 1.9.0 (build 930) https://crosstec.org/en/downlo…zingforms-for-joomla.html
Die Angaben dort scheinen nicht ganz aktuell zu sein. Beim Download erhalte ich aber bei beiden Version 1.9.1 (build 931). Dort ist auch der Inhalt der Datei, aus der der Fehler kommt, ein anderer. Auf der Seite von saumhuhn sieht es mir nach build 926 aus.
Long story short: Lad dir die aktuellste Version von der Herstellerseite runter und installiere sie.
Welche Version von BreezingForms benutzt du denn? Die Datei, die BF versucht zu finden (libraries/joomla/factory.php), existiert m.W. seit Joomla! 3.8 nicht mehr. Da müsste es doch seither mal ein Update von BF gegeben haben. Sonst mal den Entwickler anschreiben, unter Angabe der Fehlermeldung.
Interessant wäre, um welches Modul es sich genau handelt. Ich habe nur eins über joomlaos gefunden (was nicht die beste Quelle für Erweiterungen jeglicher Art ist), und das scheint für 2.5 konzipiert und seit 4 Jahren nicht mehr aktualisiert worden zu sein. Davon würde ich dann eher abraten.
Vielleicht hilft dir diese Anleitung hier: https://www.dwd.de/DE/leistung…bindung_ausarbeitung.html
Das ist der Titel der PDF-Datei, das hat nichts mit Joomla! zu tun und kann auch nicht dort eingestellt werden. Den kannst du nur in der PDF-Datei setzen, da steht er in den Dokumentinformationen. Versuch mal, in dem Programm, mit dem du das PDF erstellst, einen Dokumenttitel festzulegen.
Edit: Re:Later war mal wieder schneller. Hi! 
Hallo christine2!
hmm, meine Bildschirmbreite ist gestern gleich geblieben
Könnte mir vorstellen, dass Applemus da zwischendurch was an den Breiten geändert hat. Bei mir haben die Bilder mal die ganze Breite des Content-Bereichs ausgefüllt, mal weniger. Zentriert war es nie, aber das fiel halt nur auf, wenn die Galerie nicht genau über die ganze Breite geht, weil sonst der Platz bis zum rechten Rand genauso gefüllt ist wie nach links (bzw. nur noch das Padding des content dazwischen ist).
Es gibt z.B. auch eine Einstellung bei den Optionen: Allgemeine Einstellungen > PG zentriert > Ja.
Funktioniert nur bedingt. Ist auch u.a. abhängig wie breit Main-Content (pg-msnr-container) ist usw.
Wurde von mir schon öfters gefragt: Warum Plugin verwendet wird. Bei dieser Ansicht in diesem Fall, wäre Plugin nicht notwendig. Formatierungen z.B. sind dadurch auch erschwert.
Ah okay, dann ist das wahrscheinlich die sinnvollere Variante, wenn man das einstellen kann. Da bist du eher die Expertin! 
Das liegt nicht am Browser, sondern an der Bildschirmbreite. Die Bilder haben eine feste Breite und je nachdem, ob sie gerade so reinpassen oder eins in die nächste Zeile runterrutscht, bleibt da ein Freiraum. Um dessen Positionierung geht es.
Ich fürchte aber, dass das nicht so ganz einfach wird, es sei denn, Phoca gibt einem da irgendwelche Möglichkeiten mit. Du müsstest das ganze Teil von float:left auf ein Flexbox-Modell umstellen.
Aktuell ist die Seite auch im Wartungsmodus, ich kann also nicht schauen, wo genau man was ändern müsste.
Das sieht aus, als wäre mindestens die index.php aus einer sehr alten Joomla!-Version (vor 3.2). Versuch mal, im Administrationsbereich die Core-Dateien zu überprüfen und wiederherzustellen (vorher Backup anlegen!). Wie das geht, ist z.B. hier beschrieben: Paketdatei hochladen fehlt
Das sieht nach einem z-index-Problem aus, ggf in Verbindung mit position:relative/absolute/fixed/sticky. Versuch mal in deinem Template, dem backdrop einen niedrigeren oder dem Modal einen höheren z-index zu geben. Wenn das nicht klappt, musst du die jeweiligen Elternelemente bis hoch zum body vergleichen. Dann hat eines davon eine position-Angabe mit einem der Werte relative/absolute/fixed/sticky und einen zu niedrigen bzw. zu hohen z-index.
Beispiel:
Normalerweise hat das modal-backdrop einen z-index von 1040 und das modal einen von 1050. Also ist das Modal-Fenster vor dem schwarzen Hintergrund.
Wenn jetzt das modal-backdrop direkt unten im body drinsteht, bleibt es beim z-index von 1040. Wenn das modal ein Elternelement hat, das position:relative und z-index:20 hat, kommt der eigene z-index von 1050 nicht mehr zum Tragen, sondern der des Elternelements. Dann liegt das Elternelement mit allen Inhalten hinter dem schwarzen Hintergrund und du hast das Verhalten, das man auf dem Screenshot sieht.
Ich hoffe, das war einigermaßen verständlich. Wenn du den Fehler nicht selbst findest, müsstest du uns entweder einen Zugang (sinnvollerweise per PN) oder zumindest irgendwie die Dateien deines Templates und den Quellcode, der für die oben zu sehende Ansicht ausgegeben wird, zukommen lassen.
Wunderbar ... diese Erweiterung kannte ich nicht. Recht umfangreich, aber macht genau was ich will - DANKE!
Aber würde soetwas auch zusätliche Erweiterungen über etwaige Template-Codes oder Override gehen?
Nur, wenn du dein Menü so strukturierst, dass für die Beiträge ein anderer Menüpunkt aktiv wird als die Startseite (z.B. mit eigenen Menüpunkten pro Artikel oder Kategorie). Dann klappt das über die normale Modulzuweisung. Wüsste nicht, was man da mit Overrides machen könnte. Höchstens im Template die Modulpositionen für alle Seiten, die nicht die Startseite sind, entfernen.
Hallo und danke, dass du die Lösung hier festhältst! Bist bestimmt nicht der einzige, den das betrifft, daher werden sich andere freuen, wenn hier direkt die Lösung steht.
Wäre schön, wenn es für dieses Problem im Joomla Core Code demnächst mal eine dauerhafte Lösung geben würde, so dass man nicht immer wieder diesen Patch aufspielen muss, der ja auch möglicherweise irgendwann nicht mehr funktioniert.
Der Patch hängt leider seit August mehr oder weniger fest. Er löst das Problem für die Umlaute, allerdings gab es den Wunsch, das für alle Zeichen zu lösen, bevor er eingebaut wird. Und da gibt es noch Probleme mit einigen Multibyte-Zeichen wie manchen Schriftzeichen, die bisher noch niemand gelöst hat.
Bis das der Fall ist, muss man den Patch leider manuell (oder über den Patchtester) anwenden, wenn die betreffende Datei durch ein Update geändert wurde. Es reicht übrigens, die Zeilen https://github.com/joomla/joomla-cms/pull/25845/files in der einen Datei auszutauschen, anstatt gleich das komplette Verzeichnis zu kopieren. Da in den Filtern einige sicherheitsrelevante Dinge drin sind, würde ich da dazu raten, so nah wie möglich an der aktuellsten Version zu bleiben und so wenig wie möglich auszutauschen.
Deine robots.txt verbietet Google unter anderem, auf die Ordner "templates" und "media" zuzugreifen. Dann fehlen sämtliche Styles und die Seite sieht so aus, wie sie dann aussieht. Nimm mindestens die beiden Verzeichnisse aus deiner robots.txt raus. Orientieren kannst du dich an der aktuell in Joomla! mitgelieferten hier: https://github.com/joomla/joom…b/staging/robots.txt.dist
Würde mich wundern, wenn es da Erweiterungen gäbe, mit denen man das so 1:1 umsetzen könnte. Das ist schon eine sehr spezifische Anwendung, bei der du um eine Eigenentwicklung nicht herumkommen wirst.
Ich habe leider keine Programmierkenntnisse und auch kein Budget, daher ist es wahrscheinlich auch ziemlich schwer.
Dann erlaube ich mir mal die Frage: Warum willst du ohne Budget und ohne eigene Programmierkenntnisse eine Seite aufziehen, die eine "Nische" füllt, die bereits von etablierten Anbietern wie Kicktipp o.Ä. gefüllt ist? Was ist der Mehrwert deiner Seite?
Ich bin mir nicht ganz sicher, ob du das mit diesem Satz hier meinst:
Wenn ich im Admin-Backend als Hauptadmin eine Kategorie lösche und anschließend "engültig" lösche
Hast du die Kategorie auch aus dem Papierkorb gelöscht? Also so:
Und verschwindet sie dann aus dem Papierkorb?
Schau mal hier rein, da gibt's Tipps, wie man an die relevanten Infos kommt: Fehler finden durch detailliertere Fehlermeldung. Debug-Modus. Call stack.
Und der Redirect gibt mir eine URL ohne Id aus (option=com_meals&view=ingredient&layout=edit).
Dann ist das das Problem. Hast du die save-Methode im Controller auch selbst eingerichtet oder benutzt du da die von FormController? In ersterem Fall müsstest du dir überlegen, woher du die ID des neu gespeicherten Datensatzes herbekommst, und diese an den Redirect anhängen. Wenn du die von FormController verwendest, sollte das dort schon drin sein, vorausgesetzt, das Model legt die ID im State ab. AdminModel macht das z.B. hier: https://github.com/joomla/joom…odel/AdminModel.php#L1302
Spricht denn etwas dagegen, nach deiner Vorverarbeitung (json_encode etc) die Daten im Model über parent::save($data) zu speichern?
Welcher Teil der Komponente setzt eigentlich das
$app->getUserState('com_meals.edit.ingredient.data', array());
?
Da werden Formulareingaben temporär gespeichert, wenn die Eingabe noch nicht fertig ist. Also z.B. wenn du was ins Formular eingetragen hast, aber ein Feld falsch oder nicht ausgefüllt hast. Dann wirst du ja wieder zum Formular zurückgeleitet und willst nicht wieder alles von vorn eingeben. Dafür ist das da. Wenn ich das richtig im Kopf habe, wird der im Controller befüllt.
Ich würde übrigens noch überlegen, anstatt die save-Methode komplett in deinem Model zu machen, über die Methode des übergeordneten Models parent::save zu gehen, da da schon viele Sachen abgefangen werden.
Zu deinem Problem: Stimmt denn der Redirect, d.h. wirst du nach dem Speichern auf die richtige Seite (mit der neuen ID in der URL) geleitet? Und was steht in der Variable $requested_id in loadFormData?
Das hat mit dem Menü selbst nichts zu tun.
Und wenn du die Frage an den Entwickler so formulierst, dass er versteht, was du meinst? Frag nach, wie du ein Menü oder was auch immer da hin soll auf die Offcanvas-Position legst, und wie du es schaffst, dass dann der Button angezeigt wird. Kannst ja auch auf den Thread hier verlinken, vielleicht wird dann klarer, worauf du hinauswillst.
Was passiert denn, wenn du ein Modul auf der Position "offcanvas" veröffentlichst?
Es sind aktuell 30 Tickets offen, die als "Release Blocker" gelten, d.h. die gelöst werden müssen, bevor die 4.0 kommen kann. Wenn du ungeduldig bist, kannst du dich gern an deren Lösung beteiligen: https://github.com/joomla/joom…/labels/Release%20Blocker
Nachtrag: Die "Beta Blocker", die vor der ersten Beta gelöst werden müssen, sind hier zu finden: https://github.com/joomla/joomla-cms/labels/beta-blocker
Eine Übersicht des aktuellen Standes gibt es unter anderem hier: https://github.com/joomla/joomla-cms/issues/27812
Das Problem scheint zu sein, dass alle JavaScript-Dateien vom Browser blockiert werden, weil sie mit einem ungewöhnlichen MIME-Type ausgeliefert werden. Mein Firefox zeigt in der Konsole etliche Meldungen dieser Art an:
Da scheint seitens deines Servers irgendeine Einstellung zu greifen, die JavaScript-Dateien nicht als Typ "text/javascript" oder einen anderen der hier definierten, sondern als ein "text/x-js" ausliefert. Hast du FTP-Zugriff auf deinen Webspace? Also einen Zugang, mit dem du Dateien hoch- und runterladen kannst? Dann würde mich doch mal der Inhalt der Datei ".htaccess" interessieren, die dort im Stammverzeichnis deiner Seite liegen könnte (ggf. im FTP-Programm "versteckte Dateien anzeigen" aktivieren).
Oder du fragst den Hoster, woran dieses Verhalten liegen kann.
Edit: JoomlaWunder war schneller. Hallo!