$tpath = JPATH_THEMES . '/' . $tname;
Der Ansatz ist generell falsch, weil JPATH_THEMES der absolute Serverpfad ist und nicht einer, den man für Links im HTML oder ähnlich verwendet.
$tpath = JUri::root(true) . '/templates/' . $tname;Das ist dann aber wieder komplett nicht nachvollziehbar,
Hängt doch auch davon ab, wie die Erweiterungen das laden. Wenn joomlakonform, kann man das sicherlich irgendwie so:
https://www.ghsvs.de/programmi…entfernen-mootools-jquery
Wenn nicht, vielleicht so: https://kubik-rubik.de/jcc-js-css-control
Meine mich zu erinnern, dass auch JQuery Easy das Filtern irgendwie konnte. Habe ich mich aber nicht mehr mit beschäftigt.
Dann werden viele Fonts ja über JS geladen, bspw. die Google-Map lädt zwanghaft Roboto.
Ich würde diese gerne zusammenfassen, wenn ich aber die Quelle lösche und den Font im CSS setze, so funktioniert das nicht so recht. ... /templates/theme/fonts/
Hängt halt davon ab, wo du das versuchst. Auf XAMPP ist der Pfad halt nicht richtig.
Deshalb sollte man in solchen Fällen den Pfad immer mit
Uri::root(true)generieren, damit der garantiert richtig landet. Dafür brauchst natürlich PHP in Joomla-Umgebung.
Ich meine neulich hier irgendwo mitbekommen zu haben, dass dieser PageBuilder mittlerweile auch gänzlich ohne Joomla-Beiträge auskommt. Wäre also eher eine Frage für deren Forum, wenn dem beim TE so ist. "Hat ja eigentlich mit Joomla nichts zu tun." 
früher war ich immer bei joomlaportal - das schein wohl offline zu sein - oder?
So meinte ich das
Joomla selbst setzt im Normalfall nur dann Canonicals, wenn was im Plugin "System - SEF" in Feld "Website-Domain" eingetragen ist. Ansonsten ist das eine zuinstallierte Erweiterung.
Und den Status zeigst du in normalen Joomla-Beiträgen an oder...?
Das kommt darauf an, ob du die Unterdateien auch overriden willst, sonst wird halt z.B. die default_component.php genommen und eine sonstwas_component.php ignoriert, falls angelegt und nicht geändert.
Oder anders: Wenn du nur was in der Basis-Datei sonstwas.php ändern willst, musst nix weiter tun. Noch nicht mal für die anderen Dateien Overrides anlegen.
Das ist eigentlich nur möglich, wenn die configuration.php zurückgesetzt wird, also jemand/etwas zur Datei Zugang hat, sei es über Webspace oder Joomla-Backend.
Die Seite läuft ganz normal und es wurde auch kein Update durchgeführt.
Nenn doch mal die Versionen etc. Siehe Forenregeln.
b. es im Grunde für meine Seite nicht notwendig ist, sich registrieren zu koennen;
Dann schalt "Benutzerregistrieung" in der Konfiguration für Komponente "Benutzer" aus und alles ist gut.
Sollte da irgendein Modul laufen, dass sein eigenes Ding macht, das ebenfalls deaktivieren. Joomla selbst hat kein eigenes Registrierungs-Modul. Wäre also ein zuinstalliertes, wenn.
Auf der Joomla-Seite - frisch installiert sieht man oben den Link zur LOGIN-Möglichkeit
Das ist ja dann ein anderes Ding. Da musst halt das Anmelden-Modul auch noch deaktivieren. Welches das auch immer ist. Hat aber nicht direkt mit Registrierung zu tun. Bereits registrierte User (z.B. du) können sich dann halt auch im FE einloggen, wozu auch immer. Bzgl. Sicherheit bist dann du selbst gefragt wie sicher deine Passworte sind.
Hatemile ist ein Firefox-Plugin https://hatemile.github.io/projects/hatemile_for_browser/
Hab ich garantiert nicht als AddOn installiert. Glaubs deshalb nicht
Liest der Screenreader nicht einfach das title-Attribut des Links aus?
Mag schon sein (keine Ahnung), aber dann fehlt der Hinweis auf Neue Seite. Mein Credo ist in solchen Fällen, warum kompliziert, wenns einfach geht.
Und ältere Schrott-Browser benötigen 1 Zeile mehr:
a .force-read-before {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}Das ist dann das Äquivalent zu .sr-only in Bootstrap, wenn auch nicht ganz vollständig, weil der Focus-Teil fehlt. Das aber nur nebenbei.
Das hat was mit Barrierefreiheit zu tun und es fehlt einfach passendes CSS. Das ist schon richtig so. Füge das am Ende deiner CSS-Datei ein:
a .force-read-before {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}Dann wird z.B. sehgeschwächten Screenreader-Nutzern das vorgelesen, die Titelattribut des Links nicht sehen können bzw. nicht vorbereitet sind, dass Link ein neues Fenster öffnet.
Ich kann das auch auf IE 11 (der einzige IE, der, wenn überhaupt noch zu berücksichtigen ist) nicht nachvollziehen. Ich seh aber auch keine Seite, die irgenwie so aussieht, wie deine Bilder (grauer Hintergrund und so). Müsstest also den korrekten Link posten.
Ich würde den IE ignorieren.
Ich Depp habe gerade wieder gelernt, dass man das als Dienstleister unbedingt im Angebot erwähnen muss, dass IE11-Anpassungen mehr kosten
Viele Firmen bleiben hartnäckig und ich habe gerade 2 Tage Mehrarbeit hinter mir, ein "schickes" Bootstrap-4-Template für IE11 nachzubessern, weil Microsoft den IE-Müll zwar noch supportet, aber sich seit Jahren weigert, zahlreiche flex-Bugs zu korrigieren, Features, die u.a. das Arbeiten mit Bootstrap-4 eben so "schick" machen.
Unterhalb IE11 ist aber tatsächlich "tot" und man sollte als Dienstleister eher verweigern, Seiten dafür zu erstellen, als für unsichere Versionen zu arbeiten.
Statt deinen kopierten Override default.php zu nennen, gibst du ihm einen anderen Namen, bspw.
sonstwas.php,
sonstwas_component.php
usw..
Im Menümodul kannst dann "sonstwas" im Feld "Layout" auswählen.
So kannst diverse Alternative Layouts anlegen. Klappt für (fast) alle Module.
Bei mod_menu muss man noch beachten, dass in der Basisdatei "sonstwas.php" diese 2 Stellen angepasst werden müssen
getLayoutPath('mod_menu', 'default_ ...usw..."default" durch "sonstwas" ersetzen.
In einem Override kann man auch so machen machen. Ich geh von einem Template-Override der Original-Joomla von
/components/com_content/views/featured/tmpl/default_item aus:
Da findet sich
<?php echo $this->item->introtext; ?>Da macht man draus
<?php
$Limit = 250;
echo JHtml::_(
'string.truncateComplex',
$this->item->introtext,
$Limit
);
?>$Limit ist dabei die gewünschte, maximale Länge.
ODER:
<?php
$Limit = 250;
echo JHtml::_(
'string.truncate',
$this->item->introtext,
$Limit
);
?>Erste Variante (truncateComplex) erhält die HTML-Tags, bspw. Links, Überschriften und Absätze im Text, hat aber die unschöne Eigenart, dass die abschließenden 3 Pünktchen (...) in einer neuen Zeile erscheinen. Braucht man dann wieder zusätzlichen Code (zu faul).
Zweite (truncate) entfernt alle Tags ist also gut geeignet, wenn der Introtext puristisch gehalten wird. Einfach stinknormale Absätze.
Erst das RokCommon Plugin aktualisieren auf Mindest-Version 3.2.6. Aktuelle ist 3.2.8, geht also.
Dann erst das RokSprocket.
Deshalb ist es immer gut Fehlermeldungen in voller Länge zu posten. Hätte mir etwas Code-Wühlerei erspart
So irgendwie wird die Melsung aussehen:
ZitatRokSprocket needs at least RokCommon version 3.2.6. You currently have RokCommon version %s
Nun habe ich im Verzeichnis mod_login eine dritte default.php (versehen mit dem Datum von heute), mit der ich nichts anfangen kann.
Wenn du einen neuen Override anlegst via Backend-Geklicke und schon einer da ist, erhält der neue eine Datumsmarkierung.
Ich muss aber zugeben, dass mir die Sinnhaftigkeit dahinter nicht wirklich klar ist Irgendwo werden einem die Unterschiede der Overrides zu Original angezeigt. Aber wie gesagt blick ich nicht wirklich zu welchem Original eigentlich und wozu.
Aber du kannst die Dateien löschen und fängst dann mit einem neuen Override an. Der heißt dann wieder default.php und ist frisch.
Könntet ihr bitte prüfen, welche Cookies auf meinen Seiten aktiviert werden.
Für den Firefox gibt es das kostenlose AddOn "Cookie Quick Manager". Damit kann man sehr gut die Cookies identfizieren, die dein Browser so sammelt.
Klickerst also die Seiten einfach mal durch, nachdem du die Cookies alle gelöscht hast. Dann siehst, welche neu erscheinen.