Beiträge von Re:Later

    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.

    Gebe ich dir ja recht für Seiten, die das nötig haben, wirklich schnellstmöglich zu laden und um jede Millisekunde feilschen müssen. Da kommt dann oft auch die von dir genannte "gefühlte Geschwindigkeit" ins Spiel.


    Und die in Teilen redundanten Codes, die ich oben erwähne, müssen auch eingebunden werden und geparst und ausgeführt. Wir landen dann bei tatsächlichen Geschwindigkeitsgewinnen, die für viele Seiten "gefühlt" vollkommen unerheblich sind.


    Dazu kommt, dass es sowieso sehr lange dauern wird, bis Erweiterungsprogrammierer auf JQuery verzichten werden, weil sie Ihre Vanilla-Codes deutlich intensiver, browserübergreifend testen werden müssen und sich nat. in diesem Bereich auch einarbeiten müssen. Unter'm Strich nat. ein großes Plus für kommerzielle Anbieter, die so was mit gößerer Man-Power leisten können und mit "Super-Geschwindigkeitsgewinnen" werben können.


    Die meisten Seiten die ich als Popel-Webbastel-Anbieter so sehe, haben jedenfalls ganz andere Probleme bzgl. Geschwindigkeit als JQuery ;)

    Ich habe gar nichts gegen die Entfernung von JQuery

    Da ich selber gerade mit den jQuery Problemen zu kämpfen habe

    Was denn für Probleme? Nach meiner Erfahrung kann man die alle lösen. Und auch Joomla 3 mit höheren Versionen, sowohl JQuery als auch BS betreiben. Im blödsten Fall braucht man 1 zusätzliches Plugin.


    Nur paar lose Gedanken:


    JQuery ist auch für Newbies relativ schnell erlernbar und korrigierbar.


    Außerdem sollte man sich mal anschauen, was es für Folgen hat, dass Joomla 4 jetzt auf ES5 bzw. ES6 umstellt. Es gibt nämlich kaum mehr Leute, die im JS-Bereich mitarbeiten können oder wollen. Und wenn dgrammatico mal keine Zeit/Lust hat, bleiben viele JS-verursachte, trivialste Fehler ewig liegen. Stattdessen werden dauernd neue "Genialitäten" nachgeschoben. Programmieren muss man den Kram für Joomla 4 in perfektem ES6 und dann via Konsole nach ES5 kompilieren und dann minifizieren und dann testen und dann von vorne, wenn was nicht klappt. Überfordert nicht nur Anfänger unter den Mithelfern, liest man regelmäßig in Kommentaren. Vom Zeitaufwand für ein einzelnes JS-Fitzel und Aufsetzen einer solchen Arbeitsumgebung, die ständig aktuell zu halten ist, ganz zu schweigen.


    Außerdem sind da viele sehr starre und unflexible, "eingemeißelte" JS-CSS-Programmierungen darunter, zumindest derzeit noch, weiß ich aus Spielereien mit eigenen Backend-Templates für Joomla 4. Weitaus zeitaufwendiger umzubiegen als das in Joomla 3 möglich ist. Stichwort "Markup-Müll", der einen genauso zwingt wie zuvor BS2-Markup-Müll seine Erweiterungen und Templates anzupassen.


    IE11 einfach auszuschließen, was bedeutet das für viele Seitenbetreiber? Nur weil ich den Browser nicht mag? Wird viele nur dazu verleiten, ewig Joomla 3 über EOL weiterzuverwenden, wenn man einfach was raushaut.


    Außerdem liefert letztlich Joomla-4-Core nur noch BS4/JQuery mit aus, so, dass man es nutzen kann, aber nicht muss (wenn man clever genug ist). Wenn du dir anschaust, wie viele Erweiterungen auf JQuery bauen und auch weiterhin werden, ist das auch absolut richtig so.


    Außerdem ist es ja nicht so, dass BS5 dann ohne JS und ohne "starres, eigenes, inkompatibles CSS" daherkäme. Es ist halt nur nicht mehr JQuery. Und das JS ist dann auch "festgemeißelt". Muss man sich also zusätzlich einarbeiten, wenn man was umbiegen will.


    Bei den Ladezeiten/Größe für/von JQuery wird von den Puristen auch gerne übertrieben, weil sie sich immer nur Einzelsituationen anschauen und so tuen, als müsste für jede EInzelsituation JQuery neu geladen werden. Wenn man sich dann anschaut, wie viel redundanten Code die für jedes einzelne Pimpelpampel produzieren... So werden aus paar Sachen, die mit JQuery paar Zeilen benötigen, undurchschaubare Riesendateien.


    Ich habe gar nichts gegen die Entfernung von JQuery, aber dann sollte die ach so moderne Alternative auch kein Bremser für die Weiterentwicklung und/oder Tester sein. Und das ist sie im Moment.

    Stellt sich mir die Frage, wie du denn überhaupt feststellen kannst, ob diese Backlinks der Konkurrenz irgendeine Auswirkung auf's Ranking BEI GOOGLE haben und, ob diese seriös oder unseriös sind. Seriös sind sie, wenn sie im Kontext der verlinkenden Seite Sinn machen (Relevanz).


    Alles andere ist "out" (siehe Vorredner) und verballerte Mühe bis schädlich.


    Hier ein kleiner Beitrag, den ich auf die Schnelle gefunden habe: https://www.takeoffpr.com/blog/backlinks-aufbauen


    Nebenbei habe ich auch mehrere Seiten in Pflege, wo mir bei Google zahlreiche Backlinks angezeigt werden. 99% sind unseriös und verschwinden nach einiger Zeit auch wieder.

    Oder wie komme ich mit legalen Mitteln auf die ersten Plätze?

    Dauerhaft und konsequent dran bleiben. Klingt blöd, ist aber so.


    Und, wenn schon Geld raushauen, lieber gleich mit AdWords arbeiten, wo aber das selbe gilt: "Dauerhaft und konsequent dran bleiben", weil eben hier die Konkurrenz auch nicht schläft und man ununterbrochen im direkten Wettkampf steht.

    Das ist leider ein ziemlich verquastes Durcheinander von Override-Möglichkeiten. Intuitiv geht anders.


    1)

    - In components/com_fields/layouts/ findest 2 Ordner.

    - Kopierst den field/ nach templates/DEINTEMPLATE/html/layouts

    - Benennst darin die Datei render.php nach myrender.php (Name beliebig) um.

    - Wählst in deinem Wiederhol-Feld in Einstellung Layout "myrender" aus.

    - Jetzt kannst versuchen die Variable $value , die eine fertige Liste (<ul><li>Artikel1, Preis1</li><li>Artikel2, Preis2</li></ul>) enthält, irgendwie umzubauen.


    2) Nur Hinweis:

    - components/com_fields/layouts/fields/render.php kann man auch als Override kopieren. Aber nicht umbenennen als eigenes Layout. Ein Override würde also ALLE Felder betreffen.


    3) Um den Aufbau der obigen UL-Liste direkt zu beeinflussen. Wohl das, was du suchst und ich zuletzt gefunden habe ;) :

    - Kopierst plugin/fields/repeatable/tmpl/repeatable.php nach templates/DEINTEMPLATE/html/plg_fields_repeatable/repeatable.php

    - Auch das betrifft dann ALLE Wiederholfelder, da Plugins kein alternatives Layout kennen oder ich nicht weiß, wo man das in diesem Fall wählen sollen konnte.

    - Und nachdem ich keine Lust habe, mich durch weiteres Dutzend Dateien zu hangeln, um rauszubekommen, wo eigentlich dieses tmpl/repeatable.php in's Spiel gebracht wird, ob man da irgendwo irgendwas auch umbiegen kann, verbleibe ich mit einem "Viel Spaß!?" ;)


    EDIT: Zu spät. Hätt ich mir sparen können.