Beiträge von Harmageddon

    Ein Ansatz wäre, den Cookie Hint über dem Popup einzublenden, sodass man zumindest die Möglichkeit hat, zuerst die Cookies zu akzeptieren, und danach das Popup wegzuklicken. Das ginge mit folgender CSS-Anweisung in der custom.css deines Templates:

    Code
    div#redim-cookiehint-top {
      z-index: 100000;
    }


    Ich könnte mich jetzt also in das CookieHint-Plugin einarbeiten und eine Möglichkeit suchen den von PopUp Aholic erzeugten Cookies von Anfang an zuzulassen. Ich weiß aber leider nicht, wie einfach oder aufwändig das Ganze ist.

    Ist das sinnvoll, das CookieHint-Plugin dann direkt zu umgehen? Wenn ich das richtig im Kopf habe, müsstest du dann begründen, warum der Cookie für PopUp Aholic technisch unerlässlich und nicht zum persönlichen Tracking verwendbar ist.

    Wenn es nicht viele Beiträge sind, kannst du sie bearbeiten und den Autor im Tab "Veröffentlichung" ändern. Um es automatisch zu machen, musst du an die Datenbank ran. Vorher zur Sicherheit bitte ein Backup der Datenbank machen!

    Dann aus der Tabelle ' #__users' die ID des alten und des neuen Accounts suchen. Mit dem folgenden Befehl wird der Autor geändert:

    SQL
    UPDATE `#__content` SET `created_by` = neue_id WHERE `created_by` = alte_id

    Natürlich neue_id und alte_id jeweils ersetzen. Und #__ ersetzt du mit deinem Datenbankpräfix.

    Der Screenshot hilft bei der Erkennung des Problems! Da sieht man, dass das X in die rechten Formularfelder reinrutscht, bzw darunter liegt. Wenn du darauf klickst, klickst du nicht auf das X selbst, sondern auf die rechte Hälfte des Formulars.


    Das ist ein Fehler in Joomla!, nicht in deinem System. Ich habe hier eine Meldung dazu eingereicht. Bis das Problem behoben ist, ist die einzige Lösung, die ich spontan sehe, die Breite des Fensters entweder zu vergrößern oder zu verkleinern. Bei einem breiteren Fenster ist mehr Platz da und die Buttons rutschen nicht mehr ineinander. Bei einem kleineren Fenster (<= 767 Pixel) greift die mobile Ansicht und es ist auch wieder mehr Breite für die einzelnen Felder da. Oder vielleicht hat hier ja noch jemand eine Idee.

    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.

    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 :) Vorher waren 6 Bilder nebeneinander, später dann 5 Bilder - daher Zentrierung nicht möglich gewesen.

    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! ;):thumbup:

    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.

    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:

    1. Kategorie mit Häkchen markieren
    2. Per Klick auf "Papierkorb" in den Papierkorb verschieben
    3. Unter "Suchwerkzeuge - Status wählen" auf "Papierkorb" gehen
    4. Kategorie mit Häkchen markieren
    5. "Papierkorb leeren" klicken

    Und verschwindet sie dann aus dem Papierkorb?

    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.