Beiträge von Re:Later

    Ja. Trotzdem werden auch im Joomla-3.6.0-Core (Frontend) nach wie vor noch Zeilen der oben genannten Art verwendet, die eben ALLE select-Boxen der jeweils angezeigten Seite umwandeln.


    Ein paar Views und Module wurden entschärft, wie z.B. Sprachauswahl, die ja meist auf allen Seiten angezeigt wird.


    Das ist ein sauguter Schritt, war aber zuvor durch Overrides auch schon möglich.


    Großer Vorteil der Chosen-Boxen ist ja das Suchfeld bei vielen Einträgen. Ich sehe eher selten die Notwendigkeit.

    Na ja, Templateersteller gehen vielleicht ja auch davon aus, dass man das Joomla-Feature
    Erweiterungen > Templates > OptionenButton klicken > Vorschau von Modulpositionen aktivieren
    kennt, das es seit Joomla 1.5 gibt (oder sogar länger).


    Beschreibung des Features durch Mouseover über das Label des Einstellfeldes.


    Weiters hilft oft ein Blick in die templateDetails.xml von Templates, um sich zu orientieren.
    Und in die index.php des Templates, wohin die Positionen vom Macher verteilt wurden


    Es gibt bzgl. Modulpositions-Bezeichnungen schon lange keinen Pseudo-"Standard" mehr (es gab diesbzgl. nie einen). Ein position-0 kann zusätzlich vom Templatemacher irgendwo eingesetzt werden usw. und beliebig benannt werden per Sprachfiles oder kann auch komplett fehlen.
    Früher wars halt so, dass mehr Templates sich öfter bemühten die Demodaten, die man mit Joomla zusammen installieren kann, verwendet werden und das schloss eben Modulpositionen mit ein.


    Wenn du Joomla-Demodaten installierst, wirst auch feststellen, dass du mehrere Menü-Module an unterschiedlichsten ModulPositionen findest, teils sogar an "leeren" Positionen für Templates, die gar nicht mehr mit Joomla zusammen ausgeliefert werden.


    Das Ganze hat je nach Betrachtungsweise Vor- und Nachteile. Ich sehe mehr Vorteile...

    Ja, ist bisschen nervig gelegentlich zu überlisten.


    Diese Zeile kann überall in Joomla verwendet werden, wirkt dann aber für die ganze angezeigte Seite. Sagen wir, irgendein Modul, das du auf der Archiv-Seitezusätzlich einsetzt, hätte gern so Dropdowns und hat deshalb diese Zeile im eigenen Code. Dann wird leider auch deine Archivauswahl wieder mitgestylt.


    Dann kannst am Ende des Overrides der default.php noch den Code hier einsetzen. Dann verschwindet der Stil wieder für die Archivauswahl.

    Code
    1. <script>;(function($){$(window).load(function(){ $('#month, #year, #limit').chosen('destroy');});})(jQuery);</script>


    oder etwas radikaler für alle Selectboxen der Seite, also auch das Modul

    Code
    1. <script>
    2. ;(function($){
    3. $(window).load(function(){
    4. $('select').chosen('destroy');
    5. });
    6. })(jQuery);
    7. </script>


    Könnte man ja denken, dann setze ich doch gleich diesen Code präventiv ein, z.B. gleich am Ende der Template-index.php, damits für alle Seiten gilt. Denkste nur. Wenn die Dropdowns einer Seite nämlich NICHT durch besagte Zeile gestylt wurden, dann führt dieser Blockier-Code zu einer merkwürdig kollabierenden Seite mit einem Riesendropdown ohne Einträge quer über den ganzen Bildschirm.


    Hülfe also z.B. für den Archiv-Override nur, die JHtml-Zeile drin lassen und zusätzlich den Code-Block einsetzen, um auf Nummer sicher zu gehen.


    Deshalb nervig ;-)


    Auf umfangreicheren Seiten kann das zu einem Teufelskreiskreiskreis werden... Deshalb hab ich mir ein Plugin geschrieben, dass die Chosenzeile komplett per PHP abfängt/verbietet, ohne, dass ich überall was entfernen oder hinzufügen muss. Chosen einfach verboten bei mir im Frontend ;-)

    Schuld daran ist eine Zeile

    Code
    1. JHtml::_('formbehavior.chosen', 'select');


    Schau mal im Templateordner, ob dort ein Template-Override liegt
    /Joomla/templates/stammbaummainpage/html/com_content/archive/default.php
    wo die drin ist und deaktivier die Zeile. Ob's dir dann besser gefällt. Mir mal schon ;-)


    Ansonsten musst für diese Datei einen Template-Override anlegen, wo du Zeile dann entfernst und 3x Holz kann nicht schaden ;-)


    Sonst wirds bisschen Fieselfiesel, wenn du diese Chosen-Optik doch weiter verwenden willst.

    Das ist eine uralte PHP-Version und nicht geeignet für Joomla. Eigentlich für gar nix mehr geeignet ;-)


    Frag den Provider, warum da plötzlich PHP4 läuft.


    - Wenn es eine Joomla 3.5.x ist nimm PHP7 oder PHP5.6.


    - Egal, welche Joomla-Version, geh nicht unter PHP5.4. (auch gerade noch akzeptabel für Joomla 3).


    - Alles unterhalb Joomla3.5 darf NICHT PHP7 sein.

    Es gehört zum guten Ton in Foren Crosspostings zu unterlassen oder wenigstens darauf hinzuweisen:
    http://www.joomlaportal.de/joo…ages-xx-xxxxxxxxx-ht.html


    Geh Backend > System > Systeminformationen > Tabulator Systeminformationen und poste die paar Zeilen hier.


    Wenn du auch dort nicht mehr reinkommst, nenne die PHP-Version, die im Joomla-Ordner aktiv ist.


    Bei Unsicherheit. Erstelle im Joomlaverzeichnis eine Datei i.php mit Inhalt

    PHP
    1. <?php
    2. phpinfo();


    und rufe auf.
    example.org/i.php
    Lösche Datei danach wieder.

    Zu Beez3: Reagiert gerade bzgl. Menüs in einigen oberen Modulpositionen extrem zickig. Das gezeigte Phänomen ist altbekannt und kaum zeiteffizient lösbar, wenn du das Menü nicht an anderer Modulposition einsetzt. Dann musst aber wieder andern CSS-Kram lösen.


    Kurz: Topmenü: 1 Ebene in Beez3 und damit basta ;-)


    Bei Beez3 geht es mehr um Accessibility-Aspekte und man sollte nach Möglichkeit mit dem leben, was es mitbringt und "vorschlägt" oder sich eben anderweitig umschauen.


    3.5.x ist vollkommen unschuldig ;-) Alles wie immer... nur mit ein bisschen mehr...

    Also ich MUSS desöfteren z.B. mit templatemonster und Templates anderer Schmieden arbeiten. Klar sind die Demos komplett zugeballert. Diese sollen ja alle möglichen Elemente, Features etc. zeigen, die möglich sind (viele sind auch unmöglich selbst zu pflegen ;-) ). Und zugeballert wurden sie nicht von wirklichen Joomlafachleuten. Darf man nie vergessen dabei, wenn man im Backend dann gelegentlich das kalte Kot... bekommt!


    Die Agenturen, die mir die Templates vorgeben, sichten die Möglichkeiten nach ihren Plänen, was denn auf der Seite für einen Kunden eigentlich sein soll/muss. Also eher umgekehrt. Nicht, mit was fülle ich denn jetzt noch diesen Bereich? Sondern, was wollen wir auf der Seite darstellen und mit was sieht das am passenden aus und welche Bereiche des Demos können eh gleich raus. Daraus bauen die mir ein Screendesign, schneiden also einfach passende Bereiche des Demos als Grafiken aus und "kleben" mir die als Vorlage neu zusammen (natürlich mit reichlich Nacharbeit, programmiertechnischen Rattenschwänzen und heftigen Diskussionen ;-) ).


    Am Ende bleibt von einem solchen Demo keine 2% (auch was Module, sonstige Erweiterungen anbelangt) übrig und die Startseite ist mit paar mal wischen durch statt 100x. Das Templatedesign gewährleistet eigentlich nur einen konsistenten Gesamteindruck und dazu viele optisch passende Features.


    Kurz: Das Grunddesign, der Grundaufbau, Schriften etc. pp., die Grundfunktionalitäten und einige der Grundelemente sollten einem gefallen, um hier keine bis ganz wenig eigne Arbeit reinstecken zu müssen.


    Viele wählen sich ja ein Template wegen eines einzelnen lächerlichen Effektes (den die Templateschmieden "auch nur geklaut haben"), um das Template dann in ewig langer Fieselei erst mal kaputtzu"designen" ;-) Bis zum kompletten Zerfall.


    Dann fängt man besser mit Protostar an und "baut nach und nach auf" statt tragende Wände eines Kauftemplates einzubrechen ohne den Bauplan des 1. Stocks intus zu haben.

    Auch nur als Tipp: Footable. Für deine Belange würde ich Version 2 empfehlen, auch, da die Doku etwas klarer ist und man die Tabellen "in echt" im Seitenquelltext der Demos sieht.
    http://fooplugins.com/footable-demos/
    Braucht JQuery.
    Zusätzlich Bootstrap-CSS machts jedenfalls leichter, wegen grundlegender Tabellen-Responsivität durch CSS-Klasse "table".


    Nix gegen Version3, ist aber lang nicht so übersichtlich und man sollte bevorzugt mit dynamisch generierten JSON-Datas arbeiten. Musste jedenfalls ziemlich kämpfen, auch mit Bugs, bevor ich meine erste JHtml-Joomla-KLasse einsetzbar fertig hatte.

    Wieso sieht das ganz anders aus? Die Navi ist irgendwie komisch...


    Bei allen Kauftemplates installiert man wenigstens in einer weiteren Installation das mitgelieferte Quickinstall-Paket. Das ist ein komplettes Joomla inklusive vollständig eingerichteten Erweiterungen. Sieht dann exakt aus wie das Demo.


    Man kann dann entweder "rückbauen", also nach und nach aus dem Demo alles raus, was man nicht braucht oder im andern Joomla, wo man nur das Template installiert hat "anbauen", indem man im Demo abspickt.


    Ich geh bei templatemonster so vor, dass ich sogar 2x das Demo installiere in 2 verschiedenen Subdomains. Eine Installation bleibt zum Abspicken unberührt, in der andern wird gebastelt.
    Weiterer Tipp: Mach viele Backups bis du durch bist. Vieles is so "kompliziert", dass man froh ist noch eine Sicherung von letzter Stunde zu haben.


    Nur das Template zu installieren, macht (nicht nur) bei templatemonster keinen Sinn.

    Meine Empfehlung wäre ja:


    Da du ja eh neu aufsetzt. Setz das Joomla mit der Quickinstall-ZIP neu auf.
    abcquickStart.zip


    Dafür verwendest du diese ZIP-Datei als wäre es ein runter geladenes Joomla-ZIP-Paket und installierst es wie man Joomla installiert, entpacken, Install-Routine usw.


    Dann sollte alles notwendige schon installiert sein.


    Kannst ja auch in neuem Ordner machen mit eigener, neuer DB und das andere Joomla erst mal behalten.

    Über mehrere Stunden war die Seite und alle oben im Bild zu sehenden, egal, ob via Suchmaschinen geklickt oder direkt hier deine Links, für mich gesperrt. Deshalb auch mein Hinweis zu IP, die ja heute Nacht erneuert wurde. Ich denke mal "blöde, paranoide und/oder rassistische IP-Sperre" auf der Hauptdomain inklusive Subdomains, dem Hauptdomain-Server oder war einfach (sehr lange) abgek....

    Auch das deaktivieren des SEF Plugins (System - SEF) hat keine Auswirkung auf die Wirksamkeit der user.css


    Das ist nicht richtig. Ohne SEF-Plugin bleibt im href der relative Pfad erhalten wie vom Protostar in diesem Fall übergeben (templates/... ohne führenden Slash bzw. $baseurl).
    https://github.com/joomla/joom…s/protostar/index.php#L87


    Damit entsteht spätestens auf Unterseiten genau das von @Trubadix beschriebene Problem, dass der Browser die Base-URL der Seite vorne dranhängt.


    Statt example.org/templates/... => 200


    example.org/unterseite/templates/... => 404


    oder


    example.org/index.php/templates/... => 404


    etc.


    Selbes Spiel bei images und src, die bspw. direkt im Editor mit relativem Pfad (images/...) eingefügt werden.

    SEF war schon zu 1.x Zeiten eine Katastrophe


    Wir reden vom SEF-Plugin, das nur auf Umwegen etwas mit den SEF-Einstellungen der Joomla-Konfiguration zu tun hat.


    Versteh auch deinen Kommentar nicht ganz. Ich fahr seit jeher gut mit dem Joomla-SEF-Features (außer Canonical ;-) ), zugegebenermaßen nachdem ich mein Lehrgeld bezahlt habe und nun eben meine Joomlas von Anfang an sauber aufbaue (was das Backend sowieso viel übersichtlicher macht) und kleine Unschönheiten halt sofort ausmerze sobald sie in Suchmaschinen auftauchen.


    Und es tut sich ja auch was bzgl. SEF für kommende Joomla-Versionen (neuer Router), aber auch nicht so viel, dass man nicht selber weiterhin in der Pflicht wäre...
    (Ganz ganz nebenbei erwähnt: Manko ist eigentlich nur aus meiner Sicht, dass ich bei den Testanweisungen für die neuen SEF-Features auf GitHub nicht mehr so richtig durchblicke ;-) also nicht so richtig meiner Testpflicht nachkommen kann, damit das vielleicht schneller in Stable-Joomla alles drin ist. Blick einfach nicht durch, welcher PR denn jetzt... Bin aber nicht alleine damit... Dafür testest ja du, damit alles besser wird, was schon unter 1.x Sch... war?).

    Wo siehst du diese Überprüfungen?


    Oh ja, hast Recht, wird auch mit falschem Pfad eingebunden. Weiß jetzt auch nicht, wie ich da drauf gekommen bin.


    EDIT:
    Ah doch, habe ich einfach durcheinandergebracht, weil ich öfters wegen des Prüf-Features

    Code
    1. JHtml::_('stylesheet', $file, ... );


    auch in Kombination mit $path_only = true, verwende, um in einem Rutsch zu prüfen, ob denn ggf. Overrides sonstwo vom User angelegt wurden, bevor ich einen Fallback lade, LESS starte oder sonstwas. Ist dann auch gar nicht in Templates...



    addStylesheet ist aus dem Template selbst natürlich der direktere Weg. Alles gut so wie es ist ;-)

    Produziert hast DU das, weil du ein elementares Core-Plugin deaktiviert hast ;-)


    Das SEF-Plugin hat diesbzgl. einen irreführenden Namen. Ohne macht Joomla komische Sachen.


    In modernen Zeiten, wo dann auch noch picture-srcset-Sachen und ähnliches vermehrt dazu kommen (werden), kann man kaum darauf verzichten und sind via 1 Plugin zentral für die Joomla-Programmierer nachrüstbar.


    Ein Arbeiten mit Medien, im Editor bequem einzusetzen, kannst ohne das Plugin komplett vergessen.


    Lass es aktiviert.