Beiträge von Re:Later

    Bei mir lautet die entsprechende CSS-Anweisung

    Code
    font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;

    Und die ist nach Abgleich mit älteren Joomla-Versionen seit Jahren so.


    Angezeigt wird bei mir in Arial, weil ich erstere beiden nicht auf meinem Rechner habe.


    Mittlerweile erlebt man ja mit jedem Update, egal ob FF, Windows, sonstwas, dolle Verbesserungs-Änderungen, z.B., dass man jetzt in FF in der Adresszeile graue Schrift auf grauem Hintergrund (statt zuvor weißem) hat, weil Spönner meinen, das wäre doll besser (für mich nur unlesbarer). Ergo: Ich lasse es mal dahingestellt sein, ob du deine Fonts aktiv selber ändern musst, um sie nicht plötzlich doch auf dem Rechner zu haben, obwohl vorher nicht ;)

    Den mittleren Teil bräuchte man dann eigentlich nicht mehr(?).

    Entscheidend ist das "width" und "height" für den leeren content, damit dann das Hintergrundbild entsprechend angezeigt wird. Durch das "cover" eingepasst.

    Ich denke ich muss URL-Rewrite einschalten

    Das nein.

    die htaccess.txt in .htaccess

    Das ja, wenn du weitere Umleitungen dort eintragen willst.

    das ergibt aber einen Internal Server Error Apache at Port 443

    Bei manchen Providern muss man dann noch 1, 2 Zeilen in der .htaccess anpassen.

    Können wir nicht wissen.


    Folgend eine PHP-Variante. Bin aber immer noch nicht sicher, ob ich dein Anliegen richtig verstehe.

    Code
    $myUri = JUri::getInstance();
    $optionVar = $myUri->getVar('option');
    $viewVar = $myUri->getVar('view');
    
    if ($optionVar === 'com_users' && $viewVar === 'registration')
    {
        JFactory::getApplication()->redirect('/', 301);
        return;
    }

    die ALLE Links auf die Startseite umleitet, die ein option=com_users UND ein view=registration enthalten.


    Könnte man z.B. in der index.php des Templates direkt nach Zeile

    Code
    defined('_JEXEC') or die;

    einfügen. Aber, da Templates ja auch oft nicht Standard-Joomla sind vom Aufbau her, vielleicht auch woanders ;)


    Eigentlich funktionieren die Zeile nahezu überall im Joomla-Ablauf-PHP.

    Vielleicht als IFrame. Joomla hat dafür die Wrapper-Komponente, aber auch ein -Modul, danei. Letzteres kann man in einen Beitrag per "Modul"-Button einsetzen, also auch mehrere untereinander. Ersteres ist ein Menüeintrag.


    Manche Seiten blockieren aber auch das Einbinden als Iframes auf fremden Seiten. Musst ausprobieren.

    /index.php?option=com_users&view=registration

    den würde ich gerne umtaufen

    Du willst ihn unwirksam machen?

    Und du hast bereits einen anderen Link, also einen Menüeintrag für die Registrierungsseite?

    Warum kann ich eigentlich meinen ersten Beitrag nicht bearbeiten

    Dafür hast du 15 Minuten Zeit. Danach nicht mehr.

    Gab aber davon noch mehr

    Weshalb ich das dann auch nicht mehr weiter verfolgt habe ;) Ursprung war ja glaube ich nur, dass man mit Trickserei nicht außerhalb des Webspaces oder Medienordners(?) hochladen kann.


    Weiß auch gar nicht, ob das dann irgendwie mit unserem Problem hier zu tun hat.


    Sehe nur, dass das finale Ergebnis aller Änderungen nicht nur dem CD-Doku unerwartete Probleme machen wird. Hilft nur JCE oder halt ein FTP-Tool, dass das Zeugs so hochlädt wie benötigt.


    Resümee: Großschrift und Punkte in Dateinamen sind erlaubt, aber nicht im Joomla-3-Medienmanager.

    Zu 3.: Wie lädst du diese Dateien denn hoch? Also wo in Joomla? (Medienmanager oder ... ?).


    Ich bin nicht ganz sicher, ob dich das betrifft, aber es gab letztlich tatsächlich Änderungen bezüglich erlaubter Dateinamen, die mir teils "sonderlich" vorkamen.


    EDIT: Ich kann bestätigen, dass der Medienmanager beim Upload aus einer Datei "Test.Print.pdf" die Datei "testprint.pdf" macht, was natürlich Unsinn ist. Vermutlich ein Sicherheitsaspekt(?)

    Der JCE-Dateibrowser macht das allerdings nicht. Zum Glück verwende ich nur den.

    Man kann den ja auch so konfigurieren, dass er die Aufgaben von Uploadfeldern (Typ media), egal wo sie sind, übernimmt.

    Steht dir natürlich frei. Aber was hinderte dich jetzt daran, mal eben den Test aus Post #2 zu machen, weil es ist natürlich für Helfer ebenso unbefriedigend, wenn man Zeit aufgewendet hat, wenn dann der TE Lösungsfindung blockiert.


    Dann hättest doch gleich da anfragen können.


    Ist immer so vergeudete Zeit...

    ch habe nur noch nicht herausgefunden wo... in der Index.php im Template sehe ich jedenfalls nix...

    Da gehört es ja auch eigentlich nicht hin.


    Man kann nur vermuten, dass es in der Datei components\com_quix\views\page\view.html.php stattfindet. Zumindest in Quix Free Version 2.7.8 mit PHP8.0.1

    Code
    $uri = JUri::getInstance(true);
    $uri->setVar('format', 'amp');
    $document = JFactory::getDocument();
    $document->addHeadLink(htmlspecialchars($uri->toString()), 'amphtml');

    Aber es macht doch gar keinen Sinn die Zeile(n) zu entfernen. Dann kannst doch gleich AMP wieder deaktivieren.


    Viel sinnvoller wäre doch, den eigentlichen Fehler zu finden, wo das dann kollabiert. Als ersten Ansatz siehe Post#2 "Fehler finden durch ..."


    Schon das "RawDocument" in der Fehlermeldung kommt mir "komisch" vor.


    Mir scheints auch so, dass in der Free Version das AMP gar nicht vorgesehen ist. Da wird das format=amp an einer Stelle im Code wieder entfernt (aber, nicht zu verwechseln(!), nicht im HEAD).

    Ich bevorzuge viele Plugin-Events in Komponenten. JShopping ist ein gutes Beispiel mit vielen eigenen(!) Events, die es ermöglichen nahezu überall via Plugins Daten abzugreifen, zu ändern, zu erweitern usw. usf. Man kann entweder Plugins schreiben, die in einer eigenen jshopping-Plugin-Gruppe sind (weiß den Ordnernamen gerade nicht), aber auch einfach system-Plugins. Erstere werden im Normalfall nur bemüht, wenn JShopping auf einer Seite geladen wird. Zweitere evtl. auch schon mal unnötig registriert/geladen.


    Wie viel Code ausgeführt wird, hängt davon ab, wie schnell ein Plugin abbricht, wenn es nichts zu tun hat (meist durch context oder jinput-Prüfungen). Oder, ob es nur die Event-Methoden enthält, die es eben braucht.

    Außerdem in welcher Plugin-Gruppe es sich befindet (s.o.). System-Plugins werden bspw. nahezu immer aufgefordert werden, mal nachzusehen, ob sie was zu tun haben könnten. Hier kann man nahezu ALLE Event-Methoden anderer Plugin-Gruppen verwenden. "Sie sind immer da."

    Ein User- oder Content-Plugin oder ... wird nicht so oft ins Spiel gebracht beim Codeablauf, außer man triggert diese eben in seinem Code.

    Außerdem natürlich davon wie viel und was für Code ein einzelnes Plugin bei diesem oder jenem Event eben drinnen hat, verwendet, oder anderweitig bemüht. Ein paar, dutzende, 100e oder 1000e Zeilen auszuführender Code? Wie komplex? Datenbankabfragen? usw.usf.


    Plugins sind ja auch nur PHP-Klassenm mit PHP-Methoden.


    Und, wenn ich es richtig verstehe, werden diese Klassen erst nur registriert und nur im Bedarfsfall dann geladen. Kann mich täuschen.


    Kurz: Eine Frage der Programmierung und was man halt so alles installiert, aktiviert hat und schließlich triggert.

    Ich kann dir aus Zeitgründen für den Moment nur das sagen:


    - Dreh und Angelpunkt für die Ausgabe der Felder sind die JLayouts

    /components/com_fields/layouts/fields/render.php

    und

    /components/com_fields/layouts/field/render.php


    - Für diese kann man in seinem Template Overrides anlegen. Auch welche, die dann z.B. nur für Beiträge gelten.


    - Man kann Feldern im Backend auch Ausgabe-CSS-Klassen zuweisen. Weiß nicht, ob hilfreich.


    Weiteres ist dann abhängig von dem Template, z.B. welche Bootstrap-Version es verwendet oder irgendwas anderes als Bootstrap, damit man diese Mehrspaltigkeit hinbekommt. Das Ganze soll dann ja sicherlich auch responsiv sein.

    Nur so paar Gedanken.


    Bisher habe ich bei meinen Erweiterungen und Templates, nach anfänglich großem Engagement und dummen Versprechungen Kunden gegenüber, Joomla 4 erst mal wieder liegen lassen, weil sich nach Versuchen und dann immer noch mal Versuche nach einiger Zeit, zeigte, dass sich das nicht lohnt, seine Zeit weiter damit zu verschwenden. Wegen gravierender Code-Änderungen.


    Mit dem ersten ReleaseCandidate von gestern ist nun aber endlich Schluss mit weiteren, allzu dämlichen "dollen" Features und Pseudo-"Optimierungen" am Basis-Code von Joomla 4. Die eigentliche Code-Basis bleibt ab jetzt nahezu unverändert, wenn sich nicht doch wieder ein(er der) Endlos-Blah-Blah-Schlimmschlimmschlimm-Spönner durchsetzt.


    Kurz: Eigentlich sollte jetzt der Punkt erreicht sein, wo Erweiterungsprogrammierer sinnvoll anfangen können, ihre Erweiterungen für J4 kompatibel zu machen; ohne allzu große Überraschungen zu erleben.


    Das war aber auch schon ab Joomla 3.9 in großen Bereichen möglich, nebenbei.


    Andere werden aber sicherlich so lange warten bis J4 Stable raus ist. In 2 Jahren schafft man das schon, eigene J3-Erweiterungen an J4 anzupassen, wenn man seinen eigenen Code kennt und nicht auf Joomla 2.5 stehen geblieben ist (leider gibt es solche Erweiterungen nämlich auch noch und die werden explodieren). Oft sind auch gar keine aufwändigen Anpassungen nötig, weil J4 nämlich auch noch viel J3 versteht, sozusagen.


    Wieder andere werden nichts tun, aber andere werden deren Projekte adaptieren bzw. Alternativen basteln.


    Weitere Erweiterungen werden verschwinden, auch weil sie eigentlich für J4 gar nicht mehr gebraucht werden.


    Wenn man also mit Bedacht an sein Joomla 4 und/oder Joomla 3 und "kreativen" Anpassungen und Änderungen rangeht und dazu gehört sicherlich auch, nicht jeden "Müll" zu installieren bzw. dann auch gleich (wieder) zu deinstallieren, weil gar nicht benötigt, wird das dann schon irgendwie gehen.


    Wenn man sich erst mal vornehmlich auf Inhalte, saubere Menüaufbauten, Kategorisierungen etc. konzentriert anstatt gleich ästhetisch kreativ zu werden, vergeht ja auch erst mal Zeit.


    Wenn du genügend Zeit hast, auf Joomla 4 Stable zu warten; nur damit solltest du dann öffentlich online gehen, tät ich mal sagen "Warum nicht gleich mit J4 anfangen". Auch, weil man sich dann eben gleich da einarbeitet... Man freut sich dann, wenn die eine oder andere Erweiterung "nachwächst", man das Template doch noch wechseln kann, weil man in das erste noch nicht zu viel Aufwand gesteckt hat usw.


    Egal was so gesagt wird, wird eine 1:1-Portierung von J3 auf J4 im Normalfall für "Laien" nicht ganz ohne sein, wenn man Obiges nicht bedenkt. Einer der Gründe ist auch, dass man beim Update vor inkompatiblen Erweiterungen gewarnt wird, die ggf. gar nicht inkompatibel sind. J3-Templates müssen teils extrem umgeschnitzt werden bzw. müssen wahnsinnig viele Overrides erhalten, damit man sie weiter verwenden kann. Ohne Testseite, auf der man das schrittweise klärt, wirst nicht auskommen, aber hast halt auch 2 Jahre Zeit dafür.

    Beim JCE hast du auch den Button. Er erscheint unter dem Beitrag

    Ja, Danke, hast recht. Der Beitragknopf war aber nach einem der JCE-Updates in dem Dropdown nicht drinnen, weshalb ich ziemlich genervt war. Oder wurde er umgeleitet auf den normalen Link-View vom JCE? Keine Ahnung mehr. Weiß nur noch, dass ich da das Manual für einen Kunden noch mal spät nachts umschreiben musste ;) und die 3999 oder waren's nur 4(?) JCE-Profile wieder umkonfigurieren, damit die Knöpfe wieder unter dem Editor.

    Alles wieder gut!

    Wenn du den Beitragsbutton unter dem Editor hast, damit. Cursor auf Stelle im Editor. Beitrag mit Button auswählen.


    JCE versteckt den aber gelegentlich dämlicherweise. Also ggf. im JCE den Link-Button in derToolbar klicken und dann unten unter "Content" auswählen.

    Meckern tue ich, weil die Suche nach dem richtigen Beitrag in JCE Generve ist, wenn man viel Inhalt hat, während das mit dem Joomla-Beitrags-Button simpel ist, da alle Filtermöglichkeiten gibt.

    Das wurde in dem Link behauptet, den ich Eingangs schrieb.

    Nach Lektüre desselben scheint mir der Beitrag nicht sonderlich praxisfundiert. Tatsächlich sind händische Backups wie er sie beschreibt (Datenbankexport selber machen usw.) natürlich AUCH eine Variante, aber die Wiederherstellung solcher Sicherungen kann zur Qual werden, sehe ich bei Seitenportierungen regelmäßig und nicht zu selten, weil die Importe der SQL-Dateien weitaus häufiger nicht funktionieren (aus diversen Gründen von PHP-Einstellungen bis hin zu Versions-Inkompatibiltäten) als die mit Akeeba-Backup. Letzteres ist darauf ausgerichtet, solche Fehler abzufangen, sowohl bei Sicherungen als Rückspielungen.


    Und wir reden hier bisher nur von der Free-Version. Die Pro kann einiges mehr.


    Und wie bei jeder Software sollte man halt auch da immer mal schauen, ob noch genug Speicherplatz auf dem Server vorhanden ist ;) und so Zeugs.


    Nur so Nebenbei-Pedanterie: Schon, dass dort im Beitrag im Zusammenhang mit Akeeba-Backup von einem "Plugin" die Rede ist. Das ist ein umfangreiches Paket aus Komponente, Plugins (darunter auch eines für Cron), Bibliotheken etc.


    Aber deine Aufgabenstellung riecht mir auch mehr nach astrid ' s Tipp, wenns denn funktioniert. Kenne das nicht und wollte es schon ausprobieren. Lohnt sich für mich aber bei dem Preis nicht.


    EDIT: Vergessen. Anstatt der händischen Sicherung wäre dann sowieso gleich EJB von Kubik Rubik (Easy Joomla Backup) die zu empfehlende Backup-Variante. Erzeugt Archive plus SQL-Dateien. Ist fix. Hat auch Cron dabei als Plugin. Und auch da hat die Pro-Version weiteren Luxus drinnen.