Backend oder Frontend? Beim Anzeigen oder Speichern? Wann wird das Speichern wodurch abgefeuert? Plugin mit Joomla-Methode? Eingebetteter PHP-Code?
$app->input->get('id');
Hast du denn eine Weiche drinnen, dass dein Code nur auf Beitragsseiten zum Zuge kommt. Man kann nicht immer sicher sein, dass die Input-Id eine Beitrags-Id ist. Kann auf bestimmten Seiten z.B. auch die Kategorie sein oder ganz anders. Im Editmodus kann es auch gar keine "id" sein, sondern z.B. "a_id".
Beim Update von 3.9.27 auf 3.9.28 hat sich am Code eigentlich nichts geändert, was auf Menüs Einfluss hat.
Vielleicht mal alle Caches (Joomla, Browser) löschen und, wenn du das JCH-Plugin verwendest, da mal rein und auch dessen Cache explizit löschen.
Das <p> wird im Normalfall bereits im Editor um den {loadmoduleid 123} erzeugt, weil man das Ding ja meist in einen neuen Absatz einsetzt.
Mit dem JCE-Shortcode-Feature sollte das aber nicht passieren, wenn man so ein DIng neu im Editor einsetzt bzw. den Beitrag neu speichert. Lege ich meine Hand nicht ins Feuer was davon nun, weil ja als experimentell gekennzeichnet und Joomla 4.
Schalt doch mal das Content-Plugin loadmodule (oder wie es heißt) aus. Und schau dann in den Seitenquelltext wie es dann aussieht.
<p>{loadmoduleid 123}</p>
oder blankes
{loadmoduleid 123}
irgendwo dazwischen?
Und auch mal den Editor in HTML-Ansicht umschalten, was da um den Shortcode drumrum ist.
Es passiert jedenfalls nichts, wenn man nur die JCE-Konfiguration umstellt. Man muss auch den Beitrag mindestens noch mal öffnen und vrmtl. neu speichern.
Vielleicht ja auch Cache?
Sonst weiß ich auch nicht weiter.
Das ist klar, dass das nicht valide ist. 2 meiner Erweiterungen, die so Shortcodes verwenden, entfernen die <p> bevor das Ergebnis-DIV dann auf der Seite ausgegeben wird, aber das ist keinesfalls performanter Code, nicht mehr empfohlen so Code, also mach ich das nicht mehr. Die Nachteile sind größer als die Vorteile. Damit das dann immer und verlässlich alle diese umgebenden <p> entfernt, wäre der Code noch komplexer und langsamer.
Und Abstand halt, wenn das CSS für <p> hier entsprechend greift. Und ein <p> hat ja normalerweise ein margin-bottom oder so was in der Art, damit die Absätze im Text Abstände haben Manchmal tut es nicht greifen.
Deshalb ist die JCE-Lösung schon nicht doof. Die <p> von Anfang an verhindern.
Das ist "normal" oder "war schon immer so".
JCE-editor bietet mittlerweile aber eine Einstellung, um so eingesetzte Tags der Art "{.....}" davor zu schützen, dass schon im Editor ein <p> drumrumgesetzt wird.
Ist allerdings ein wenig mit Vorsicht zu genießen, wenn man das bei Seiten aktiviert, wo man schon viele so Tags im Editor hat. Habe ich bei meiner Seite wieder deaktiviert 
Weiß aber nicht mehr genau warum. Ich schätze, weil dieser <p> ja auch einen "willkommenen" Abstand erzeugt und dann plötzlich überall auf der Seite diese Module am Folgeinhalt "kleben".
EDIT: Das ist die Einstellung (und ich sehe gerade, dass ich sie doch aktiviert habe):
Und im JCE-Editor-Text siehts dann so aus, zumindest, wenn visuelle Hilfen aktiviert ist (oder wie es heißt, wenn einem die Tags angezeigt werdn):
... falls man kein Standard-Joomla verwendet, wo z.B. noch nichts an Benutzer/Gruppenrechten verändert wurde oder keine Erweiterung installiert ist, die sich in Erweiterungs-Updates/-Installationen einmischt und ähnliches (wer weiß das schon gewiss?).
Andere sollten jedenfalls updaten. Egal, welche Joomla-Version. Auch 2.5 kann betroffen sein von einer entdeckten, eventuellen Lücke. = "es kann halt u.U. was passieren".
Code-Liebhaber werden die Fixes sicherlich schnell hier (Tabulator "Files changed") finden https://github.com/joomla/joomla-cms/compare/3.9.27...3.9.28
Selbstverständlich sollte jeder updaten, aber man weiß ja wie die Realitäten sind
Die Bezeichnungen "Laptop", "Desktop", "Smartphone" usw. sind mit modernem CSS teils ja sowieso Quatsch. "Laptop" bedeutet traditionell motiviert halt einen bestimmten Bereich größer und gleich 768Pixel.
Ein "Laptop" ist für das CSS kein Laptop, nur, weil es als Laptop verkauft wird. Es geht ja um darstellbare Pixel. Ein iPadPro (12,9 inch) fällt damit CSS-technisch in den Bereich "Desktop". Und auch schon das iPadPro (10,5 inch) mit seinen 834Pixel.
Reine Definitionssache. Letztlich zählt doch auch nur "Wie viel Platz habe ich auf dem Bildschirm".
Nachdem ich deine Frage noch mal gelesen habe, bin ich allerdings etwas ratlos, was auf deinem Apple eigentlich nicht passt
Weil letztlich beschreibst du ja selbes Verhalten wie JoomlaWunder und das ist ja korrekt so. Ein Ausschnitt wird angezeigt. Bei einem eigenen Bild muss man jetzt halt die CSS-Werte so verändern, dass der Ausschnitt passend ist.
Kurz: Screenshot.
Kannst ja mal hier mit background-size und den anderen rumspielen bis du einen Kompromiss findest. Man kann ja die size auch mit %-Werten für Höhe und Breite forcieren:
Im Netz finde ich mit DuckDuckGo mehrere Treffer mit Such-Eingabe "safari background cover bug". Habe ich nichts gelesen von. Aber scheint wohl einen zu geben oder gegeben zu haben. Safari ist ja eh Müll (aus Entwicklersicht).
Off Topic:
Ich dachte immer Warp und Helix sind 2 verschiedene Frameworks? Weil ich mich über
Theme von Warp, das unter dem Helix Framework läuft
wundere?
Nur, weil ein Template nicht mehr weiterentwickelt wird, muss man es doch nicht gleich entfernen/austauschen. Funktioniert es nicht mehr?
Das perfekte Template liegt im Auge des Betrachters/Benutzers. Der eine mag so, der andere so, auch, was der Umgang im Backend mit dem Template anbelangt.
Vielleicht fängst hier an: Woher bekomme ich Templates bzw. Themes für Joomla?
Und du bist sicher, dass, manchmal nach mühsamem Suchen, sich nirgends, meist am linken Rand, ein kleines Icon befindet, um die Sidebar wieder zu öffnen?
Wäre es dann nicht einfacher einen htaccess-Verzeichnisschutz anzulegen? Der Joomla-Offline-Modus hat sowieso ein paar Nachteile (eben, weil man dann ein angemeldeter User ist und kein allgemeiner).
Grundlegend kann man in der Konfiguration > Berechtigungen den Offlinezugang für Gruppen erlauben, aber dann muss der User eben auch in eine solche, vielleicht neue Gruppe, gepackt werden und Joomla-Anmeldedaten haben.
EDIT: Und da das flüchtige Bearbeiten von Benutzergruppenrechten in Joomla auch verheerende Folgen haben kann, spare ich mir das so oft als möglich.
Off topic:
Das Gute sind halt auch die Profile. Ich habe meist mehrere, besonders bei großen Seiten, wo ich z.B. in einem Profil die aufgeblähten /images/ ausschließe oder "nur Joomla-Core" oder "nur Images" und oder ... je nach Bedarf. Wenn die Archive der Profile dann auch noch spezifische Dateinamen haben, die alfabetisch korrekt sortiert sind, Datum am Anfang z.B., kann man beim Scrollen gut unterscheiden, welche Datei was war, wenn man so viele lokal aufhebt wie ich.
Auch, dass man die Archive als entpackbare ZIP speichern kann, wo sinnvoll. Da verwende ich aber meist EJB, wenns um "schnelle ZIPs" geht, um mal schnell auf lokal zu kopieren, z.B..
Der CSS-Validator prüft halt auf Standard-Validität. Da es aber Usus ist, auch sogenannte CSS-BrowserHacks (http://browserhacks.com/) und Vendor-Prefixe (https://ghsvs.de/programmierer…nd-scss#vendor_prefixes_2) in die Haupt-CSS-Datei einzubauen, anstatt zuvor zu ermitteln, um welchen Browser es sich handelt und dann ggf. für den eine eigene CSS-Datei zu laden, kommt es halt zu vielen Meldungen im Validator.
Man kann den aber auch etwas hinkonfigurieren, damit er nicht so dramatisches ignoriert.
Kurz: Kein Grund zur Sorge, soweit es sich nicht um "echte CSS-Fehler" handelt. Muss man sich bisschen "eingrooven" in die Thematik, was was ist bei den angezeigten Meldungen.
Das hat auch den Vorteil, dass die Backups nicht unnötig größer werden, da dann die Backups nicht im Backup enthalten sind.
Der eingetragene Backup-Ordner wird per se bei weiteren Backups ausgeschlossen (weshalb es auch blöd wäre, einen Joomla-Core-Ordner und nicht einen eigenen Unterordner daraus zu nehmen, wenn man wechselt). Backups blähen sich also nicht auf.
Verwendet man parallel Easy Joomla Backup, muss man halt in beiden Erweiterungen einen Ausschlussfilter eintragen, damit sie sich nicht gegenseitig aufblähen.
In akeeba ist das simpel, beliebige Ordner und Dateien auszuschließen. In der FREE von EJB bisschen Fieselei, wenns viele sein sollen und nicht nur die com_akeeba.
Gibt doch eine .htaccess
Außerdem haben alle Archivdateien einen wirren Zufalls-String hinten dran hängen. Also selbst, wenn die htaccess fehlt und der Ordner/Server nun nicht gerade so (dämlich) eingestellt ist, dass man die Datei-Liste im Browser einsehen kann, ist es kaum möglich, die Datei per Browser herunter zu laden, weil man den Dateinamen nicht rausbekommt. Auch, weil er einen Stunden-Minuten-Sekunden-String enthält. Wenn man jetzt auch noch "Backup archive name" etwas sinnvoller gestaltet als er im Standard ist, na ja usw....
Man muss schon auf einem extrem sch.... eingestellten Server sein, damit da Gefahr besteht.
besser einen eigenen Ordner auf meiner Webseite dafür erstellen soll
Nein. Das ist so zu verstehen, dass man einen Ordner AUSSERHALB des Webseitenverzeichnisses verwenden sollte, also AUSSERHALB des Joomla-Hauptverzeichnisses. Irgendwo, wo man keinen Zugriff via Browser darauf hat.
Ich persönlich halte das für übertriebene Paranoia in den allermeisten Fällen., da die Backup-Archive bereits ausreichend vor fremden Zugriffen geschützt sind.
Danke! Hab halt immer auf Buy geklickt und nur eine Fehlerseite statt Preis gesehen.
Soweit mit bekannt arbeitet der Entwickler gerade an einer Version für Joomla 4.
Vielleicht nennt er dann ja auch den Preis des Produktes irgendwo?
Ich frage mich auch immer, warum ich mir die Mühe mache, meine CSS-Dateien auch minifiziert in meine Erweiterungen und so zu packen, anstatt die Nutzer aufzufordern halt JCH-Plugin zu verwenden. Man kann das ja auch so konfigurieren, dass es eben nur CSS und JS verkleinert (und dann cached), falls anderweitige Probleme auftauchen mit JCH.
Würde die Sache für alle viel leichter machen. Gerade unter Joomla, wo man erst den Debug-Modus aktivieren muss, um die richtigen Stellen leichter zu finden.
Unmöglich finde ich "Pakete fürs Volk" wo nur minifizierte CSS-Dateien beiliegen im Download für die Dummies (wie mich) Dann lieber umgekehrt.
