Einbindung von jQuery

stefanek · 26.10.2016 23:37:38

grindbatzn schrieb:

zu jQuery:
WIe baut man andere Versionen richtig in WBCE ein? Bisher klemmte es immer an inrgendwas mit "insert" (glaub ich ad hoc)
in der rFG werden eigentlich nur ganz einfache Funktionen verwendet, die sollte an sich funktionieren - wenn denn jQuery überhaupt mal läuft.

Das ist ein wichtiges Thema, bevor es untergeht, wäre gut, wenn Du da ein Thema zu öffnest.

Gruß,
Christian

florian · 27.10.2016 08:51:20

Das ist ein wichtiges Thema, bevor es untergeht, wäre gut, wenn Du da ein Thema zu öffnest.

Was hiermit passiert ist.

1. Methode:
Im <head> des Templates

<?php echo register_frontend_modfiles('jquery'); ?>

einfügen.

WBCE bis einschließlich 1.1.6 hat jQuery 1.7.1 an Board. Wenn das zu alt ist, kann man
a) einfach den Inhalt der /include/jquery/jquery-min.js austauschen
b) auf register_frontend_modfiles('jquery'); verzichten und jQuery über CDN oder mit im Template-Verzeichnis abgelegte jQuery laden, also z.B.

<script type="text/javascript" src="<?php echo TEMPLATE_DIR; ?>/js/jquery-1.8.3.min.js"></script>

Dann aber unbedingt auch einfügen:

   <script type="text/javascript">
		var URL = '<?php echo WB_URL; ?>';
		var WB_URL = '<?php echo WB_URL; ?>';
		var TEMPLATE_DIR = '<?php echo TEMPLATE_DIR; ?>';
	  </script>

c) Das Modul libraryadmin + lib_jquery verwenden

Siehe dazu und allem anderen in epischer Breite hier

grindbatzn · 27.10.2016 22:07:33

"c) Das Modul libraryadmin + lib_jquery verwenden"

Das ist der Knackpunkt: Ich WILL das nicht verwenden, weil ich in aller Regel noch 32 andere Libraries installieren muss (das fällt dir - Stefek - wahrscheinlich nicht auf, weil du den Krempel immer mit dazu lädst - ich aber nicht)

Gehts auch OHNE c) ?

Beitrag geändert von grindbatzn (27.10.2016 22:11:25)

florian · 27.10.2016 22:34:07

Gehts auch OHNE c) ?

Wie meinen?

stefanek · 27.10.2016 22:47:21

grindbatzn schrieb:

(das fällt dir - Stefek - wahrscheinlich nicht auf, weil du den Krempel immer mit dazu lädst - ich aber nicht)

Du hast Dich wahrscheinlich in der Adresse geirrt.
Ich habe LibraryAdmin und ihre Vorläufer nie verwendet. Hauptsächlich aus dem selben Grund: zu viele Abhängigkeiten.

stefanek · 27.10.2016 23:02:06

grindbatzn schrieb:

zu jQuery:
WIe baut man andere Versionen richtig in WBCE ein? Bisher klemmte es immer an inrgendwas mit "insert" (glaub ich ad hoc)
in der rFG werden eigentlich nur ganz einfache Funktionen verwendet, die sollte an sich funktionieren - wenn denn jQuery überhaupt mal läuft.

Du meinst jQueryCore im Frontend, nehme ich an.

Persönlich habe ich nie diese

<?php echo register_frontend_modfiles('jquery'); ?>

Einbindung bei mir in den Templates verwendet, sondern jQueryCore über eine eigene kleine Funktion eingebunden.

Geht es Dir darum, wenn normalerweise jQueryCore über diesen Aufruf geladen wird, eines der jQuery Skripte aber eine höhere Version voraussetzt, Du eine höhere Version nachlädst, statt die, die mitgeliefert wird?

Ich finde das Thema wichtig. Wenn auch nicht einfach.
Grade weil es dazu führen kann, dass andere Skripte, die bereits installiert sind, nicht mehr mit der neueren jQueryCore Version laufen.

Edit:

grindbatzn schrieb:

Bisher klemmte es immer an inrgendwas mit "insert" (glaub ich ad hoc)

Ich denke nicht, dass mit insert etwas hier verkehrt war. Denn insert setzt jQueryCore voraus, also kannst Du damit nicht das jQueryCore austauschen.
Das kann man nur mit DOM Manipulation machen, entweder Serverseitig mit PHP oder im Browser, mit JavaScript.

... später mehr ...

Gruß,
Christian

Beitrag geändert von stefanek (27.10.2016 23:05:54)

stefanek · 28.10.2016 01:27:11

Ein Lösungsansatz wäre, es mit einem Droplet zu überschreiben.

if(!isset($src)) return;
if(is_string($src)){
	$sNewSource = $src;
	$jQueryCore = WB_URL.'/include/jquery/jquery-min.js';

	if(strpos($wb_page_data, $jQueryCore) !== false){
		$replace_jQuery = true;
	}else{
		$add_jQuery = true;
	}
}
if(isset($replace_jQuery))
	$wb_page_data = str_replace($jQueryCore, $sNewSource, $wb_page_data); 
if(isset($add_jQuery)) {
	$sElement = PHP_EOL.'<script src="'.$sNewSource.'" type="text/javascript"></script>'.PHP_EOL;
	$wb_page_data = str_replace('</title>', '</title>'.$sElement, $wb_page_data); 
}
return true;

Dann das Droplet:
[[jquery_version?src={vollständigeurl}]]
Beispiel: [[jquery_version?src=https://code.jquery.com/jquery-3.1.1.slim.min.js]]

Das Droplet ist noch etwas primitiv.
Wenn jQuery von woanders geladen wird und nicht von WB_URL.'/include/jquery/jquery-min.js';
endet es damit, dass man jquery doppelt geladen hat.

Wenn jQuery gar nicht geladen ist, wird die angegebene Version unterhalb vom </title> Element gesetzt. Was auch nicht so gut ist, da es unter CSS aber vor allem anderen JS sollte (wobei das läßt sich leicht korrigieren).
Was serverseitig kompliziert ist festzustellen, ist, ob jQuery geladen wurde. Und falls ja, über welchen Aufruf (welches Element im DOM) sodass man es dann richtig ersetzen könnte.

Das ist es, was das ganze kompliziert macht.

Christian

Beitrag geändert von stefanek (28.10.2016 01:28:42)

cwsoft · 28.10.2016 10:58:38

Hi,

das austauschen von jQuery für alles (Core, Module, Templates) ist nicht der Knackpunkt. Problem ist der Betrieb mehrerer jQuery Versionen ohne dass sich Core, Template oder spezielle Module in die Quere kommen. Hier vor allem die vielen jQuery Plugins die Teils neue, teils alte jQuery Versionen voraussetzen. Hat man dann einen Abschnitt mit z.B. Bildplugin für altes jQuery und einen Abschnitt mit Pagination für neue jQuery, greifen viele der Mechanismen nicht.

Gruss

stefanek · 28.10.2016 11:10:54

Das ist soweit klar.

stefanek schrieb:

Ich finde das Thema wichtig. Wenn auch nicht einfach.
Grade weil es dazu führen kann, dass andere Skripte, die bereits installiert sind, nicht mehr mit der neueren jQueryCore Version laufen.

Die Frage ist, wie löst man es?
Und wie weit will man mit der Lösung gehen?
Es geht nicht absolut DAU sicher.

Bei jeder Lösung wird man einige Kompromisse machen müssen.
So wie eben die Lösung die damals eingebaut wurde:

<?php echo register_frontend_modfiles('jquery'); ?>

eine sehr grobe Kompromis-Lösung war.

Es geht sicherlich besser, bzw. kann man diese Lösung noch verbessern.

Hier geht es mehr darum festzustellen, wie weit soll es gehen, ohne zu komplex und verwirrend für den User zu sein.
Und um das erörtern von Möglichkeiten der Umsetzung.

Beitrag geändert von stefanek (28.10.2016 11:15:09)

cwsoft · 28.10.2016 11:31:31

Hat sich schonmal jemand angeschaut wie andere CMS das handhaben? Das Problem haben ja nicht nur die WB Derivate. Evtl. gibt es dort ja passend Ansätze.

Eine Möglichkeit wäre z.B. das Bereitstellen einer WBCE globalen $ oder $_ Variable, der man z.B. als Parameter die benötigte jQuery Version übergibt und diese dann als Instanz zurückgibt. Hätte aber ne kleine Anpassung der Plugins zur Folge. Auch zu klären wäre das ganze jQueryUI und jQuery Plugins Thema. Da stecke ich aber nicht im Detail drin.

Gruss

stefanek · 28.10.2016 12:04:23

In diese Richtung hat sich viel getan bei WBCE 1.2.x
Es wird eine neue Class geben, die I/Insert Class.

Aber das ist zunächst ein "Unterbau" und genau der zweite Teil

Hätte aber ne kleine Anpassung der Plugins zur Folge.

und

Auch zu klären wäre das ganze jQueryUI und jQuery Plugins Thema.

ist, wo es komplex werden könnte, nicht nur für den DAU sondern auch für die Entwickler unübersichtlich.

Und selbst wenn alles aufeinander abgestimmt wird, man übergibt mit jedem Plugin die Dependencies (was braucht es: jQueryCore Version, UI, spezielle plugins wie easing etc.), hackt es wieder, weil doch noch ein inkompatibles Plugin mit auf der Seite ist.

Und diese Lösung würde dann auch nur innerhalb von WBCE funktionieren.

Die ursprüngliche Frage war:

grindbatzn schrieb:

WIe baut man andere Versionen richtig in WBCE ein?

Ich finde wir müssen da mehr ins Detail gehen. Wer Ideen, Ansätze hat, wäre gut, wenn wir die hier alle sammeln.

Auch: wie weit soll das ganze gehen?

Ich persönlich denke, was ausreichen sollte, wäre, dass man mit dem Laden von Plugins die Dependencies übergibt (braucht jQuery Version, easing, UI.sortable).

Was andere CMS oder Systeme allgemein angeht, ich denke nicht, dass irgendeines es komplett narrensicher hinbekommt. An einem Punkt muss man einen Kompromis machen zwischen dem Idealen und dem Machbaren bzw. Vertretbaren.

cwsoft · 28.10.2016 12:48:14

Wenn WBCE auf jQuery baut, würde ich eine jQueryCore Version zur Verfügung stellen, um Core Funktionalität (verschieben, etc.) sicher zu stellen, ohne dass Benutzer hier durch Austausch etc. Teile des Core lahmlegen.

Für Module und Templates eine einheitliche Einbindung und Bereitstellung von jQuery, z.B. über die bereits angesprochene $ Funktion (closure).

[== JavaScript ==]
// We define a function that takes one parameter named $.
(function ($) {
  // Use jQuery with the shortcut:
  console.log($.browser);
// Here we immediately call the function with jQuery as the parameter.
}(jQuery));

Statt einem jQuery Object könnte man so auch eine lokale jQuery oder CDN Version übergeben. Ist eine von vielen Möglichkeiten.

Gruß

Beitrag geändert von cwsoft (28.10.2016 12:50:23)

stefanek · 28.10.2016 13:15:02

Alle kein Problem, wenn man das ganze persönlich unter Kontrolle hat.

Die Kompliziertheit fängt an, wenn man es DAU sicher machen will.

Sicher kann man Empfehlungen schreiben, wie jQuery Plugins umschrieben werden sollten sodass sie alle nur mi der $ Funktion arbeiten.
Doch machen das alle?

Ich bin mir nicht sicher, wie Du das umsetzen würdest -- nicht, dass ich meine, dass Du es sollst oder Ähnliches, ich frag mich einfach, wie Du es umsetzen würdest, Schritt für Schritt, wenn Du es tätest.

Christian

cwsoft · 28.10.2016 14:53:06

Hi,

im Prinzip so ähnlich wie die WBCE Insert-Class oder die neue Datenbank-Class.

1. Trennung von WBCE jQuery für Core (Sortierung, jQuery-Datepicker und Co. etc.)
2. Bereitstellen eines globalen $ Objektes für jQuery (Default:= WBCE jQuery oder leer, evtl. Alias für $jQuery)
3. Insert Klasse erweitern um globale $ Objekt zu ändern (jQuery Version, evtl. jQuery Plugins)
4. Einbinden von jQuery Plugins über Closur-Aufruf (Wrapper --> so greift jedes Plugin auf das $ zu das es benötigt)
4. Deprecated Meldung für WBCE 2.x für alle alternativen Aufrufe (z.B. register_frontend_modfiles, etc.)
5. Evtl. Frontendfilter für Uralt Code

So machen das auch einige andere CMS Systeme. Ist aber wie gesagt nur eine von vielen möglichen Optionen.

Gruß

grindbatzn · 28.10.2016 15:01:58

Mal eine blöde Frage:
Grundsätzlich ist ja alles jQuery-Zeugs in /include/jquery/
Wenn ich einen Ordner jquery-irgendwas und in der index.php (root) ganz unten vor echo $output; reinmache:
$output = str_replace('/include/jquery/', '/include/jquery-irgendwas/', $output );

Dann kann ich testweise jede beliebige jQuery-Version (mitsamt Plugins) einhängen. Öder?

cwsoft · 28.10.2016 15:08:45

jQuery Version tausche ich so auch global (einfach jquery_alt / neue Kopie rein).

Bei Plugins und jQueryUI funktioniert das oft nicht ganz so einfach, da manche Plugins eine gewisse jQuery Version voraussetzen und nicht kompatibel zu neuen Versionen sind. Leider werden sehr viele jQuery Plugins nicht aktiv gepflegt, was das ganze nicht wirklich erleichtert.

Für sowas gibt z.B. in Python sogenannte virtual environments. Ähnlich ist auch die Idee hinter dem $ JS-Closure. Sprich ich übergebe dem jQuery-Plugin beim Aufruf die jQuery-Version (Objekt, Pfad, URL) die es benötigt und innerhalb dieser Funktion greift das Plugin dann auf $ zu. Also eine Art Wrapper. In der Regel merkt das jQuery Plugin davon nichts, es muss halt etwas anders eingebunden werden.

stefanek · 28.10.2016 15:23:55

grindbatzn schrieb:

Mal eine blöde Frage:
Grundsätzlich ist ja alles jQuery-Zeugs in /include/jquery/
Wenn ich einen Ordner jquery-irgendwas und in der index.php (root) ganz unten vor echo $output; reinmache:
$output = str_replace('/include/jquery/', '/include/jquery-irgendwas/', $output );
Dann kann ich testweise jede beliebige jQuery-Version (mitsamt Plugins) einhängen. Öder?

Wenn's Dir nur darum geht, dann kannst Du das mit einer leichten Abwandlung des hier beschriebenen Droplets machen. Dann musst Du nicht am Core frickeln.

Ich bin aber davon ausgegangen, dass Du über eine allgemeine Lösung nachdenkst, mit der auch andere etwas anfangen können.

stefanek · 28.10.2016 15:31:00

@cwsoft

Danke. Ja, eine Möglichkeit von vielen.
Ich denke, alleine das Setzten von register_frontend_modfiles() auf Deprecated ruft bei einigen ein mulmiges Gefühl hervor.

Ich werde mir nach dem Release der 1.2.x einige Gedanken dazu machen.

Doch ohne eine größere Beteiligung mehrerer Leute in diesem Thread, wird da nicht viel passieren können.
Es gibt eben zu viele Möglichkeiten. Und keine von ihnen ist perfekt.

Also: bringt eure Erfahungen mal in die Gesprächsrunde. Was braucht ihr, was fehlt, was stört.
Oder einfach lassen wie es ist?

Gruß,
Christian

cwsoft · 28.10.2016 15:45:32

stefanek schrieb:

Ich denke, alleine das Setzten von register_frontend_modfiles() auf Deprecated ruft bei einigen ein mulmiges Gefühl hervor.

register_frontend_modfiles macht was genau? Es schaut nur ob Module ne frontend.css, frontend.js etc. haben und bindet diese Datei dann ein. Der jQuery Aufruf lädt das WBCE jQuery. Es gibt keine Möglichkeit das nur für Modul A, oder für Modul B wenn zuvor/danach eine Sektion vom Typ X kommt ... zu laden. Das meiste ersetzt bereits die Insert Klasse, sogar etwas besser justierbar, bzw. kann mit Droplets, bzw. den neuen Modulfunktionen (Hooks) realisiert werden. Stellt WBCE noch ein JS $-Objekt bereit, kann man register_frontend_modfiles komplett ersetzen. Notfall auch per Filter. Sprich es gibt aktuell bereits 3-4 Möglichkeiten die alte register_frontend_modifles Funktionalität zu ersetzen.

Daher habe ich das auch für 2.x vorgeschlagen und nicht für 1.2.x. In 2.x wird es sicherlich das ein oder andere nicht 100% abwärtskompatible Feature geben. Aber wenn das alles so behutsam wie im Moment gemacht wird, sehe ich für den Anwender keinen großen Nachteil (siehe Insert-Klasse, DB-Klasse, neue Modulfunktionen, neue Sprachdateieinbindung, neue Passwortverschlüsselung ...). Das meiste wurde rückwärtskompatibel implementiert. Aber irgendwann muss man sich halt fragen ob mann Sachen von 2007 auch im Jahr 2016 noch mit herumschleppen will. Gut MS hat seit Windows 1.0 das olle MS DOS als Unterbau bis Windows ME mitgeschleppt, aber das muss man sich ja nicht zum Vorbild nehmen.

Aber es wird Off-Topic. Denke ich habe meine Ideen für jQuery eingebracht, gibt es weitere Ideen dazu?

Beitrag geändert von cwsoft (28.10.2016 16:12:40)

stefanek · 28.10.2016 17:54:20

Danke CWSoft.

Gute Ausführungen.

Das gute an der I/Insert Klasse ist, dass man im Frontend Template nichts ändern muss, dass sie wirkt.

Um die Templates nicht ändern zu müssen (und sie auch kompatibel zu halten), könnte der Aufruf "register_frontend_modfiles()" im Template bestehen bleiben, vom System aber auf "leer" gesetzt werden (keine Ausgabe).

Die Verwendung der frontend.css /.js könnte in Zukunft auch obsolet werden. Oft will man für ein und das gleiche Modul ganz andere Ausgaben haben (und unterschiedliche CSS/JS Dateien verwenden wollen), wenn sie in mehreren Sections verwendet werden. Mit der I/Insert Methode kein Problem. Aber das ist jetzt etwas am Thema vorbei.

Jedenfalls ja, es gibt viele Möglichkeiten jQuery Core anders zu verlinken.
Die gab es schon immer, eigentlich, aber vom System wurde bis jetzt eben nur das "mitgeliefert".

Ich habe einen guten Ansatz, wie man es lösen kann, dass man beim Laden von jQuery-Plugins die jQ-Core Vorraussetzungen mit angibt.
Also im Beispiel, mein Template hat einen Slider der ein jQuery von Version 2.1.1. vorraussetzt.
Ich verlinke das Plugin und gebe die dependency mit an.

Doch im Moment ist dieser Thread noch nicht richtig Aufschlußreich.
Da ich für mich persönlich mit jQuery gut zurecht komme, ist diese Runde hier mehr dazu gedacht, zu erörtern, was anderen fehlt, womit sie nicht zurecht kommen, was sie global gerne im System hätten.

Ich helfe gerne bei der Umsetzung, wenn ich weiß was wie gebraucht wird.

Christian

cwsoft · 28.10.2016 18:04:18

Na dann. Was mir beim Umgang mit jQuery, jQueryUI und jQuery Plugins derzeit fehlt:

a) EINEN bevorzugten und dokumentierten Weg der künftig weiter unterstützt wird statt XXX Möglichkeiten
b) Option jQuery lokal oder von CDN einzubinden und zwar aus: PHP, HTML (Template) und JS (z.B. Insert Klasse)
c) Möglichkeit für verschiedene Module/Seiten/Sektionen verschiedene jQuery Versionen zu verwenden (ohne jQuery Kompatibilitätsmodus)
d) Möglichkeit verschiedene Plugins für verschiedene jQuery Versionen auf einer Seite nebeneinander herlaufen zu lassen ohne viel Frickeln
e) Möglichkeit jQuery bei Bedarf nachzuladen (für Module auf Seiten/Sektionen wo es gebraucht wird)
f) Möglichkeit jQueryUI Komponenten bei Bedarf zu laden (statt alles auf einmal)

Einiges davon geht schon. Am meisten fehlt mir ein "einheitlicher und zukunftssicherer" Weg das ganze über eine einfach zu bediendende API aus PHP, HTML (Template) bzw. JS aufzurufen.

Gruss

Beitrag geändert von cwsoft (28.10.2016 18:05:01)

stefanek · 28.10.2016 18:31:50

Ich finde, Du hast es gut zusammen gefasst. Ich denke, das ist das Ziel.

Ich würde höchstens noch ergänzen:

g) leicht zugängliche, übersichtliche Dokumentation, damit man es schnell erlernen und in Anwendung bringen kann (auch als DAU).

ein negativ Punkt der sich daraus ergibt:

h) Kompatibilitätsbruch mit kleineren Versionen und verwandten CMS's

Gruß,
Christian

Beitrag geändert von stefanek (28.10.2016 18:32:15)

cwsoft · 28.10.2016 19:23:42

stefanek schrieb:

ein negativ Punkt der sich daraus ergibt: Kompatibilitätsbruch mit kleineren Versionen und verwandten CMS's

Der Bruch ist bereits in WB 1.2.x implementiert, wirkt sich derzeit aber noch nicht aus, da es noch keine Module gibt, die die neuen Möglichkeiten des WBCE 1.2.x Entwicklungszweiges verwenden.

Dies wären z.B. die neuen Hooks für die Module (info.php), die Insert-Klasse, die neue DB-Klasse (ORM), der Autoloader für Klassen (ohne require_once) ...

Wenn ein Modul die neuen praktischen Methoden des WBCE Cores nutzt, heisst das zwangsläufig einen Bruch mit den anderen WB-Derivaten. Über kurz oder lang wird das eh kommen, da auch die Derivate ähnliche Funktionen einbauen, bzw. bereits eingebaut haben, die aber alle leicht anders aufzurufen sind etc. Eine langfristige Addon-Kompatibilität zwischen den WB Derivaten sehe ich nicht. Ist ja auch der Sinn von Forks, sich eigenständig und selbstständig weiterzuentwickeln und eigene neue Wege zu beschreiten. Sonst bräuchte es die Forks ja nicht.

Gruß

stefanek · 28.10.2016 19:56:35

Mich musst Du da nicht aufklären. Es gibt aber noch Leute, die sich um eine Kompatibilität bemühen oder sich eine solche wünschen.
Mir persönlich ist z.B. eine Kompatibilität zu dem WB Fork "DarkViper CMS" völlig schnuppe.

florian · 28.10.2016 21:04:11

Hui, das Thema nimmt ja echt Fahrt auf.

Was ich praktisch fände: Wenn das Frontend-jquery unabhängig vom Backend-jquery wäre. Weil nämlich allerlei Sortierscripte im Backend ältere jQ-Versionen voraussetzen, als z.B. von Bootstrap unterstützt werden. (Nur als Beispiel, meine "große" Begeisterung für Bootstrap sollte ja hinlänglich bekannt sein).

Ansonsten: Vom Prinzip her ist der Ansatz von lib_jquery / library_admin aus Anwendersicht super. Sprich, man installiert ein Modul und lädt dann Mini-Module nach und muss im Idealfall nicht eine Zeile Code schreiben.
Mit der Handvoll Bibliotheken, die für diese Module installiert werden müssen, habe ich kein Problem. Was mich wirklich davon abhält, dieses Modul zu verwenden, ist dessen unschöne Angewohnheit, Inline-Styles zu zerschießen und die für mich undurchschaubare Logik, ob und wann die einzubindenden Codefragmente nach einer Bearbeitung übers Backend neu eingelesen werden.

WBCE CMS Forum

#1 26.10.2016 23:37:38

Einbindung von jQuery

#2 27.10.2016 08:51:20

Re: Einbindung von jQuery

#3 27.10.2016 22:07:33

Re: Einbindung von jQuery

#4 27.10.2016 22:34:07

Re: Einbindung von jQuery

#5 27.10.2016 22:47:21

Re: Einbindung von jQuery

#6 27.10.2016 23:02:06

Re: Einbindung von jQuery

#7 28.10.2016 01:27:11

Re: Einbindung von jQuery

#8 28.10.2016 10:58:38

Re: Einbindung von jQuery

#9 28.10.2016 11:10:54

Re: Einbindung von jQuery

#10 28.10.2016 11:31:31

Re: Einbindung von jQuery

#11 28.10.2016 12:04:23

Re: Einbindung von jQuery

#12 28.10.2016 12:48:14

Re: Einbindung von jQuery

#13 28.10.2016 13:15:02

Re: Einbindung von jQuery

#14 28.10.2016 14:53:06

Re: Einbindung von jQuery

#15 28.10.2016 15:01:58

Re: Einbindung von jQuery

#16 28.10.2016 15:08:45

Re: Einbindung von jQuery

#17 28.10.2016 15:23:55

Re: Einbindung von jQuery

#18 28.10.2016 15:31:00

Re: Einbindung von jQuery

#19 28.10.2016 15:45:32

Re: Einbindung von jQuery

#20 28.10.2016 17:54:20

Re: Einbindung von jQuery

#21 28.10.2016 18:04:18

Re: Einbindung von jQuery

#22 28.10.2016 18:31:50

Re: Einbindung von jQuery

#23 28.10.2016 19:23:42

Re: Einbindung von jQuery

#24 28.10.2016 19:56:35

Re: Einbindung von jQuery

#25 28.10.2016 21:04:11

Re: Einbindung von jQuery

Fußzeile des Forums