Ich hab in meiner htaccess die bisher übliche mod rewrite-Einstellungen beibehalten, die von Joomla empfohlen sind.
"moderne" siehe mein Screenshot
Ach ja und danke an addi Hab das jetzt mal ausprobiert. In älteren Joomla-versionen gab es das wohl noch nicht.
Danke Astrid, jetzt funktioniert es auch bei mir.
Das WorkAround mit dem Menütyp URL hat aber leider auch zwei Nachteile, wie ich jetzt feststellen konnte:
1.) Mein MobileMenü zeigt, wenn ich auf der Seite "Inhalt" bin und das Menü neu ausklappen lasse, nicht an, dass ich auf der Seite Inhalt bin, sondern statt dessen auf "home".
2.) Ich möchte auf der rechten Seitenspalte zwei Module anzeigen lassen. Anscheinend verhindert Joomla dies, wenn der main content über eine URL eingefügt wird.
Und jetzt, wo ich wenigstens mal das Inhaltsverzeichnis angezeigt bekomme, hätte ich noch gern dessen Erscheinungsbild dem der restlichen Site angepasst:
Ich möchte der Darstellung des Inhalts, die von OSM als HTML geliefert wird, eine class zuweisen, durch die das ganze Inhaltsverzeichnis (wie alle meine Beiträge) in einem schattenbehafteten Rahmen angezeigt wird.
Im Menü selbst geht das nicht, aber wo sonst?
Den Font für body habe ich auf meiner neuen Experimental-Website prozentual definiert. Beim Ausprobieren per CSS fand ich heraus, dass es einen Sprung der Fontgröße gibt bei 98%. Gebe ich 97% ein, kommt in Chrome und Midori (=Safari) die Schrift in der gewünschten Höhe. In Firefox wird sie größer dargestellt, sodass es schon deutlich stört.
Ich habe dann versucht, es auf 96 und 95% zu setzen. Die Schrift bleibt dann in Chome und Midori immer noch auf der gewünschten Größe, aber die Größe in Firefox verringert sich nicht, wie ich angenommen hatte.
Würde ich aber noch kleiner werden, so wäre der Font in Chrome und Midori zu klein, wenn er in Firefox richtig wäre.
Link zur Experimental-Website:
Was tun? Sollte ich denn trotz Responsive Design die Fonts doch wieder in festen Pixeln angeben? Oder hilft das nicht gegen die jetzige Schwierigkeit?
Auf meiner neu installierten Experimentierseite sind die "modernen URLs" aktiviert, bei denen die Beitrags-IDs rausgefiltert werden. Nun habe ich in einer der Kategorien einen neuen Beitrag angelegt und diesen als Haupteintrag markiert. Er erscheint auch einwandfrei auf der Homepage. Aber die zugehörige URL führt zu einer 404 statt zur gewünschten Seite.
Der neue Beitrag hat – außer der Darstellung auf der Hauptseite – keinen Zugang z.B. über einen Menüpunkt.
Erst nachdem ich den Beitrag über einen Menüpunkt in einem Schattenmenü verlinkt habe, war der Fehler weg. Ich dachte, der Kunstgriff über das Schattenmenü wäre in der jetzigen Joomla-Version nicht mehr nötig?
Gibt es eine einfachere Möglichkeit als über ein Schattenmenü zu gehen?
Gerade hab ich OSMap free installiert und über einen Menüpunkt die HTML-Liste meiner Webseiten anzeigen lassen wollen. Wenn ich den Menüpunkt anklicke, erhalte ich eine 404-Seite.
Gehe ich im Backend auf das Editieren der von OSMap erstellten Sitemap, so sind alle Seiten-URLs dort richtig aufgeführt. Und natürlich ist die Sitemap "veröffentlicht".
Nun weiß ich nicht, wie ich den Fehler beheben kann. Denn was nicht angezeigt wird, kann ich schlecht untersuchen.
Aaaachhhh, das Leben kann doch auch mal so einfach sein!
Herzlichen Dank sag ich dir!
Von w3schools hatte ich ein responsive Design mit zwei gleich langen Spalten, die sich selbst anpassen. Das zugehörige CSS sieht so aus:
.column-cl {
float: left;
width: 100%;
box-sizing: border-box;
}
.right-cl {
padding-right: 1.2em;
}
.left-cl {
padding-left: 1.2em;
}
/* Clear floats after the columns */
.row-cl:after {
content: "";
display: table;
clear: both;
}
/* Oberhalb von 800px soll zweispaltig dargestellt werden */
@media screen and (min-width: 800px) {
.column-cl {
width: 50%;
}
}Mit den beiden von mir zusätzlich eingeführten Klassen left-cl und right-cl will ich dafür sorgen, dass bei zweispaltiger Darstellung zwischen den beiden Spalten ein Abstand bleibt. Im HTML habe ich also beide Klassen für eine div-Spalte verwendet:
<div class="column-cl right-cl">
und für die zweite Spalte natürlich:
<div class="column-cl left-cl"> Jetzt habe ich mir damit aber das Problem eingehandelt, dass bei einspaltiger Darstellung immer der Text, der sonst die erste Spalte bildet, eine um die Einrückung kürzere Zeilenlänge hat und der Text, der sonst in der zweiten Spalte stehen würde, ist deutlich sichtbar nach rechts eingerückt.
Ich könnte natürlich für beide Spalten ein padding nach links und rechts verwenden. Dann aber ist der Text gegenüber den meistens nicht in Spalten stehenden Überschriften eingerückt. Und zudem würde unnötig Platz verschwendet, wenn der Beitrag auf einem kleinen Display gezeigt wird.
Gibt es in diesem Code-Beispiel eine Möglichkeit, statt zwei eben drei Spalten zu erzeugen, wobei dann die zweite Spalte leer bleiben würde und sehr schmal wäre, um den Abstand zwischen den Spalten eins und drei zu halten. Spalten 1 und 3 würden wie bisher den Text beinhalten.
Da die mittlere (Abstandshalter-)Spalte inhaltsleer bleibt, würde sie automatisch auf Null zusammen fallen, wenn der Text aufgrund der @media-Regel wieder einspaltig gezeigt werden soll.
So weit meine Überlegungen. Vielleicht gibt es noch einfachere Lösungen?
Jedenfalls reicht mein CSS-KnowHow nicht aus, hier eine Lösung zu finden und so würde ich mich über Lösungs-Ideen freuen.
Entscheidend ist das Zusammenspiel von Bildgrößen und dazu passenden @media Pixelwerten und das auch wieder abgestimmt auf die gesonderten @media-Regeln für die Umschaltung zwischen "mit Randspalte" und "ohne Randspalte".
Mit sehr viel Experiementieren und drei verschiedenen Bildgrößen mit vier @media-Konditionen sieht es jetzt ziemlich gut aus.
Allerdings darf kein Bild in einem zweispaltig angelegten Beitrag in einer der beiden Spalten stehen (also ein sehr schmales Bild) und dies soll dann auch noch sowohl dann funktionieren, wenn der main-content zusammen mit einer rechten Spalte steht als auch dann, wenn diese Spalte weg fällt. Die dann auftretenden Sprünge in den Bildbreiten lassen sich auch nicht mehr mit object-fit weg bekommen.
Nun brauche ich keine Anregungen mehr zu diesem Thema. Danke!
Ich habe das verflixte Problem, dass bei einspaltiger Darstellung des main-content die im Beitrag führenden Bilder viel zu groß werden, besonders die Höhe. Ich könnte z.B. bei der Aufnahme der Fotos schon darauf achten, dass links und rechts genug übrig bleibt, um auch Seitenverhältnisse von bis zu 1 : 4,3 verwirklichen zu können. Das ist aber bei vielen Motiven nicht immer machbar!
Ich könnte aber auch den Beitrag bei kleiner Screenwidth einspaltig zeigen und ab einer nächsten Breite zweispaltig und ab der darauf folgenden Breite wieder einspaltig, aber dann mit einer Haupt- und einer Seitenspalte in 2/3 zu 1/3 geteilt. Und wenn's noch breiter wird, den Beitrag wieder zweispaltig darstellen.
Dabei würde das Bild bei zweispaltiger Darstellung des Beitrags nur in einer Spalte erscheinen.
Wenn diese Unterteilung mit @media gelingen würde, benötige ich wahrscheinlich nur zwei verschiedene Seitenverhältnisse des gleichen Bildes und würde dennoch die Ladezeit und den Datentransfer für den Besucher gering halten.
Beispiele (ACHTUNG: reine Experimentier-Website)
Wie kriege ich das nun in mehreren @media-Regeln untergebracht? Oder muss ich für jede Darstellungsgröße eine eigene Klasse für das Bild definieren, die dann bei Nicht-Erfüllung der Bedingung @media auf display: none gesetzt wird?
Kleine Ergänzungsfrage: Ich könnte ja mit object-fit: cover arbeiten. Aber dann müsste ich ein relativ großes Bild (Ladezeiten) laden, damit bei kleinen Screenwidth der gewünschte Effekt eines Bildausschnitt wirksam wird.
Hab schon mit folgendem experimentiert:
.cover-cl {
object-fit: cover;
max-width: 100%;
height: 230px;
}Sieht gut aus, wenn ein genügend großes Bild geladen wird UND wenn das Bild-Wichtige möglichst in der Bildmitte steht und nicht nach der Drittel-Regel weiter außen liegt.
Wähle ich die Bilder schon vorher mit der @media-Kondition so aus, dass nichts überflüssig Großes geladen wird, sieht's eher mickrig aus.
Die Leading-Klassen werden aber offensichtlich per PHP oder JS gesetzt, zumal sie ja bei Blogs fortlaufend nummeriert sind. Ich finde, da ist es ungünstig, einzugreifen.
Also setze ich besser den joomla-eigenen Readmore, damit die Unterteilung in den Einleitungstext usw. klappt. Dann blende ich den Readmore-Button per Menüpunkt-Vorgabe aus und setze meinen eigenen Button, der einfach nur eine Verlinkung zum Beitrag darstellt.
Damit der aber nicht die Vollansicht des Beitrag stört, müsste ich in CSS definieren, dass der Button innerhalb eines Containers der Klasse item-page nicht angezeigt wird. (display: none;)
Mache ich das mit
.itempage.btn oder
.itempage .btn ??
Hier für andere Interessenten die Lösung:
.article-head ist die Klasse für meinen Rahmen mit Schatten, der um den Beitrag herum laufen und den selbstgemachten Readmore-Button umschließen soll.
.item-page ist die von Joomla generierte Klasse, wenn ein Beitrag im Vollformat angezeigt wird.
.btn ist die template-eigene Klasse für Buttons
.btn-cl ist mein separater Button mit fast den gleichen Definitionen, wie der vom Template (Protostar).
Den Template-Button darf ich nicht nehmen, weil ich den nicht frei umdefinieren kann. Mein Button soll also in der Beitragsvorschau erscheinen, aber nicht, wenn der Beitrag im Vollformat gezeigt wird, also item-page aktiv ist.
.article-head .btn-cl {
margin: 0px 15px 10px 0px;
}
.item-page .btn-cl {
display: none;
} Funktioniert prima
Hab gerade die von dir genannten 5% auf 0% gesetzt. Du kannst es ja mal anschauen. Das Ergebnis zeigt immer noch die gleiche Problematik, nur sitzt der joomla-systemeigene Readmore-Button jetzt dicht am unteren Rand des Schatten.
Deshalb schrieb ich ja, dass ich annehmen muss, dass du mich nicht verstanden hast mit meinem Anliegen: Der joomla-eigene Readmore-Button soll INNERHALB des schattierten Rahmen positioniert sein.
In dem Einleitungstext des Beitrag "über mich" habe ich einen selbst erstellten Button "innerhalb" des schattierten Rahmen eingefügt. Dessen Nachteil im Gegensatz zum joomla-eigenen Readmore: Der selbst erstellte Button verschwindet nicht, wenn der Artikel vollständig angezeigt wird.
Ich glaube, du hast mein Anliegen nicht verstanden und sehe auch nicht, wie meine viewport-css die derzeitige Position der Buttons verändert. Hab's sogar gerade noch mal mit Firefox kontrolliert.
Der von mir definierte div-Container mit dem schattierten Rahmen soll den Readmore-Button umschließen, wenn der Beitrag nur mit dem Einleitungstext, also im Blog-Layout angezeigt wird. Und das tut es zurzeit nicht.
Entweder kriege ich es hin, den div-Container so zu starten, dass Readmore-Button immer innerhalb liegt, oder ich muss ihn zwar setzen, aber ausblenden und meinen eigenen Readmore-Button erstellen (wie im zweiten Beitrag im o.g. Link). Dieser selbst erstellte Button muss aber ausgeblendet werden, wenn der Beitrag dann nach dem Klick auf den Button in vollem Umfang dargestellt wird.
Derzeit arbeite ich an einem Redesign meiner Website und möchte die Beiträge in div-Boxen erscheinen lassen, die mir eine Umrandung mit Schattierung geben. Den div-container definiere ich zu Beginn des Beitrags ganz zu Anfang und schließe mit </div> ganz am Ende des Beitrag. Das funzt auch schon prima und das Gesamtbild gefällt mir.
Probleme macht mir dabei die Positionierung des Readmore-Button wie man hier sehen kann:
Im Blog-Layout werden ja nur die Einleitungstexte der Beiträge gezeigt. Und auch diese erhalten die Umrandung mit Schattierung. Leider liegt dann der standardmäßige Readmore-Button sehr störend weit unterhalb des unteren schattierten Rand und wirkt so, als ob er nicht mehr zu dem Beitrag gehören würde.
Im o.g. verlinkten Beispiel habe ich im unteren der beiden Beiträge versucht, einen eigenen Readmore-Button zu erstellen und dachte, ich könnte ja über die Menü-Einstellung den standardmäßigen Readmore-Button ausblenden. Das würde zwar im BlogLayout funktionieren. Aber sobald der Beitrag dann ganz geöffnet wird, bleibt natürlich der von mir generierte Readmore-Button unterhalb des Einleitungstext stehen, während der standardmäßige Readmore-Button dann nicht angezeigt wird.
Oder müsste ich den schattierten Rahmen an anderer Stelle, z.B. in der index.php des Template definieren? Zu Beginn jedes Beitrags im BlogLayout sehe ich im HTML
div class="leading-0" itemprop="blogPost".....Natürlich wird das durch die index.php des Template eingefügt. Aber dies könnte eine Eingriffsmöglichkeit sein, oder?
Klicke ich auf ReadMore, und der Beitrag wird voll angezeigt, sehe ich statt dessen im HTML
div class="item-page" itemprop=""Also ist die Idee, in die index.php des Template einzugreifen, doch falsch?
Oder ich versuche, den von mir selbst gebauten ReadmoreButton immer dann verschwinden zu lassen, wenn die Klasse für den Beitragscontainer auf "item-page" wechselt? – Aber wie müsste dann das CSS dazu defineirt werden? Vielleicht so:
.item-page.rm-button {display: none;}
/* wobei dann rm-button für meinen Readmore-Button stehen würde */Was tun?
Liebe Astrid! Herzlichen Dank für deinen wertvollen Hinweis. Der kommt gerade rechtzeitig, weil ich jetzt den Auftrag für die Lightbox vergeben habe. So konnte ich deine Links an ihn weiter geben.
Ich überlasse ihm die Entscheidung, welches der Scripte aktueller und qualitativ besser oder auch leichter anpassbar ist.
Jedenfalls finde ich die von dir empfohlene glightbox als sehr elegant. Macht einen positiven Eindruck. Leider hab ich keine Zeit mehr, mich darum zu kümmern.
Vielen Dank addi !
Die Schwierigkeit betr. dieser Lightbox sehe ich, genau wie bei der von RokBox / Rocket Theme darin, dass die Definition einiger Klassen, die die Größe der content-box bestimmen, dynamisch durch Berechnungen des Script bestimmt werden.
Das Script erkennt die Screen-dimensions sowie die Geräteklasse und errechnet individuelle Klassendefinitionen und dies auch abhängig davon, welche Art von Mediadata in die Content-Box geladen werden soll. Das sieht man auch daran, dass ein Joomla-Beitrag, den ich auf dem Desktop öffne, seinen Hintergrund behält, während bei Darstellung auf dem Smartphone plötzlich der Hintergrund fast schwarz ist.
Ich habe sogar versucht, im Script an den bei Videowiedergabe benutzten Dimensions der Content-Box etwas zu verändern. (Zeilen 60 und 61 sowie 108 und 109) bzw. in meiner geänderten JS Zeilen 66 + 67 plus 114 + 115)
Zwar habe ich jetzt ein schönes großes Video, aber mit dem Start des Containers auch ein Mis-Placement des Container nach rechts unten. Dieses korrigiert sich von selbst, wenn bei geöffneter Lightbox die Breite des Browserfenster verändert wird. Klar, denn dann erfolgt eine Neuberechnung.
Ich glaube, das ist was für JS Spezialisten. 
addi und JoomlaWunder
Ich danke euch herzlich für euer Engagement!
Meine Antwort hier ist irgendwie verloren gegangen.
Inzwischen hatte ich die von addi verlinkte Accordion-Lösung ausprobiert. Und die funktionierte mitsamt autocollapse auf Anhieb.
Für mich ist zwar damit die Aufgabe gelöst. Allerdings sehe ich, sobald ein Upgrade auf Joomla 4 erfolgt und somit auf eine neue Version des Bootstrap, werde ich evtl. erneut solche Schwierigkeiten bekommen können.
Naja bis dahin ist ja noch Zeit
Na das ist ja mal wieder echt krass! Ich hab im Firefox das Addon ClearCache, damit mir der Browser nicht längst geänderten Code interpretiert. Und trotzdem geschieht genau dies! – Tja mein Anfängerfehler... immer wieder neu!
Ich danke dir für deinen Hinweis. Ich hab mir die Lightbox jetzt mal in Midori angeschaut und sie funktioniert auf Anhieb... — aber leider zeigt sie das Video nicht mit voller Viewportbreite (max-width: 100%) Aber bei mir wird der Schließen-Button oben rechts korrekt angezeigt! Der HTML-5-Audioplayer wird vor einer viel zu großen schwarzen Fläche gezeigt. Text von Joomla-Beiträgen werden korrekt angezeigt.
Auf den von mir unter Android getesteten Mobil-Browsern fehlt dieser Button. Aber auf allen Browsern spielt das Video endlich ohne Fehlermeldungen oder sonstigen Ärger einwandfrei ab! Das Video wird mit voller Viewportbreite dargestellt. Im Querformat des Video bleibt aber dann kein Platz mehr für den Schließen-Button, sodass der Betrachter leider ratlos sein wird, wie er das Dingens wieder schließen kann.
Und Text wird auf dunklem Hintergrund kaum lesbar gezeigt, während dies beim Desktop-Browser so funzt wie gewünscht.
Wenn es mir gelingt, diese Darstellungsfehler zu korrigieren, habe ich hier endlich eine zuverlässige Lightbox für jeden medialen Inhalt gefunden, die auch auf Mobilgeräten einwandfrei funktioniert. – OK auf Apfelgeräten kann ich nicht testen.
Noch während ich dies schreibe, erhalte ich die Mitteilung, dass eine weitere Antwort hier eingegangen ist. Mal schauen...
Leider kann ich das, was du hinter dem Spoiler verborgen hast, nicht sehen. Evtl. ein falscher Link?
Der Font hatte tatsächlich einen falschen Pfad in der lightcase.css und der überschrieb mir den von mir korrekt angelegten Pfad in einer anderen css-Datei. Das X kommt jetzt sicher.
Mit der Anpassung gemäß meiner oben genannten Wünsche habe ich für mich unlösbare Probleme, da z.B. die Größe der Content-Box, ähnlich wie in RokBox, per JS dynamisch berechnet wird.
Und weil ich mich mit JS zu wenig auskenne (praktisch gar nicht), kann ich da nicht sinnvoll daran herum ändern.
Es sieht danach aus, dass ich hierfür doch noch einen Dienstleister beauftragen muss.
Lange hab ich mit RokBox als Alternative zur JCE-Mediabox experimentiert. Eigentlich läuft die Rokbox ja auch prima, benötigt aber für die Darstellung von Videos auf Mobilgeräten noch ziemlich Anpassungen. Jedenfalls sind die bisherigen Ergebnisse – besonders auf Mobilgeräten – erheblich besser, als mit JCE-Mediabox.
Die nötigen Optimierungsarbeiten an der RokBox beziehen sich aber auf die Verwendung von Mootool-JS und die sind ja für Joomla ziemlich out, wenn ich das recht verstanden habe.
Deshalb habe ich durch Recherchen eine neue Lightbox / Modalbox gefunden, die gemäß deren Demo-Website und gemäß deren Dokumentation für mich brauchbar wäre und moderne Scripte verwendet. Es nennt sich Lightbox.js und findet sich hier.
Ich habe genau nach Anleitung die Scripte mittels Ergänzung der index.php des Template eingebunden und ebenso die CSS per @import in die template.css (Ich verwende aktuell Protostar). Auch an den lightcase-Font habe ich gedacht.
Leider ist das Ergebnis nun gar nicht so, wie es so hübsch auf der Demo-Seite gezeigt wird. Vor allem lässt sich die einmal geöffnete Lightbox nur noch über den Zurück-Button des Browsers schließen. Weiteres habe ich auf meiner Test-Website beschrieben, die sich hier befindet:
Ich wünsche mir, dass jemand sich auf meine Testseite traut und mir evtl. die rettenden Ideen bringt. 
addi Dir ist aber wohl nicht klar, dass es sich hier um eine reine Test- oder Experimentier-Website handelt?
Es geht ausschließlich um die technischen Funktionen.
Aber vielleicht hast du ja eine Idee, wie "auto-close" gelöst werden kann?
Immerhin haben wir bisher zwei Codevarianten für das Accordion und beide haben das gleiche Problem. Und für die hier diskutierte gibt es sogar eine funktionierende Demo bei w3schools.com
Sind unter Joomla-4 Konflikte absehbar, wenn eine Extension mit Mootools arbeitet?
Konkret frage ich wegen des PlugIn RokBox von RocketTheme.com Die Entwickler versichern, dass sie ihre aktuellen Templates (in denen meist auch das PlugIn RokBox enthalten ist) auf Joomla-4 anpassen werden.
RokBox ist eine leistungsfähige Modalbox, weil per Script nicht nur die Screen-Abmessungen abgefragt werden und die Größe der Contentbox eigenständig berechnet wird, sondern auch die Geräteklasse berücksichtigt wird. Ich würde sie gerne als Ersatz für JCE-Mediabox verwenden, da die JCE-Mediabox bei der Darstellung von Videos auf Mobilgeräten Probleme macht.
Leider arbeitet die RokBox mit Mootools statt mit jQuery.