Diskussion rund um JQ, JS und alles Mögliche

[Yetiie]

Versucht, möglichst alles JS (vor allem JQ) nach unten ans Ende des Body zu schieben (frontend_body.js).

...

Es wird sofort im Multitasking das HTML übertragen und auch sofort angezeigt. Dann erst kümmert sich der Browser um das langsamere JS. Eine etwas umfangreichere Seite mit viel JS wird dadurch optisch deutlich schneller aufgebaut.

Naja, das Thema ist so alt wie JS/JQ und Konsorten selbst und sollte eigentlich bekannt sein. Übrigens: trotzdem packen immer noch viele auch große Seiten JS-Dateien immer noch an den Anfang ... und ich glaube das tun die meisten Module hier in WB auch. Das mag einerseits an der 'bequemen' Code-Organisation liegen wie aber aber auch an der fehlenden Bekanntheit von frontend_body.js

Was zu dem Thema dazu gehört (und sich noch nicht unbedingt überall rumgesprochen hat glaube ich) ist, dass das CSS eines Moduls vor der JQ eines Moduls geladen sein sollte ...



Andererseits:
---------------------------------

Schaue ich mir die großen Templates im Modern-Webdesign an   ...
... spielt das zukünftig wohl eine immer kleinere bis gar keine Rolle mehr.

Da soll HTML ohn JQ-Bearbeitung gar nicht angezeigt werden und sieht auch gar nicht aus ... keiner mag sehen, wie sich das HTML verändert oder es nicht wie gewünscht zucken kann. Entsprechend wird diese Anzeige in extremen Fällen in den Tempaltes dann auch gezielt durch Sandglass-Signs ersetzt. Wobei die langen Ladezeiten auch aber nicht nur durch die JS/JQ-Scripte geschuldet sind sondern auch durch die großen Background-Images ...

Ganz wichtig um Missverständnissen vorzubeugen: Das gilt natürlich nicht für alle ... aber diese Form der Templates nimmt zu und stellt sicher so was wie die Zukunft dar. Mag man es mögen oder nicht.




Some points for optimzing:
---------------------------------------------

Bei der Beschleunigung der Ladezeiten spielt übrigens nicht mehr unbedingt die Größe der Dateien (sofern es nicht die Mega-Background-Images sind) die entscheidende Rolle sondern die Anzahl der Dateien (HTTP-Requests) bzw. das Browser-Caching:

(A)
So macht es durchaus Sinn die JQ-Bibliotheken u.ä. von Google zu beziehen statt von der eigenen Seite, weil die oft schon von vorhergehenden Besuchen auf anderen Seiten im Browsercache vorhanden sind ... und dann gar nicht mehr geladen werden müsen. Man mag Google mögen oder nicht ... ich bin Nicht-Möger ... aber der Vorteil ist tatsächlich nicht unbeachtenswert und das Nutzen macht druchaus Sinn.

(B)
Ebenfalls macht es Sinn, die CSS-Dateien und JS-Dateien einer Seite in jeweils einer Datei zusammen zu fassen und in eienr Datei einzubinden anstatt für jede einzelne Seite zu optimieren. Das reduziert die Anzahl der Requests und ist schon auf auf einer Einzelseite mit individuell zusammen gestellten Scripten deutlich schneller.

(C)
Kombiniert man A+B baut kann man die CSS- bzw. JS-Dateien für ein Gesamtprojekt zusammenfassen anstatt die Einzeldateien pro Seite (je nachdem welcher Codeschnipsel für die spezielle Seite benötigt wird) zu optimieren. Ab dem zweiten Seitenaufruf steht es dann im Cache zur Verfügung ... was ein Laden wiederrum unnötig macht ... die Sanduhr wird dann im Zweifel nur beim ersten mal geschüttelt, - wenn durch die reduzierten Requests überhaupt.

Punkt C ist für mich der Grund, warum ich register-modfiles kaum benutze.




Anregung: Was kann WB für uns tun:
-----------------------------------------------------------------

Für WB würden sich daraus zwei Anregungen zur Optimierung der register_frontend_m odfiles() ergeben:


(1)

Die Funktion erweitern und anbieten, die großen Frameworks anstatt vom eigenen Server von den Google-Libraries zu laden, ... natürlich nur von dem der möchte.

Das könnte man realisieren indem man die Funktion 'register_frontend_m odfiles('jquery')' um einen optionalen Parameter 'register_frontend_m odfiles('jquery', 'google') erweitert.

Klasse wäre es auch, wenn man dann dort eine Liste anlegt, so dass man nicht 'jQuery' sondern auch die Version zur Auswahl stellt. Muss sich ja nicht nur auf jQuery beziehen ...

Der Aufwand für diese Lösung wäre übrigens wahrscheinlich noch recht übersichtlich, da ja nur die Links hinterlegt werden müssten ... und der Aufwand für die Einrichtung neuer Frameworks oder der Pflege oder Diskussion 'warum ist die nicht drin' entfiele in großen Teilen.

(BTW.: Was mir fehlt oder nicht weiß wie es ginge ist, in der WB-Installation eine eigene Bibliothek zu hinterlegen, die dann mit register_frontend_m odfiles() geladen werden könnte ... so könnte jeder selbst die JQ-Version aufrüsten oder gezielt andere Frameworks nachschieben die er braucht ...


(2)

Die Dateien, die Mod-Dateien, die von WB geladen werden könnten automatisch (jeweils CSS und JS zusammen) zusammengefasst und dann als eine Datei geladen werden. Im Prinzip Präprozessing wie bei SASS.

Ein Beispielscript dazu gibt es hier (habe aber keine Erfahrung damit): http://www.ejeliot.com/blog/72

Das könnte unterteilt werden: Große Frameworks separat (die müssen ja teilweise anders behandelt werden), alles andere wir zusammengeschoben

Schwieriger wäre Optimierung hinischtlich Punkt (C): Alle CSS/JS-Dateien der verschiedenen Einzelseiten zusammen zu fassen um sie in einer Datei zu laden. Da müssten wahrscheinlich die JS/CSS-Dateien aller installierten Module zusammengefasst werden ... wäre für mich aber zunächst eine nachfolgende Ausbaustufe und ich kann aktuell nicht abschätzen, ob das wirklich sinnvoll wäre.

[jacobi22]

aber auch an der fehlenden Bekanntheit von frontend_body.js

gibs aber schon seit WB 2.7.0  bzw seit 2009, steht im changelog und ist auch im Forum in diversen Threads zu finden

zum Rest: ich ahne schon, das das jezt wieder einer der sinnlosen Framework-Diskussionen wird und klink mich hier mal aus.
Nochmals mein Dank an euch für euren Einsatz

[Yetiie]

Danke für den Hinweis zur Framework-Diskussion

Ne, darüber (Frameworks) bitte nicht diskutieren. Es geht hier um Möglichkeiten der Optimierung zur Seiten-Ladegeschwindigkeit nicht um den Einsatz von Frameworks. Eine Bitte um Aufnahme spezieller Frameworks in das WB-Standard-Paket ist in diesem Thread außerdem NICHT gefallen

...

So: Es waren lediglich Anregungen zur (ggf. automatisierten) Ladezeiten-Optimierung.
Nicht mehr. Nicht weniger. Und auch das sollte nicht als 'Muss' verstanden werden

Die Idee der vereinfachten Einbindung von der Google-Librarie hat aber sicher einen Charme.
Auch wenn man den Link ganz einfach selbst setzen kann bzw. setzt ...

Und es ist (naja bei WB muss man sagen: wäre ...) mit überschaubarem Aufwand außerdem wieder etwas für's Marketing:
WB --> nutzt Google Libraries --> Google modern --> WB modern --> Journalisten und Blogs wollen Futter haben *g

Selbiges gilt auch für das ganz anders leider wohl nicht unaufwendige Präprozessing.
Das(!) wäre wirklich eine dolle Sache denke ich. Denn das ist ein Trend ...

[DarkViper]

Ne, darüber (Frameworks) bitte nicht diskutieren. Es geht hier um Möglichkeiten der Optimierung zur Seiten-Ladegeschwindigkeit nicht um den Einsatz von Frameworks. Eine Bitte um Aufnahme spezieller Frameworks in das WB-Standard-Paket ist in diesem Thread außerdem NICHT gefallen

Es gibt auch für Frameworks keinerlei Diskussionsgrundlag e. Wir sind dabei, bei WB auf eine 100% komplette Trennung von Code und Anzeige hin zu arbeiten. Sobald wir diesen Punkt erreicht haben, interessieren uns keine Frameworks und keine optischen Trends mehr, da dieses dann einzig und vollkommen den Designern der Anzeigeschicht überlassen bleibt. X-beliebige Optik...  ohne auch nur eine Zeile des eigentlichen Quellcodes ändern zu müssen. Das ist unser Ziel.
Inwieweit hier die Addons (bis auf die Standardaddons) mitziehen werden, das liegt leider nicht in unserer Hand.

Manuela

PS:  Lokale JS- und CSS-Dateien jeweils zusammenzufassen ist kein Problem.. und auch bereits auf der ToDo. Beides in eine einzige Datei gibt Probleme, da dann 2 völlig verschiedene Mime-Typen in einer Datei vereinigt werden müssten... und DAS ist nicht trivial und überfordert die Browser, da diese Daten anhand des Mime-Typs bzw. des zu einer Datei gesendeten Mime-Headers einer Datei erkennen.
(binde einfach mal eine JS oder CSS Datei ohne Dateierweiterung ein... wirst sehen, dass das problemlos funktioniert)

[jacobi22]

Und es ist (naja bei WB muss man sagen: wäre ...) mit überschaubarem Aufwand außerdem wieder etwas für's Marketing:
WB --> nutzt Google Libraries --> Google modern --> WB modern --> Journalisten und Blogs wollen Futter haben *g

Hatten wir gestern schon mal...
was für den einen ein Non-Plus-Ultra ist, ist für den anderen Murks. Es gibt im Forum gefühlte 100 Beiträge, in denen erklärt wurde, warum genau das (Google Lib) nicht angewendet wurde und wohl auch nicht wird. Ich bin mir z.b. sicher, das es auf Schlag hunderte Postings geben wird, das dieses oder jenes Plugin nicht mehr läuft. Der große Teil der aktiven Leute hier wird das handhaben können, aber die, die wirklich nur ein einfaches CMS bedienen wollen, die schon seit zig Jahren eine WB 2.6.5 laufen haben, stehen nachher eben hilflos da

[Yetiie]

Ups ...

JS- und CSS-Dateien jeweils zusammenzufassen ist kein Problem.. und auch bereits auf der ToDo. Beides in eine einzige Datei gibt Probleme ...

Ne, so war das nicht gemeint und ist auch nicht State off the Art bzw. so weit geht das dann doch nicht. Selbstverständlich ist gemeint: JS zu JS und SCC zu CSS ... zwei statt 15 Request ist immer noch eine gute Quote, da muss man nicht auf 1: 15 kommen   Außerdem glaube ich würden bei CSS + JS zu Universal die Anwender streiken bzw. die Funktion nicht nutzen ...

Die Zahl 15 ist natürlich fiktiv und schwankt erheblich

Bin dann mal gespannt, wobei das Preprozessing ja nur ein Teil der Optimierung ist ...

[Yetiie]

was für den einen ein Non-Plus-Ultra ist, ist für den anderen Murks.

Absolut dacor ... darüber zu Diskutieren ob Google-Einbindung der richtige Weg ist genauso wie über den Einsatz von Frameworks zu diskutieren: sinnlos! Jeder geht den Weg so wie er es für richtig hält und das ist auch gut so. Und mal ist das eine besser, mal das andere.

Der Vorschlag ist daher auch die optionale Möglichkeit des Ladens vom Google-Server zu integrieren. Gleichzeitig bietet er gerade wegen der größeren Wahlfreiheit und des geringeren Pflegeaufwands mehr Flexibilität.

Ich bin mir z.b. sicher, das es auf Schlag hunderte Postings geben wird, das dieses oder jenes Plugin nicht mehr läuft.

Das kann ich nicht nachvollziehen.

Ad1: Die Einbindung von Google wurde als optionale und nicht als Standard-Lösung vorgeschlagen. Module sollten also schon von daher keine Probleme bekommen es sei denn die Entwickler hier entscheiden, dass es Zeit ist auf eine aktuellere Sprachversion umzustellen wie das aktuell der Fall ist ...

Ad2: Kein Modul wird nicht laufen wenn eine JQ v1.7.1 vom Google-Server statt vom eigenen Server geladen wird. Das ist dem Modul total egal woher die selben Textzeilen stammen bzw. von wo sie referenziert sind, denn sie sollen ja nicht geladen werden, weil sie sind ja schon da, spricht der hoffende Ladezeitenoptimiere r   

Der große Teil der aktiven Leute hier wird das handhaben können

Naja, - so gesehen: ja natürlich. Wobei der große Teil der aktiven Leute hier die das handhaben können und(!) das umsetzen möchten ... setzen das schon heute um. Einen Link im Template zu schreiben ist ja nun wirklich nicht schwer (mal abgesehen vom blöden Escapen s.o. *g)

Aber jedes moderne Angebot macht - wenn man es geschickt verpackt - ein CMS attraktiver. Und für die 'Fortgeschreitenden' so etwas ein klein Tick komfortabler zu machen ... ist ja nicht unbedingt verkehrt 

[jacobi22]

Aber jedes moderne Angebot macht - wenn man es geschickt verpackt - ein CMS attraktiver. Und für die 'Fortgeschreitenden' so etwas ein klein Tick komfortabler zu machen ... ist ja nicht unbedingt verkehrt

da teilen sich unsere Meinungen.
Ich hab hier ein paar hundert User, die ein WB privat oder beruflich nutzen und 90% davon wissen garnicht, was JQuery ist und wollen es auch garnicht wissen. Es geht nicht mehr um "das einfachste CMS der Welt", sondern nur noch darum, es den Fortgeschrittenen einfacher zu machen. Was meinst du denn, wer sich dann schöne TWIG-Templates baut?  Das bist vielleicht du oder ich, ein paar Modul-Autoren wie cwsoft oder Stefek, aber keinesfalls die User, die z.b. im Forum fragen, wie sie denn eine Überschrift im Template XY größer machen können.

Ich neige ja dazu, eine Beitragstrennung zu beantragen, aber erklär mir doch mal, warum ein Fremdzugriff auf eine Google-Datei Ladezeitoptimierend er sein soll als der Zugriff auf die gleiche Datei am lokalem Server. Vielleicht bin ich ja doof und vielleicht sollt ich auch einpacken, weil das, was hier kommt, nichts mehr mit dem zu tun hat, wofür WB mal stand.

Die Projekte, die ich in diesem Jahr mit WB gemacht habe, nutze alle die aktuelle JQ 1.11, das wird zwar nicht über Google geladen, wäre aber auch nicht das Problem, solang ich das einbinde oder ich dem User mit Zeilennummer sage, wo er das machen muß. Nicht einer würde sich trauen, da selbst etwas zu ändern oder, wo auch immer, zu verstellen. Wer hat also den Nutzen? Der Fortgeschrittene, der am Ende 3 Dateien weniger bearbeiten muß.
Meinst du wirklich, du gewinnst einen neuen Benutzer, wenn du jetzt diese Option zur Auswahl der JQ-Quelle hättest?
Das als Pressemeldung wird genau so ein Hammer wie Bilder von mir, wo ich naggisch vorm Reichstag tanze 

Ein CMS lebt von der Vielseitigkeit im Einsatz, von der Anzahl der Module und Templates, aber nicht von einem Schalter im Backend

[Yetiie]

erklär mir doch mal, warum ein Fremdzugriff auf eine Google-Datei Ladezeitoptimierend er sein soll als der Zugriff auf die gleiche Datei am lokalem Server.

Naja, der erste Teil stand ja schon oben:

Das  wichtigste Zauberwort dazu heißt Caching. Moderne Browser Cachen die Dateien, die sie geladen haben. Wurde eine Datei (auch wenn sie von einer anderen Seite aus aufgerufen wurde) schon mal geladen spart sich der Browser die Mühe beim zweiten mal. Also: Hat der Surfer schon mal eine Seite aufgerufen bei der z.B. die spezielle JQ-Datei von Google aus geladen wurde und kommt auf die WB-Seite, die die selbe Datei verlangt ... ist sie schon da. Referenziert man die großen Frameworks auf die Google-Bibliothek ist die Wahrscheinlichlicke it recht hoch, dass sie schon von anderen Seiten gecacht ist ... naja die Menge machts. Ohne diesen Trick (auch das Cachen der Seiten des eigenen Webauftritts, weil auch dort Dateien auf der zweiten aufgerufenen Seite oder beim Wiederbesuch receicelt werden) wären die Lade-Gechwindigkeiten in den Browsern deutlich langsamer.

Das zweite Zauberwort heißt Hochverfügbarkeitss erver. Es ist sehr unwahrscheinlich, dass ein Server bei einem 0-8-15-Provider an die Übertragungsgeschwi ndigkeiten und Verfügbarkeiten der Google-Server heran kommt, zumindest was die üblichen (auch großen) Hoster von WB-Seiten betrifft. Die Hochverfügbarkeit gilt übrigens auch für andere Server wie die von MS, FB, Twitter, Amazon ... unter Beweis stellt das Googl laufend unter anderem Analytics oder Google-Schriften bei denen genau diese Technik die Grundlage bildet ... und dort nicht wirklich in Frage gestellt wird genauso wenig wie bei der Einbindung von FB-, Google-Werbenetzwerk oder Twitter-Codes. Das alles würde nicht funktionieren, würde die Technik nicht entsprechend überdurchschnittlic h performant funktionieren. Also: auch diesbezüglich schnellere Reaktion und schnellere Ladezeiten.

Eine interessante Infos dazu: Der Effekt dieser Hochverfügbarkeits-Server ist messbar. Amazon: zwei zehntel(!) langsamere Ladzeiten (wir reden vom Durchschnittswert) = Umsatzverluste je Std. im sechstelligen Bereich (kein Witz, von Amazon selbst gezielt reduziert und getestet). Für die meisten WB-Seiten möglichweise nicht relevant weil andere Liga und andere Aufgabenstellung. Aber es macht die von Dir erfragte Wirksamkeit der Spitzen-Technik auch von dieser Seite aus deutlich.

Es geht nicht mehr um "das einfachste CMS der Welt", sondern nur noch darum, es den Fortgeschrittenen einfacher zu machen.

Bei dem Wunsch nach Einfachheit leigen wir auf einer Linie. Das ist aber kein Wiederspruch dazu, es gerade den Fortgeschrittenen schmackhaft zu machen. Denn sie erstellen die schönen Templates (egal ob mit oder ohne TWIG) ... und sind die Multiplikatoren. Und ich weiß nicht, ob die Attraktivität für diesen Personenkreis in der letzten Zeit zugenommen hat. Die Rückmeldungen und beobachtbaren Reaktionen häufen sich, das WB in dieser wichtigen Gruppe eine zunehmend geringere Rolle spielt.

Außerdem: So gesehen sieht die Zukunft von WB düster aus. Das Abschaffen von 'echo' oder - was ich heute zufällig gesehen habe - von 'Konstanten' wie die dem entgegen gestellte zunhemende Klasserities (sei sie nun notwendig oder nicht) ... was ich hier jetzt nicht generell kritisieren möchte und natürlich ein wenig überspitzt Formuliert ist ... geht genau in die von Dir bedauerte Richtung. Und in diesem Punkt teiel ich Deine Befürchtung ganz generell.

Das als Pressemeldung wird genau so ein Hammer wie Bilder von mir, wo ich naggisch vorm Reichstag tanze 

Ich denke, da haben wir unterschiedliche Vorstellungen aber auch Erfahrungen in dem Bereich dieser Arbeit.  Lass uns das bitte mal beiseite schieben und einfach sagen: unterschiedliche Sichtweisen und Vorstellungen sind auch hier erlaubt. Allgemein und ohne groß oder allzuweit auseinander zu liegen denke ich kann man aber wohl sagen: Wünschenswert für WB wären sowohl (mehr) Themenfutter wie auch eine aktive(re) Betätigung auf diesem Gebiet, was WB tatsächlich(!!!) mit extrem hoher Wahrscheinlichkeit mehr Zuwachs bringen würde als eine neue Version oder besser programmierter Code 

Die Projekte, die ich in diesem Jahr mit WB gemacht habe, nutze alle die aktuelle JQ 1.11,

Mmmh ... mein WB nutzt 1.7.1 wenn ich mich gerade nicht verguckt habe. Die meisten meiner Seiten würden mit 1.1 nicht laufen ... und einige Module hier haben doch trotz allem recht aktuelle JQ-Module integriert meine ich ... also 1.1 macht mich da irgendwie stutzig ... aber eine feurige Hand möchte ich dafür jetzt nicht riskieren ... und register_frontend ist mir speziell diesbezüglich tatsächlich nun auch wirklich egal, gerade deshalb, weil ich die Version nicht steuern kann, - fände eine Einsatzmöglichkeit in der oben beschriebenen Form aber durchaus reizvoll.

Ich neige ja dazu, eine Beitragstrennung zu beantragen

Naja. Off-Topic ist das schon länger. Das stimmt.
Aber soweit ich verstanden habe war Deine Fragestellung heute früh schon gelöst, oder habe ich das falsch verstanden gehabt? Und die Entwicklung zum Thema JQ schneller Laden war ja eigentlich keine zwanghafte ... 

[DarkViper]

Eine kleine Erinnerung so zwischendurch:
Vor (soweit mein Alzheimer mitspielt) ca. ein bis anderthalb Jahren hatte Google einen netten Systemausfall... und hunderttausende Websites waren über mehrere Stunden nicht mehr erreichbar....  weil alle vergeblich versucht haben JS von Google in ihren Head zu laden...  
Was auf meinem Server liegt, wird ausgeliefert wenn meine Seite erreichbar ist.. unabhängig von fremden Infrastrukturen... und ohne Tracking.

Und Uwe, auch wenn auf OOP umgestellt wird... das ursprüngliche Ziel von WB bleibt mindestens solange erhalten, solang ich hier Code produziere.

Ältere werden lernen müssen... und Jüngere? Ich seh's an meinem Sohn. Der hat Probleme mit dem alten Spagetticode... dafür kombiniert er Klassen im Schlaf.

Manuela

[jacobi22]

gerade deshalb, weil ich die Version nicht steuern kann

Nicht persönlich nehmen, aber alles, was wir in den letzten 3 Tagen hier und im anderem Thread geschrieben haben, geht weit über das hinaus, was die meisten Forumsmitglieder hier von WB und dem drumherum wissen. Warum kannst du die Version nicht steuern? Weil sie nicht per Setting wählbar ist?
Ich habe mir z.b. ein "privates" Installationspaket geschnürt, liegt brav in einem Zip auf dem Rechner und frag nicht, wo noch. Da drin ist alles, was ich gern an Modulen oder "Zubehör" dabei haben möchte (vergleichbar mit WB-Portable, das ja auch eine andere Zusammenstellung hat). Dort ist keine JQ 1.7.1 oder 1.8.3 drin, auch kein FCKEditor, eben so angepasst, wie ich das für mich als Grundpaket für notwendig erachte. Ein JQ zu tauschen, mach ich so nur einmal und nicht bei jeder Installation neu.
Andere Sache: die Ressourcen an Core-Programmierern sind wirklich begrenzt und wenn ich die Wahl oder die Entscheidungsbefugn is über die Reihenfolge auf der ToDo-Liste hätte, wäre solch Option sicher auf einem der hintersten Plätze - nice to have, aber erst nach allem Anderen.
Cachen - kann ich nicht mitreden, mein Cache wird selten eine halbe Stunde alt, von daher für mich persönlich sinnlos.
Da ich eine eher unterirdische I-Net-Verbindung habe und selbst für eine simple Textmail deswegen selten weniger als drei Versuche in 10 min brauche, fällt ein JQ-Download auch für mich persönlich aus. Ich hab sicher an die 20 private WB's lokal laufen, vom Rezeptbuch meiner Frau bis hin zur privaten "Lexikothek" zu diesem oder jenem Thema, dazu alle möglichen WB-Versionen und Backups von Kunden und Usern. Was denkst du, was passiert, wenn ich da anfange down zu loaden?
Genau - nix  

Auf Anhieb fallen mir 100 Gründe gegen solch Vorschlag ein und nur einer dafür - nice to have halt. Es ist auch nicht so, das ich dir einen Vogel dafür zeige, um Gottes Willen. Es ist nichts irrsinniges und du begründest auch gut, aber viel von dem, was hier im Thread steht, kannst du auch problemlos selbst einrichten, anderes ist schon in der offiziellen Planung.
Ich denk, so ist der Sinn von WB, hier hast du ein Basispaket und wenn das nicht reicht, holt man sich hier oder da noch etwas dazu. Es steht uns frei, das mitgelieferte JQ zu nutzen, einen JQ-Link im Template oder gar in der frontend.functions. php zu setzen. Und wer es komplizierter mag, baut sich auch noch einen Schalter rein.
Klar hat jeder seine Wünsche, ich hätte auch gerne einen Ferrari, aber realistisch betrachtet ist er eben Mist. Ich hab eine Frau und 5 Kiddies im Haus. Wen nehm ich mit? Ich darf nach Norden, Süden und Westen nur 80kmH fahren, nach Osten sogar nur 70, jeweils bis zur nächsten Stadt in ca 20 km. Was soll ich mit nem Auto, das 300 fährt. Mein Hof ist nicht gepflastert, es ist Wiese (kein Rasen) - ich bekomm das Dingen nicht mal bis zur Garage ohne den Frontspoiler abzureißen. Und selbst wenn, da steht der Van drin. Der von meiner Frau muß schon draußen stehen, weil ich nur eine hab. Tausend gute Gründe, sich keinen Ferrari zuzulegen, aber trotzdem wär es schön  

Und Uwe, auch wenn auf OOP umgestellt wird... das ursprüngliche Ziel von WB bleibt mindestens solange erhalten, solang ich hier Code produziere.

Es geht nicht um OOP oder Core, Manu. Die Leute, die irgendwo ein Modul programmieren, mußten sowieso neu lernen, weil sie esin den allermeisten Fällen im Job brauchen. Ich denk, es gibt unter den Modulprogrammierern nur sehr wenig Leute, die z.b. hauptberuflich Bäcker sind.
Es geht um die, die einfach nur ihre kleine Webseite pflegen wollen, die mal das Andreas09-Template in vielen Stunden Arbeit und am Rande der Verzweifelung für sich "umgebaut" haben mit anderen Farben und Schriften. Für simples HTML gibt es an unseren Stunden noch Unterrichtsstunden in Informatik und im Web wird sicher jede Frage dazu schon 1000x beantwortet sein, aber such doch mal nach einem stink-normalem deutschsprachigem TWIG-Tutorial. Das, was du dir dazu aus der Hand schüttelst, lernen andere (mich eingeschlossen) in 10 Jahren nicht. Ich denk, WP ist ein gutes Beispiel, da findet sich auf 10.000 Nutzer vielleicht einer, der mal ein wirklich eigenes Template gebaut hat. Wenn dort die Masse an Addons nicht wäre, wär WP immernoch da, wo es mal war, ein kleines Blog-System. Ein gutes Template mit allen X-Tras zu bauen, ist eigentlich ein Profi-Job und genau da sehe ich eben das Risiko hier, weil die Masse, die es für solche Vielfalt braucht, garnicht vorhanden ist. Der schönste, modernste Core nützt nichts, wenn man am Ende nur 5 Templates und ein paar Module hat.

[Yetiie]

Vor (soweit mein Alzheimer mitspielt) ca. ein bis anderthalb Jahren hatte Google einen netten Systemausfall ...

@DarkViper: Jetzt enttäuschst Du mich aber. Das ist das übliche Argument, wobei die Anzahl der ausgefallenen Seiten sicher noch deutlich höher war und mit FB ein anderes Top-System z.B. dieses Jahr einen großen Ausfall hatte ... Das ändert jedoch nichts an der Sache, dass die Verfügbarkeit, Reaktionszeit und(!) Geschwindigkeit der Google-Server trotz der angesprochenen Systemausfälle höher ist als die Deines Servers bzw. des üblichen WB-Servers. Außerdem war die Menge der ausgefallenen Seiten gerade so hoch, weil die Google-Server eben diese hohe Verfügbarkeit besitzen und Fallbacks als nicht notwendig erachtet werden. Und Du verschweigst, dass Du Deinen eigenen Server durchaus als Fallback einbinden kannst ... automatisiert in einer WB-Funktion wäre das natürlich der WB-Service schlechthin

Was auf meinem Server liegt, wird ausgeliefert wenn meine Seite erreichbar ist.. unabhängig von fremden Infrastrukturen... und ohne Tracking.

Naja, kann man so sehen und hört sich erst mal gut an. Ich bin übrigens einer der heftigsten Google-Kritiker schlechthin ... Speziell im Fall SEO übersieht man bei so einer Einstellung dann aber leicht, dass auf den üblichen Seiten die Besucher durch Google kommen bzw. Google i.d.R. doch die wichtigste Rolle spielt. Ein kluger Kopf ist im Bereich SEO da gut beraten sich (auch wenn ich es gar nicht mag und das neue Analytics ist der größte M....) den Augen und Spielregeln von Google anzupassen. In diesem Bereich stolz darauf zu sein nicht getrackt zu werden ... ist da sicher der Ratschlag, der die Seitenbesucher minimiert statt zu einem hinführt  



WICHTIG bleibt dabei aber bitte:
Jeder so wie er mag. Und man sollte die Möglichkeiten für andere offen halten


---------

BTW:

Ich freue mich zu hören, dass WB einfach bleiben soll. Und bin gespannt.

Allerdings: "Ältere werden lernen müssen... " drückt hier doch einen besorgenden Widerspruch aus. Oben im Thread wurde ein gut Teil der Nutzer beschrieben inklusive ihrer Möglichkeiten und Wünsche. Die meisten davon - und nicht nur die Älteren - wollen eben einfach nicht lernen sondern nutzen WB weil sie das nicht müssen sondern Spagetti-Code schreiben wollen. Verbaut man diese Möglichkeit hat man vielleicht ein schönes System ... nur nicht in den Augen derer für die man es macht. Nein. Aktuell trifft WB leider immer weniger den Geschmack derer, die es verwenden sollen.

Ganz ehrlich: wenn ich lernen will gehe ich zu Joomla oder WP ... und bekomme Module und Templates in anderer Anzahl und(!) Qualität gleich mitgeliefert. Ich bin hier, weil ich genau Forderung des Lernens NICHT will und hier NICHT BENÖTIGE. Das hat WB anderen Systemen ja voraus. Ja. Ich mag WB und stehe dazu. Andere drehen WB schon jetzt ohne Klasserieties den Rücken weil das, was gemacht wird nicht mehr gefällt oder im Vergleich zu anderen Lösung zurück fällt. Und das sind oft ausgerechnet die, die Klasserities können. Klasserities scheint also nicht das zu sein, was WB voran bringt bzw. fehlt ...

Menno: nachdenken darüber, was anderen (= nicht mir sondern einer angenommen Zielgruppe) gefällt und andere Systeme evtl. voraus haben (oder auch wo sie zurück liegen) ist doch wirklich nicht soooooo schwer. Ein solches ehrliches(!) Nachdenken könnte ungeahnten Erfolg bringen was ja Spaß macht. Ja. Es ist die wiederholte Einladung zu einem neuen Weg, zu mehr Mut den eigenen Blickwinkel wandern zu lassen und zu einem wieder erfolgreichen System. Darüber würde ich mich freuen und glaube, dass es viel bewirken würde. Zukünftiges Lernen in der einen ODER DER ANDEREN Form ist dabei natürlich nicht ausgeschlossen ... lieber wäre mir die eine Form ...

[jacobi22]

Ich neige ja dazu, eine Beitragstrennung zu beantragen

Naja. Off-Topic ist das schon länger. Das stimmt.
Aber soweit ich verstanden habe war Deine Fragestellung heute früh schon gelöst, oder habe ich das falsch verstanden gehabt?

Geht weniger um Offtopic, eher um Übersichtlichkeit.
Solang solche Diskussionen um die Zukunft und die Möglichkeiten von WB darin, sauber geführt werden, betrachte ich es eigentlich als wichtig genug, um einen eigenen Thread zu füllen. Weder deine noch meine Meinung sind Quatsch, vielleicht wird ja auch aus der einen oder anderen Sache etwas draus. Und wenn nicht, wurde es wenigstens vernünftig erklärt.
Liest einer am Anfang, das der Uwe zu blöd ist, ein paar Hochkommas zu setzen, klappt er den Thread wieder zu und das Wichtige zu WB bleibt ungelesen.

In einem anderen Forum, wo ich aktiv bin, gibt es z.b. einen sogenannten Katalogisator. Dieser Bursche hat in einem Jahr gut 100000 Beiträge durchforstet, wo nötig, Themen getrennt, nebenbei auch etwas aufgeräumt und alles Wichtige in separaten Übersichten zusammengefaßt. Diese Übersichten sind Linklisten zum jeweiligem Beitrag.  Fragen zum Upgrade? Findest du alles auf dieser Seite, ein Link, zwei kurze Sätze, weiter zum nächsten - find ich eigentlich super, denn hier geht viel verloren, z.b. register_frontend_m odfiles_body();   

[Yetiie]

@jacobi22:

Ne, persönlich nehme ich das sicher nicht.
Ist es auch nicht. Aber gerne korrigiere ich Dich:


Eine Forderung wurde nicht gestellt:
Es wurde eine Anregung geben, von der ein Teil sogar schon auf der To-Do-Liste steht wie geschrieben wurde.
Eine Erwartung ist damit jedoch nicht verknüpft


Core-Agenda:
Du verfolgst die verschiedenen Thread hier im Forum.
Dann hast Du auch meine Anregung in anderen Threads gelesen, die Entwicklung am Core sogar zeitweise zugunsten anderer (in meinen Augen tatsächlich wichtigerer) Dinge zurück zu stellen. Also auch von daher keine Erwartungshaltung an Google ...


Bitte nicht überlesen:
Das Setting per register_frontend_m odfiles ist mir persönlich ehrlich gesagt immer noch schnuppe seitdem ich es weiter oben geschrieben habe. Gerade weil ich die Dinge selbst organisere. Anregungen müssen jedoch nicht immer etwas mit dem eigenen Gebrauch zu tun haben um einen Charme zu haben. Bleiben aber Anregungen.


... lass uns über Ideen reden und Gedanken austauschen.
Nicht jede Idee muss umgesetzt werden. Nicht jeder Gedanke mus geteilt werden.
Aber aus Überlegung kommt Neues. Und Neues ist Fortschritt.
Davon (damit ist nicht unbedingt die Google-Einbindung gemeint) könnte WB etwas mehr bebrauchen



Übrigens:
Die Einschätzung in Sachen Zielgruppe und Einfachheit sehen wir warscheinlich sehr ähnlich.
Genauso wie: 'Weder deine noch meine Meinung sind Quatsch, vielleicht wird ja auch aus der einen oder anderen Sache etwas draus.' Finde ich gut

[jacobi22]

Aktuell trifft WB leider immer weniger den Geschmack derer, die es verwenden sollen.

Seh ich eigentlich nicht so.
Es war mit Sicherheit ein Fehler, das man (auch ich) eine neue WB-Version mit groben Zeitraum der Fertigstellung angekündigt hat. Wird dieser grobe Plan dann nicht eingehalten, entsteht der Eindruck, es passiere ja nichts. Dann gab es Leute, die ihre Unzufriedenheit in welcher Form auch immer zum Ausdruck bringen mußten und auch welche, die diese Stimmung dann für sich genutzt haben, um eigene Projekte zu pushen (und sein es nur, wie kürzlich geschehen, durch Totreden und eine Systemumstellung aufschwatzen, das generiert eigene Aufträge, die man so nicht gehabt hätte).
Dann gibt es Leute, die schon länger auf diese WB 2.8.4 gesetzt haben. 90% meiner Projekte laufen z.b. mit der Rev 2101. Dafür wurden neue Module erstellt, andere umgebaut. Stefek hat z.b. auch 5 oder 6 Modulprojekte und wartet, das es weitergeht. Ein Rückbau kommt für ihn wie für mich nicht in Frage ebenso wie ein Versionen-Mix. Oder argos mit dem neuem Argos-Template. Auch er kann erst weitermachen, wenn all das, was geplant ist, im Core zur Verfügung steht. Was wir hier allesamt für WB machen, ist Freizeit und die möchte keiner gern unnütz verplempern.
Überall besteht aber auch das Risiko, das die Leute nicht ewig warten. Die meisten, die hier liefern, verdienen ihr Geld damit und wer erstmal das System gewechselt hat, wird nicht wiederkommen.
Andere Seite ist, das die WB 2.8.3 ab SP1 eigentlich ein sehr stabiles und auch gutes System ist und auch da geht man dann nicht unbedingt ran, wenn man es nicht muß.
Nicht zu vergessen, das es in der Natur der Sache liegt, das Leute nicht ewig das Hobby WB teilen. Hätte die Gesundheit mir keinen Strich durch die Rechnung gemacht, wäre ich z.b. garnicht hier. Ich mach das hier erst ein paar Jahre, aber mir ging es ähnlich wie Manu. Morgens vor dem Frühstück die ersten Postings beantwortet und nachts um 4 der letzte, der das Licht ausgemacht hat. Irgendwann muß man die Notbremse ziehen. Ich war sicher keine 16 Stunden in täglicher Vollzeit hier aktiv, aber im Hintergrund lief das Forum eigentlich immer und so mancher Termin mußte warten, weil der eine Beitrag noch fertig getippt werden mußte, schließlich wartet da jemand auf die Antwort. Bekommst du dann noch Haue, weil dies oder das nicht nach den Wünschen des Gegenübers lief, ist mal fix die Luft raus und dann war ich eben mal 6 Wochen weg. Andere kamen in der gleichen Situation nicht wieder. Und auch diese Gruppe kannst du wieder teilen in die Leute, die sich nur hier im Forum nicht mehr an WB beteiligen und andere, die komplett die Branche, die Frau bzw Mann, das Land oder das System gewechselt haben

Mit dem, was das CMS liefert, was im Core der 2.8.4 steht, hat der offensichtliche Personalschwund wenig zu tun, denk ich. Es ist die scheinbare Ruhe, die einen fragen läßt, ob es (noch) richtig ist, seine Energie hier in das Projekt zu stecken. Im Normalfall macht man nicht den gleichen Fehler mehrfach, von daher wird man sich von WB-Seite auch hüten, nochmal einen Zeitraum so bekannt zu geben wie es passiert ist. Ich z.b. war absolut davon überzeugt, das die von mir genannte 2.8.4er-Pläne auf eine Woche hin oder her passen werden. Ich kenne auch heute den Zeitplan, werd mich aber hüten, noch mal ins Fettnäpfchen zu treten. Meckern kann ich aber auch nicht, ich kann ja nicht mal Hochkommas setzen.... 

Eine Forderung wurde nicht gestellt:

Nein, hast du nicht. Sollte ich das irgendwo gesagt haben, würde ich es gern korrigieren. Es geht um Ideen, auch um Wünsche. Wenn ich verstehe, warum sich XY ein Gimmick ABC wünscht, macht es die Sache für mich leichter, ebenso, wenn mir jemand erklärt, warum mein Wunsch Mist sein könnte.
Es ist lange her, das man sich über solche Sachen mal ohne Störfeuer unterhalten konnte, vielleicht werden es darum auch immer ein paar mehr Worte 
Am Ende haben wir alle ein Interesse an einem guten WB. Was denkst du denn, was meine Frau sagt, wenn die Rezepte weg sind 

[dbs]

Moin, ich versuchte mir vorzustellen wie es wäre mit

Code: [Select]

register_frontend_modfiles('jquery','google','1.8.3');
Auf jeden Fall ist es sprechend und inzwischen für mich auch ansprechend.
Für den Fallback wäre natürlich Manu zuständig. *g*

[DarkViper]

Für den Fallback wäre natürlich Manu zuständig. *g*

Ah... neeeeeeee....   

Ich kämpf grad, dass ich Core und Anzeige konsequent getrennt bekomme. Da bau ich im Core garantiert nichts ein, das irgendwelche Anzeigeframeworks oder andere Dinge, die dann im Ausgabegerät (Browser) ablaufen zementiert.
Sowas lässt sich relativ einfach und flexibel Core-unabhängig mit Output-Filtern (z.B. SearchReplace-Filter -bisher Droplet genannt-) erledigen. 
Gut, Filter lassen sich derzeit leider noch nur etwas umständlich handhaben, aber das wird sich noch ändern.

Manuela

[Yetiie]

... ja, die Aufteilung des Threads ist sicher nicht verkehrt.
Ist ja inzwischen mehr eine Themenwanderung


....

Ein richtig spätes Posting, alle Achtung
@ jacobi22 : Du hast etwas ganz ganz wichtiges gesagt finde ich:

Was wir hier allesamt für WB machen, ist Freizeit ...

Das Engagement von allen Beteiligten kann man nicht hoch genug einschätzen finde ich. Das persönliche Engagement ist es, dass so ein Projekt trägt, am leben hällt und entwickellt. Das macht es aber auch so schwer darüber zu sprechen, wenn die Entwicklung dessen, was dort freiwilig reingesteckt wird, nicht so 'erfolgreich' läuft. Und Veränderungen lassen sich auch erst bewirken, wenn das aktive Team oder die aktiven Entscheider sich für eine sollche Veränderung begeistern lassen ...

Aktuell trifft WB leider immer weniger den Geschmack derer, die es verwenden sollen.

Einerseits schreibst Du dass Du das nicht so siehst. Aber später sprichst Du selbst auch die Signale an, die immer weniger zu übersehen sind: 'offensichtlicher Personalschwung', 'scheinbare Ruhe', ... das ist ein Prozess, der ja schon länger läuft. Ich würde es so formulieren: Es wenden sich zunehmend mehr Leute von WB ab als hinzukommen. Darunter die, die sich auf ihre Art mit Webseiten und Modulen für das System eingesetzt haben, also zunehmend die wichtigen Multiplikatoren. Die Gründe mögen sehr vrschieden sein, aber jeder tut es, weil das Gesamtsystem WB ihm nicht mehr gefällt. Die Gesamtentwicklung von WB ist deshalb problematisch, weil das Gesamtpakte eben den Geschmak immer weniger trifft ...

Das ist erst mal alles andere als gut.

Andererseits stimmt mich aber noch hoffnungsvoll, dass (auch wenn es nur wenige sind) einzelne immer wieder dazu kommen, WB also doch noch eine gewisse Anziehungkraft entfalten kann.

Und es stimmt mich hoffnungsvoll, dass sich diese Betrachtungsweise genau anders herum nutzen ließe, das Projekt wieder nach vorne zu bringen ... wenn man bereit wäre sich auf die Überlegung einzulassen, welche Punkte an einem CMS die Leute dazu bringen es zu benutzen (sei es nun die Fortgeschrittenen oder die Einfach-Anwender) und wie sich diese Punkte mit den noch zur Verfügung stehenden Ressourcen Step-Für-Step realisieren ließen.

....

Weißt Du, ich möchte das mal offen aussprechen: bei der ganzen Sache bereitet mir nicht mal so sehr die aktuell schwierige Situation Sorge. Ich glaube dass das Potential von WB noch(!) groß genug ist, um die Entwicklung mit den verfügbaren Engagisten umzudrehen. Was mir Sorge macht ist, dass genau das darüber Nachdenken was ein CMS attraktiver macht bzw. das Angehen dieser Dinge nicht (oder zumindest nicht in ausreichender Form) erfolgt.

Dabei ist es ja nicht mal so, dass die wichtigen Dinge für die Projektentwicklung eines CMS-Systems im allgemeinen und das Hintertreffen von WB im speziellen schwierig zu erkennen sind. Sie tauchen hier im Forum immer wieder in der einen oder anderen Form auf:

Design (nicht nur des Systems sondern des gesamten Umfelds)
Verfügbarkeit bzw. Sichtbarkeit von Modulen
Verfügbarkeit bzw. Sichtbakreit und Qualität Templates aktueller Machart
Speziell WB: Einfachheit und (jetzt mal übertrieben) mit Möglichkeit zu Spagetti-Code
Demos, wie ich aktuell designte und moderne Webseiten hinbekomme
...

Das ist jetzt extrem unstrukturiert und bei weitem nicht vollständig. Es fehlen z.B. die Überlegung dazu, welche Rahmenbedingungen geschaffen werden müssen, damit sich Leute in Ihren Vorstellungen einbringen und programmierend verwirklichen können (die eigentliche Triebfeder persönlichen Engagements) bzw. was ich ihnen anbeiten kann und will (nicht alles ist möglich). Aber es macht deutlich: letztendlich ist ist es das Gesamtpaket inklusive Zugänglichkeit zu den ergänzenden Dingen und die Präsentation was den Erfolg ausmacht und nicht nur die Entwicklung des Codes.

Will ich ein CMS bzw. WB entwickeln besteht zu einem Großteil der Aufgabe also nicht darin, wie und was für Code ich zur Verfügung stelle sondern darin, genau diese Rahmenbedingungen zu entwickeln und die Plattform dafür zu schaffen. Ist die Plattform attraktiv kommen Leute. Ist sie es nicht gehen sie oder bleiben sie fern. WB hätte das Potential dafür, dass Leute kommen.

Das Problem dabei ist, dass das ein Prozess ist, der nur von den aktiven und über das Projekt entscheidenden Personen angegangen bzw. angestoßen werden kann. Denn dort werden die Weichen gestellt, die am Ende dazu führen was sich entwickelt.

Und jetzt bitte als persönliche(!) Beobachtung die nicht unbedingt richtig sein muss weil nicht alles gesehen wird: allles (oder fast! alles) was ich an Projektentwicklung auf dieser Ebene sehe ist bezogen darauf, wann und wie die eine neue Version programmiert wird oder was an zusätzlichen dingen gerade noch selbst gemacht werden kann. Echte Gedanken  bzw. Signale dazu, wie die aber für das Projekt aktuell wichtigeren Dinge weil sie ins Hintertreffen gekommen sind entwickelt und gezielt angegangen werden können kann ich nicht oder nicht in bewirkend-ausreichender Form erkennen.

Das Problem dabei ist aber auch schon mehrfach diskutiert worden. Auch eine solche Arbeit (Projektentwicklung die mit Code-Programmierung nichts zu tun hat) braucht Zeit, die bei solchen Projekten aus dem persönlichen Engagement kommt. Da dies begrenzt ist und neue Leute für ein Projekt in der vorliegenden Form nur schwer zu gewinnen sind geht nicht beides. Stecke ich den Kopf in den Code (was ein beachtenswertes Engagement ist, was ich betonen möchte) passiert auf der anderen Seite ... nichts oder nur wenig und wenn dann unkoordiniert. Die Entwicklung nach unten geht weiter.

Ich werbe daher (und weil ich WB mag tue ich dies wiederholt) dafür, sich doch mal auf diese andere Denkweise und Management-Aufgabe jenseits der Programmierung einzulassen. Das ist nicht leicht gerade weil man umdenken muss und das fällt besonders schwer, wenn man unter Beschuss steht. Aber es ist auch kein Hexenwerk. Und ich bin überzeugt, dass dies durch den Erfolg, der mit dem einfach mal das andere tun einstellt, auch der Spaß kommt.

Oder mal praktisch beschrieben:

Wenn(!) ich zu dem Schluss komme (kann ja auch sein, dass es ganz anders bewertet wird), dass das Design einen nicht mehr modernen Touch vermittelt und andere Wettbewerber dort moderner wahrgenommen werden ...
.... kann ich erst mal darüber nachdenken wie ich an ein modernes Design der Webseite und des Backends und an wenigstens zwei oder drei moderne Templates komme,
... kann ich überlegen wen und wie ich jemanden dafür begeistern kann,
... kann ich überlegen wo ich Vorlagen herbekomme,
... oder ich kann weiter an der nächsten Version arbeiten.

Wenn(!) ich zu dem Schluss komme (kann ja auch sein, dass es ganz anders bewertet wird), dass die Handlungen des AMASP-Betreiber dem Projekt WB schaden ...
... kann ich erst mal darüber nachdenken, was ich dem entgegenstelle,
... wie ich Leute, dazu bewegen kann, eine Alternative zu erstellen,
... nachdenken welche Rahmenbedingungen ich diesen Freiwilligen anbieten kann,
... oder (was genauso in Ordnung ist !!!) wenn ich das nicht will was nicht zu kritisieren ist darüber nachdenken, warum das eigene Modul-Reporatory nur mäßig angenommen wird,
... und wie ich dass mit wem ggf. als Alternative entwickeln und promoten kann,
... oder ich kann weiter an der nächsten Version arbeiten.

Wenn(!) ich zu dem Schluss komme (kann ja auch sein, dass es ganz anders bewertet wird), dass moderne Trends des Webdesigns entstehen und mein CMS-System diesen Kontext nicht nutzt oder dieser Trend an meinem System vorüber zieht ...
... kann ich überlegen ob sich kleine Dinge in WB so gestalten ließen, dass sich Aussagen formulieren, die WB in den Zusammenhang mit diesen Trends bringen ließe und sich damit sie weitererzählt werden können,
... oder ich kann weiter an der nächsten Version arbeiten.

Wenn(!) ich zu dem Schluss komme (kann ja auch sein, dass es ganz anders bewertet wird), dass mehr Leute gehen als kommen und auch wichtige aktuelle Supporter durchaus immer wieder die gleichen Punkte ansprechen ...
... kann ich überlegen, was ich aus den Rückmeldungen als Anregung mitnehmen kann
... oder ich kann weiter an der nächsten Version arbeiten.


Was wohl etwas (hoffentlich nicht zu) bissig und überspitzt formuliert ist (wobei ich hoffe, dass auch deutlich geworden ist, dass die beschriebenen Schlussfolgerungen nicht! geteilt werden müssen!) macht jedoch deutlich:

Das Andere Tun kostet Zeit.
Beides Tun geht nicht.
Es ist das Andere tun, dass das Projekt entwickelt.

... und Sorge bereitet mir, dass das Andere Tun aktuell und seit geraumer Zeit nicht getan wird. Aber genu dieses Andere Tun ist das, was die Chancen in isch trägt.

Also mein Werben dafür: innehalten, mal anders denken, Blick auf das Umfeld schweifen lassen und die Dinge angehen, die viel zu lange liegen geblieben sind. und so lange andere Leute nicht in ausreichender Zahl kommen ... naja, bleibt die Frage nach dem Einen oder dem Anderen. Das schöne daran ist aber auch: Durch das Andere kommen Leute, ... und kann man zu dem Einen das einem so viel Spaß macht wieder zurück kehren.

Wichtig ist mir: Ich werbe weil ich WB mag. Und ich werbe in dem Bewusstsein, dass es die eigene persönliche Freizeit der Personen ist, die sich hier engagieren. Es kann mit solchem Werben daher keine Forderung verbunden sein und die Form, wie sich die Leute einbrignen möchten ist zu akzeptieren. Das ist so und auch richtig so. Mit allen Konsequenzen. Das schließt steigende oder fallende Nutzerzahlen ein. Oder auch die eigene Überlegung eines jeden selbst, ob das System noch den eigenen Geschmack trifft oder nicht. Ein sich entwickelndes Projekt WB würde mir gefallen

[fischstäbchenbrenner]

Das ist eine etwas akademische Diskussion hier..

Ein bissel Senf von mir:

Es ist tatsächlich schneller, wenn man Standard-Codes von Google lädt.
Ein ganz wesentlicher Grund wurde oben gar nicht genannt:

Wenn ein Besucher das erste Mal meine Seite aufruft, muss der Server in möglichst kurzer Zeit alles ausliefern. Es ist natürlich eine Entlastung, wenn da ein paar jQuery-Dateien nicht dabei sind.
Wer Angst hat, dass Google oder ein anderes CDN ausfällt:

Code: [Select]

<script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-1.11.0.min.js"></script>
<script>
window.jQuery || document.write('<script src="/eigenes/jquery-1.11.0.min.js"><\/script>');
</script>
Zusammenhängen von Dateien:
Auch das im Prinzip richtig. Allerdings muss man da im Auge behalten, dass ich ja nicht auf jeder Seite ALLES habe. DIe template.css wird wohl immer dabei sein, aber das JS/CSS der Foldergallery hat man selten gleich auf der Startseite.

Würde jetzt alles zusammengefügt werden, hätte ich auf jeder Seite eine andere Kombination und folglich jedesmal eine neue Datei. Und: Die muss jedesmal neu ausgeliefert werden, weil ja WB und Browser nicht notieren, welche schon mal waren.
Es würde also die erste Seite vielleicht schneller geladen werden, aber jede weitere langsamer.

Wenn ich das ganze in Relation setze zu diversen anderen Maßnahmen, die man setzen könnte.... jo mei..

Ich bin in der letzten Zeit dazu übergegangen, die template.css und die mobile.css gleich zusammenzufügen.
Zwar scheint es zunächst sinnvoll, die mobile.css nur dann zu laden, wenn sie auch tatsächlich benötigt wird.
Aber: Smartphones haben oft schlechte verbindung, und es kann vorkommen, dass die dann wichtige mobile.css verspätet oder gar nicht geladen wird. Ergo sehe ich die Desktop-Version am Handy, oder zumindest zappeln.

Eine Frage in diesem Zusammenhang:
Wenn ich am Handy den Zurückschalter verwende, müsste ich eigentlich sofort die vorige Seite haben; ist ja schon im Cache.
In der Praxis sehe ich aber deutlich den Ladebalken hochkrabbeln; die Seite wird neu geladen. Warum eigentlich?

[DarkViper]

Fang mer mal von hinten an:
Mobilgeräte und Caching.. Ich vermute, dass dieses Problem stark hardwareabhängig ist. Bei einem herkömmlichen Desktop-PC wird der Cache ja problemlos auf der Festplatte abgelegt. Mobilgeräte haben in der Regel keine herkömmliche, mechanische Festplatte sondern setzen auf SSD-Speicher etc., die zwar recht schnell sind, jedoch auch ihre Nachteile haben. Der gravierendste dürften die limitierte Anzahl an möglichen Schreibzyklen sein, nach der sich die einzelnen Zellen zu verabschieden beginnen. Der Arbeitsspeicher ist in diesen Geräten in der Regel zu kostbar, um ihn für Caching zu verwenden. Meine ?Vermutung? ist daher, dass die Software Caching verhindert/abschaltet um die Hardware zu schonen.

Zusammenhängen von JS/CSS Dateien kann, wie Chio schon sagte, ein zweischneidiges Schwert sein. Meine eigenen Gedanken dazu drehen sich da anfangs hauptsächlich um Inline-JS je Seite. Eine seitenbezogene, dynamisch erzeugte JS-Datei die allen Inline Code sammelt..  und vor allem auch die Variablenübergabe von PHP an JS zentral abhandelt.
Ein wirklich optimiertes Zusammenhängen von Dateien ist eine recht aufwändige Angelegenheit. I.d.Regel geht das von Hand schneller. Andererseits dürfte die minimale Zeitersparnis durch 1-2 optimierte Hintergrundbilder etc. um ein Vielfaches in den Schatten gestellt werden...

Mir geht eh immer die Hutschnur hoch, wenn einzelne Websites versuchen, mein Monatskontigent an 'HighSpeed-Traffik' mit Riesenbildern und aufgeblasenen Flashobjekten für nix und wieder nix in den ersten 5 Tagen des Monats zu verbraten. Einen Sponsor für einen besseren (und wesentlich teureren) Tarif hab ich leider noch nicht gefunden.  

Das JS-Fallback dürfte mit dem Tip von Chio auch für einige Zeit Platz in der Warteschleife haben.

Manuela

[Yetiie]

Das ist eine etwas akademische Diskussion hier..

Naja, das Thema Ladezeitenoptimieru ng ist wohl für die meisten WB-Seiten nicht relevant ... aber die Diskussion ist alles andere als akademisch sodern ist ganz real Umsatzgetrieben wie das Beispiel Amazon zeigt. Leider habe ich die Seite mit den sehr konkreten Testergebnissen der Amazon-Versuche nicht mehr gefunden, aber folgende Seite, die etwas andere Zahlen hat ist dafür sehr interessant und eindrucksvoll und da wird die Disziplin richtig lebensecht:

http://www.onpagedoc.com/blog/ladezeiten-testen-optimieren-100-millisekunden/

Da geht es dann nicht mehr um das Zusammenfassen, Cachen und Minifizieren von Dateien sondern teileise bis in die Laufzeitanalyse einzelner PHP-Funktionen und auch JS-Framework- bzw. JS-Modul-Lösungen. Naja, 0.2 Sekunden schnellerer Seitenaufbau bringen richtig Geld. Von dem so zusätzlich erwirtschafteten Verdienst eines Monats könnten wahrscheinlich viele hier das ganze Jahr oder länger leben

Ob man in seinem Webprojekt von dem Hardware-Rand einer solchen verwendeten Technik profitieren möchte oder es bei dem Projekt nicht erforderlich ist bleibt ja Einzelfallsache. Aber spätestens wenn man mit WB einen sagen wir etwas ambitionierteren Shop aufbauen möchte (wobei WB dafür dann wahrscheinlich doch das falsche System wäre) lohnen sich Gedanken in dieser Richtung schon.

Zusammenhängen von Dateien:
Auch das im Prinzip richtig. Allerdings muss man da im Auge behalten, dass ich ja nicht auf jeder Seite ALLES habe.

Ja, das ist es, was eine WB-Automatik wahrscheinlich etwas komplizierter macht. Günstig wäre daher die CSS- bzw. in separater Datei die JS-Dateien projektweit(!!!) zusammenzufassen (also nicht nach Einzelseiten zu unterscheiden) und immer komplett 'alles' zu laden. Nur dann funktionert der seiteninterne Caching-Effekt.

Dabei hat ein ein oder zweimal gebrauchter Bildwechsler nicht mehr KB als ein kleines Bild wenn überhaupt ... und über den Request hätte er beim Einzelabruf eine längere zusätzliche Ladezeit als die größere Datenmenge beim gemeinsam Laden zusätzlich erzeugt. Das projektweite Zusammenfassen ist übrigens bei vielen großen modernen Webseiten durchaus aktuelle Technik. Die großen Frameworks dann noch separat von Google holen ... und schon hätte man eine kleine WB-Ladezeiten-Optimierung fertig.

Für eine WB-Optimierung würde das dann wahrscheinlich bedeuten, dass die Mod-CSS- und Mod-JS ALLER INSTALLIERTEN Module (bis auf die Frameworks) in (zwei!) Dateien gepackt werden müssten ... ein Kennzeichnungssyste m: 'diese Moduldateien separat laden' würde das wahrscheinlich schon wieder verkomplizieren.

Eine mögliche automatisierte Datei-Minifizierung wie bei SASS würde ich da übrigens rauslassen ... da das in Einzelfällen Probleme mit sich bringen soll soweit ich (allerdings nicht wirklich genau bzw. sicher) weiß. Aber die Dateien können in den Modulen ja schon minifiziert hinterlegt werden.

[fischstäbchenbrenner]

Natürlich ist geringe Ladezeit wichtig, wobei man da aber nicht gerade Facebook oder Amazon als Messlatte verwenden sollte. Das ist schon etwas unproportional..
Für den typischen Websitebetreiber spielt es keine Rolle, solange die Ladezeit nicht nervt.

Oft sind es die Latenz-Zeiten beim Provider, die wirklich auftragen. Schnellerer Server = mehr Kosten = naja, eh nicht so wichtig...
Eine "Lösung für alle" wird unterm Strich kaum Einsparungspotentia l bringen, weil es wiederum die Latenzzeit etwas erhöht.

Und jemand der sich wirklich damit befasst, findet auf jeder Website genug individuelles Optimierungspotenti al.
Ich hab zb WebsiteBaker.at auf responsiv gemacht - für gerade mal 5% der Besucher. Nachteil für ALLE: keine Größenangaben bei Bildern, dh langsamerer Aufbau, weil erst die Bilder geladen werden müssen. Sicher keine Beschleunigung. Na und? Ist halt zeitgemäß, sagt man so.

Einsparungstipps:
Kopiere alle CSS der Module, die häufig geladen werden in deine template.css und benenne die frontend.css der Module um. Das selbe mit den frontend.js. Dauert: 3 Minuten.

[Luisehahne]

Hallo Leute,

ich habe zwar nicht alles gelesen, ist ein bisschen viel  , aber ein Beitrag ist mir aufgefallen.

Moin, ich versuchte mir vorzustellen wie es wäre mit

Code: [Select]

register_frontend_modfiles('jquery','google','1.8.3');
Auf jeden Fall ist es sprechend und inzwischen für mich auch ansprechend.
Für den Fallback wäre natürlich Manu zuständig. *g*

So ähnlich habe ich das bei mir gelöst, allerdings ohne Versionsnummer:

Code: [Select]

<?php
  register_frontend_modfiles('jquery','south-street','CDN');

oder

Code: [Select]

<?php
  register_frontend_modfiles_body('jquery','south-street','CDN');

Der Parameter"south-street" bindet das entsprechende Theme (ui.min.css) ein

eingelesen werden die Parameter in der function bind_query (framework/frontend.functions.php)  indem ich die Funktionsargumente abfrage, und entsprechend einen Schalter setze.

Eine andere Möglichkeit wäre die Versionsnummer, Urls, usw.  über eine jqeury.ini, die im Templateverzeichnis liegt,  festzulegen

Der Designer hätte dann die volle Kontrolle welche Version, welches Theme und von wo sollen die Scripte geladen werden. Würde auch die Übergabe von Argumenten überflüssig machen.

Sollte dss sinnvoll sein, werde ich mich für eine Umsetzung in der kommenden 2.8.4 einsetzen.

Wäre gut, wenn alle Module auf Inline Scripte verzichten würden.  Somit könnten Jquery und ModuleScripte vor Body Ende mit register_frontend_m odfiles_body() eingebunden werden, was sich wahrscheinlich auf die Ladezeit auswirkt.

Dietmar

[fischstäbchenbrenner]

Naja, die VOLLE Kontrolle habe ich, wenn ich das alles selber mache.
Zumindest muss ich dazu keine Dokumentation lesen und wenn mal was nicht funktioniert, kann ich es sofort selbst reparieren, ohne im Core herumfrickeln zu müssen.

Abseits der Diskussion um technische Machbarkeiten sollte man den praktischen Nutzen nicht aus den Augen verlieren.

[DarkViper]

Chio, da stimm ich Dir sogar zu 100% zu..
Ich möchte keine halbgaren Krücken zur Verwaltung einer undefinierten, sich laufend ändernden Menge an Frameworks etc. im Core integrieren...  die letztlich doch wieder durch manuelle Eingriffe korrigiert und angepasst werden müssen.
(und ob ich einem Dau jetzt die X Parameter irgendwelcher Funktionen etc. erklären muss, oder das Include einer JQ-Datei... schenkt sich nichts)

Core ist Core und Präsentationsschich t ist Präsentationsschich t.
Für ersteres bin ich zuständig und für letzteres zu 100% der Designer.
Ich stelle einen vollständigen Satz Daten zur Verfügung, sorge noch für Variablenübergabe von PHP -> natives JS fertig... und der Designer kann absolut frei entscheiden, was er zum Aufbau der Anzeige damit anstellt. Er entscheidet auch, ob und welches Framework etc. er wo und wie einsetzt. Das geht mich auf Core-Seite rein gar nichts an.

Manuela