Persönlich freue ich mich über jeden Extension Entwickler, der den Schritt in Richtung Vanilla macht, da es für mich als Purist bedeutet dass ich zumindest die Option habe, Seiten ohne JQuery zu betreiben - und ich denke das sollte auch letztlich die Grundanforderung an eine wie auch immer geartete Lösung dieser Thematik sein: es muss die Option geben, das Standardverhalten so umzubiegen, das es auf den eigenen Usecase passt.
Beiträge von SniperSister
-
-
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.
Den Einarbeitungsaufwand halte ich für überschaubar. Gerade in ES6 sind viele APIs dazu gekommen, die an JQuery-Verhalten angelehnt sind und den Umstieg daher relativ leicht machen. Eine gute Ressource hierfür ist:
-
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...
Dazu ein Einwand, der bei der Performance-Diskussion gerne übersehen wird: selbst wenn der JS-Berg, den Jquery da so lädt, gecached worden ist, muss der Kram trotzdem bei jedem Rendervorgang geparst und ausgeführt werden, was deutlich mehr Zeit in Anspruch nimmt, als der eigentliche Download. 50kb sind da deutlich „teurer“ als ein 50kb Bild. Erschwerend kommt dabei hinzu dass es einbindungsbedingt Render-Blocking ist, was es für die gefühlte Geschwindigkeit nochmal teurer macht.
-
Die Frage „Framework oder nicht“ ist schon seit vielen Jahren heiß diskutiert. Im wesentlichen gibt es dabei 4 Interessengruppen:
1. Extensionentwickler: die wollen sicherstellen, dass ihre Extensions in jedem Template gut aussehen und „JS-Krimskrams“ wie Modale, Tooltips, Smoothscroll und co überall funktionieren. Hier macht ein Framework im core Sinn, weil es dadurch ein Grundset an Funktionen und Styles mitbringt, auf die Entwickler aufbauen können.
2. Template-Entwickler: Template Devs möchten gerne mit dem Framework ihrer Wahl arbeiten, das möglichst modern und sexy sein soll. Ein Framework im Core wäre aus ihrer Sicht schnell veraltet und daher kein Tool der Wahl mehr.
3. Die Puristen: wollen garkeine Frameworks, weil sie den Markup-Müll und den Performance-Impact vermeiden wollen.
4. Die Core-Maintainer: wollen am liebsten eine externe Lösung, da uns die Ressourcen für ein eigenes Framework fehlen, gleichzeitig fürchten sie, das Framework weiter zu maintainen wenn der offizielle Support schon abgelaufen ist.
Dimtris ist extremer Vertreter der Puristen, das ist zur Einordnung seines Tweets wichtig.
Eine Lösung, die alle zufrieden macht, ist schwer.
-
Bootstrap 4 und das zugehörige bootstrap.min.js brauchen mindestens JQuery 3.3, das was du da als Fehler siehst ist eine Versions-Inkompatibilität.
-
Deutlich wichtiger als komplexe Passwörter sind einzigartige Passwörter, daher kann das hier eine sinnvolle Ergänzung sein:
Bevor es hier Bedenken gibt, dass da Passwörter an einen Drittservice gehen:
Es werden die (wertlosen) ersten 5 Stellen des Hashes an den Service geschickt und dann in der Antwort nach einem Match gesucht - es fließen also keine Daten ab.
-
Laut dem Blank Bootstrap Template von Alex hole ich via NPM die aktuelle BS / jQuery Version (+popper.js und custom.js) und packe die mit Gulp in 1 File(vendor/template.js).
Dann lade ich das ganze am Ende meiner index.php. Mit dem unset wollte ich das Laden der J! eigenen Files unterbinden, um es nicht doppelt zu laden. Aber wie gesagt, das klappt alles nicht so ganz.
So, habe nochmal genauer gelesen, jetzt macht das hier auch alles sinn. Du hast ein Problem bei der Ladereihenfolge der Skripte!
Die Website wird von oben nach unten geparst und ausgeführt, das bedeutet auch dass ein Skript im oberen Teil des Heads, das JQuery benötigt (z.B. das Caption.js von Joomla) zwingend voraussetzt dass JQuery bereits vor diesem Script geladen wurde. In deinem Template hingegen unsettest du das Core-JQuery und lädst dein JQuery in der template.js dann *nach* allen anderen Skripten, daher die Fehler.
Selbst wenn ich jetzt die Joomla eigene jQuery lade, sieht alles prima aus. Wenn ich mich als SU einlogge auch noch. Aber sobald ich irgendwo in der Seite irgendwo hinklicke, kommt sofort ein Fehler.
Auch das ergibt Sinn, du hast JQuery dann nämlich zwei mal geladen:
1. das Core-JQuery, das mit diversen Funktionen und Plugins ergänzt wurde, die in den nachgelagerten JS Files hinzu kommen.
2. dein eigenes JQuery in der template.js, bei dem diese Plugins fehlen und das die erste Instanz überschreibtGibt es dann irgendwo in der Seite einen Inline-Codeblock, der eines dieser JQuery Plugins braucht, so greift dieser Block auf das Jquery deiner template.js zu - und dort gibt es die Plugins leider nicht. Ergebnis: Fehler.
Lösungsansatz: Joomla so umbauen, dass für Public-User keine Skripte mehr geladen werden, die JQuery benötigen. Typische Kandidaten sind Captions, Tooltips und Modals. Joomla lädt JQuery nämlich nur dann, wenn es auch ein Skript gibt dass JQuery explizit angefragt hat. Für eingeloggte User ist der Performance-Impact dann in der Regel eher zu verschmerzen.
-
Deutlich wichtiger als komplexe Passwörter sind einzigartige Passwörter, daher kann das hier eine sinnvolle Ergänzung sein:
-
Welcher Fehler wird denn da geworfen? Screenshot? Copy/Paste der Meldung?
-
deltapapa die Fehler aus deinem ersten Post sind keine jQuery-Fehler, sondern Fehler die ich entstehen weil jQuery eben garnicht vorhanden ist. Durch den entsprechenden unset in deinem Template unterdrückst du das Laden des Frameworks, weshalb sämtliche Codeschnipsel, die JQuery benötigen (z.B. alles rund ums Frontend-Editing, Tooltips, Modal-Dialoge etc) in einen Fehler laufen.
-
Noch ein kurzer Sachinput hierzu:
Joomla hat in seiner Historie insgesamt 5 verschiedene Techniken zum Speichern von Passwörtern verwendet.
1. MD5 ohne Salt - das betraf, wenn ich mich recht entsinne, die 1.0er und frühen 1.5er Versionen
2. MD5 mit Salt in eigenem Format - das betrifft die 1.5er und 2.5er Releases. An den Hash des Passworts wurde, durch ein Doppelpunkt getrennt, der Klartext Salt angehangen
3. MD5 mit Salt im /etc/passwd Format. Das betrifft, wenn ich mich richtig erinnere, J 3.0 und 3.1 - das sind die Hash’s die mit $1$ anfangen
4. SHA256 oder bcrypt beide mit Salt. Das ist der Stand von Joomla 3.2 und war die einzige Version, in der der Algorithmus vom Server abhing. „Gute“ PHP Versionen (5.3.10 oder neuer) hatten bcrypt, ältere Versionen haben mit sha256 gearbeitet.
5. bcrypt via Phpass bzw. password_hash - das ist der aktuelle Standard der mit vertretbarem Aufwand und bei gescheiten Passwörtern nicht zu knacken ist. Ist ab Joomla 3.3 aktiv.
-
Inwiefern kommt das PHP-Skript damit nicht zurecht?
-
vel.joomla.org wäre da der passende Ansprechpartner
-
So wie ich den letzten Stand des Issues verstehe ist die entsprechende Restriktion DB-Treiber-unabhängig eingebaut worden, obwohl das eigentlich nur für Postgres relevant ist. Es fehlt nur der passende Patch, der den Check verschiebt.
-
Mir fallen spontan mal mindestens 3 gute Gründe für die native Entwicklung ein:
1. Sourcerer und Co sind ein Sicherheitsrisiko. Wenn es einen Angreifer gelingt, einen Account mit „niedrigen“ Rechten (z.B. Manager) zu erhalten, kann er damit standardmäßig nicht den Webspace übernehmen weil er keinen Code ausführen kann. Sourcerer hebelt diese Rechteabstufung auf und führt somit die gesamt Rechteverwaltung ad absurdum.
2. Das lose einbinden ist keine saubere Lösung. Ich persönlich will gerne auf meinen Code schauen und guten Gewissens sagen können „jop, das ist ne saubere Umsetzung, dafür muss ich mich nicht schämen“. Bei einer „drangeflantschten“ Lösung wäre ich nicht glücklich.
3. Du entwickelst dich und deine Fähigkeiten weiter. Entwicklungshilfe-Pattern wie MVC oder andere „Must-Haves“ der modernen Entwicklung wie Datenbank-Abstraktion, Namespaes, Autoloading und co bilden zwar beim Einstieg in die Entwicklung erstmal eine steile Lernkurve, aber letztlich helfen Sie Dir, dein Wissen zu erweitern und besser zu programmieren.
-
-
Nimm mal den Doppelpunkt am Ende raus - geht es dann?
-
Was ist in der configuration.php als Wert bei $host hinterlegt?
-
Ein kleiner Veranstaltungshinweis: in knapp 3,5 Wochen, nämlich am 09.02 findet im Unperfekthaus Essen das JoomlaCamp statt! Das JoomlaCamp ist eine sogennante Unkonferenz, also eine Konferenz, bei dem das Programm direkt vor Ort zusammengestellt wird und sich somit perfekt an den Wünschen der Besucher orientiert! Kommt vorbei, bringt eure Wissenswünsche ein, lernt einen Berg neue Dinge und trefft außerdem viele bekannte Gesichter aus dem Forum!
Tickets gibts auf http://www.joomlacamp.de
-
Sowas lässt sich per Symlinks lösen, für Joomla macht das dann keinen Unterschied ob es ein „richtiger“ Images Ordner oder ein Symlink ist.
