Beiträge von Re:Later

    Was setzt du ein?

    Wenn ich die Entscheidungsfreiheit habe und/oder Kunden umstimmen kann, pures Joomla. Aber ich tu mich natürlich leichter bei so einer Entscheidung, weil ich (fast) alles, was ich wil, ""schnell mal"" zu- und umbasteln kann.


    T3 kann man das Template-Framework-Plugin separat updaten. Schon mal ein Plus. Und so weit ich es kenne, erlaubt es auch stinknormale Joomla-Override-Methoden. Ein weiteres Plus. Und ich sehe im aktuellen Plugin, dass es sich schon auf Joomla4 vorbereitet. Muss man dann sehen, ob das ein weiteres Plus für Leute sein wird, die ein älteres Template verwenden, ob die dann ohne große Anpassungen durchkommen werden und v.a. ohne allzu viele ihrer Änderungen zu verlieren.


    Mehr weiß ich dazu nicht zu sagen. Ich nehm's immer wie's kommt ;-)

    Was spätestens auf einem Smartphone den gesamten Text abdeckt. Oder in Landscape-Ansicht die unteren Menüpunkte unerreichbar macht. Würde ich mir also überlegen...

    Dann bleibt wohl wirklich nur die Update-Tour.

    Mit einer Joomla 3.5.1 wäre das schon lange fällig wegen Sicherheitslücken.

    Setze eine abgesperrte Subdomain auf und teste in Ruhe das Update.


    Die Originalseite würde ich sofort as-is/ohne weitere Änderungen sichern und Backup aufheben, dass man ggf. später noch nachvollziehen kann, ob sie gehackt wurde. Daran denken: Joomla-Updates merzen nicht alle Hacks aus.

    Meines Erachtens liegt das an einem veralteten Override in deinem Template. Das wurde irgendwann mal korrigiert und das Filterfeld bleibt über der Meldung erhalten im puren Joomla.


    Benenn mal alle Dateien, die mit "default" beginnen in diesem Ordner um:

    Code
    1. /templates/jsn_epic2_pro/html/com_content/category/

    Also bspw. default.php nach default.phpxyz


    Weiß aber nicht, ob das bei JSN-Templates so einfach geht.

    Es gibt ja mittlerweile auch die sog. "moderne" URL-Generierung im Unterschied zur "kompatiblen" URL-Generierung, die man in paar Komponenten-Optionen im Tab "Integration" einstellen kann. Unter'm Strich also ein anderes Routerverhalten. Hab ich aber keine Ahnung, ob's da Unterschiede bzgl. oben gibt.

    Weil der Einstieg in das ganze Routing (zumindest beim alten, Legacy) eine Abfrage der URL ist (also GET-Variablen) mittels JUri. Dort wird nach einer Itemid in den vars gesucht (GET-Parametern). Wenn's die gibt, werden weitere Daten aus dem Menü-Eintrag zusammengesucht.


    An anderen Stellen wird dann aber u.U. z.B. mit $app->input->get('option') (also Abfrage POST und GET) überschrieben.

    Das ist dann der Grund, warum ein action index.php/?Itemid=290 auf einer Kontaktseite landet bei ienm POST-Formular mit einem Input <input type="hidden" name="option" value="com_contact"/>, auch wenn Menüeintrag 290 ein com_content-Menü ist. Weiter habe ich das nicht erforscht, worauf man noch achten muss.


    Bleibt dir also nichts anderes übrig, als wenigstens die Itemid in die action einzubauen. Im Normalfall schönt man die action sowieso mit JRoute::_($link), wenn man ja sowieso schon alle Bestandteile vorliegen hat..

    Wenn die Seite eh noch nicht mehrsprachig ist, deaktiviere die beiden Plugins, die du mit Suche nach "Sprach" findest.


    Ganz sicher bin ich nicht, ob das dann noch nötig ist:


    Ggf. musst du dann die Menüs noch mal durchsehen. Sprachen auf "Alle" rücksetzen und schauen, dass nur ein Startseiteneintrag dabei ist.


    Ebenso "Alle" bei Beiträgen, Kategorien etc.

    In neueren Joomlas findet sich das Verzeichnis unter administrator/logs. Das hat einfach damit zu tun, dass es bei paar Providern Probleme geben kann, wenn es im ROOT liegt. Gelegentlich heißt es auch log/, um diese Konflikte zu vermeiden. Je nachdem wie und wann und womit du das Joomla aufgesetzt hast.


    Ich habe gestern getestet, was passiert, wenn ich das logs-Verzeichnis sperre. Joomla schreibt dann nicht in irgendein anderes Verzeichnis, sondern spuckt einen Fehler aus.


    Einzig und allein entscheidend für Joomla ist: Joomla verwendet den Pfad, der in der Joomla-Konfiguration im entsprechenden Text-Feld angegeben ist. Das Feld findest im Tab "System" der Joomla-Konfiguration als "Protokollverzeichnis".


    Das oben erwähnte Rotator-Plugin arbeitet so: Jedwede PHP-Datei im Verzeichnis, das Joomla als Logs-Verzeichnis ansieht, wird im eingestellten Intervall mit einer Versionsnummer versehen. Dem Plugin ist es egal, was das für eine Datei ist, weil eben in's logs-Verzeichnis nur PHP-Dateien gehören, die nur Log-Informationen enthalten sollten.


    Nur nebenbei: Das ist auch der Grund, warum SQL-Logdateien jetzt nicht mehr auf ".sql" enden, sondern auf ".sql.php". 1.) um sie vor direktem Browseraufruf zu schützen. 2.) um sie eben auch zu rotieren, also regelmäßig zu entfernen bzw. erneuern.

    "Protokollrotation" ist nebenbei nach DSGVO u.U. Pflicht, da gelegentlich auch IPs mitgeloggt werden. Man muss also nach einer gewissen Zeit diese Informationen löschen. Außerdem verhindert man das Aufblasen der Log-Dateien im Laufe der Zeit. Ich hatte kürzlich eine Seite mit 2 GB großer error.php, die den Webspace blockierte, weil voll.

    Letztlich sind das JavaScript-Varianten, die Browser "eben alleine können", also ohne Zuladen von irgendwelchen extra Bibliotheken wie JQuery. Ganz unter'm Strich also alles "Vanilla"-JavaScript-Varianten bzw. "autarkes, stinknormales JavaScript".


    Und das derzeitige Problem ist eben, dass ES6 z.B. von IE11 wenigstens in großen Teilen nicht unterstützt wird (https://caniuse.com/#search=es6). ES5 verstehen mittlerweile die meisten aktuellen Browser (https://caniuse.com/#search=es5).


    Deshalb ja auch das Gezeter, das ich in Post #6 schreibe:

    Programmieren muss man den Kram für Joomla 4 in perfektem ES6 und dann via Konsole nach ES5 kompilieren und dann minifizieren

    Derzeit liegen also für jede JS-Datei mehrere in Joomla 4 rum. Beispiel core.js


    core.es6.js
    core.es6.min.js
    core.js
    core.min.js


    Erweiterungsprogrammierern kann das aber letztlich wurst sein, so weit es keine Core-Erweiterungen werdden sollen, so lange sie ihr JS so schreiben, das es kein JQuery extra zuladen muss.


    Es ist tatsächlich so, dass das Umschreiben kleinerer Dateien und Schnipsel nicht die Welt ist. Also so Kram, was man oft als schnelle Lösung in Foren findet für Kleinkram. Ganz anders sieht das aber bei komplexeren Skripten aus, wenn man eben nicht aus "dieser Programmiererwelt" kommt oder eben Fremdbibliotheken wie z.B. Venobox oder Flexslider verwendet.


    Wenn ich also ein beschränktes Kontingent für Weiterbildung in meinem Beruf habe, werde ich so lange JQuery verwenden bis ich Zeit und Bock habe, bevor ich anderes, wie Einarbeitung in andere CMS oder Joomla4 liegen lassen. Darauf wollte ich oben auch hinaus.

    W

    Mehrfach wurden die 3 Dateien im Administrator-Verzeichnis umbenannt

    Im Administrator-Verzeichnis gibt es im Normalfall gar keine 3 PHP-Dateien., sondern lediglich index.php .

    Das Plugin "System - Protokollrotation" hängt auch nur vor .php-Dateien eine Versionsnummer an.

    Wenn das Logs-Verzeichnis falsch eingestellt ist, kann's natürlich sein, dass jetzt im administrator-Verzeichnis eben Log-Dateien wie z.B. joomla_update.php auch abgelegt werden.


    Bin ich ja gespannt ;-)

    Auch ich hatte auf drei auf unterschiedlichen Servern liegenden Webseiten diese ominöse Umbenennung festgestellt.


    Unter Joomla 3.8.14: joomla_update.php


    Nach Update auf 3.9.0: 1.joomla_update.php


    Wobei die eine Seite sogar eine ziemlich neu erstellte Webseite war. Diese automatische Umbenennung bezog sich in meinem Falle nur auf diese Datei.

    Es kommt darauf an, wo die Dateien umbenannt werden. Falls es sich um Dateoen im Joomla-Logs-Verzeichnis handelt, ist das normal und es ist verursacht durch das Plugin "System - Protokollrotation". Das fügt nach bestimmten Zeitintervallen (siehe Einstelllung "Protokollrotation (in Tagen)") Log-Dateien, die auf .php enden, Versionsnummern vor die Log-Dateien an und beginnt eine neue Log-Datei ohne Versionssnummer. Wie viele Log-Datei-Versionen aufgehoben werden, hängt von der Einstellung "Anzahl Protokolle" im Plugin ab.


    Umbenennungen dieser Art außerhalb des Logs-Verzeichnisses, sind aber sicherlich Fehler im System oder VIELLEICHT Hacks.