WebsiteBaker Community Forum
WebsiteBaker Support (2.8.x) => 
Hilfe & Support (deutsch) => General Help & Support => Diskussion über WB (closed) => Topic started by: Yetiie on November 17, 2014, 03:17:30 PM
-
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 (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.
-
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
-
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 ...
-
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)
-
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
-
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 ...
-
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 :wink:
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 :-)
-
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 :wink:
Ein CMS lebt von der Vielseitigkeit im Einsatz, von der Anzahl der Module und Templates, aber nicht von einem Schalter im Backend
-
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 ... ;-)
-
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... :-o :-o :-o
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
-
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 :-D
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 :-D
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.
-
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 ... ;-)
-
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(); :wink:
-
@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 :-)
-
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.... :cry:
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 :wink:
Am Ende haben wir alle ein Interesse an einem guten WB. Was denkst du denn, was meine Frau sagt, wenn die Rezepte weg sind :-D
-
Moin, ich versuchte mir vorzustellen wie es wäre mit
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*
-
Für den Fallback wäre natürlich Manu zuständig. *g*
Ah... neeeeeeee.... :-o :roll:
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
-
... 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 :-)
-
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:
<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?
-
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. :cry:
Das JS-Fallback dürfte mit dem Tip von Chio auch für einige Zeit Platz in der Warteschleife haben. ;-)
Manuela
-
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/ (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.
-
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.
-
Hallo Leute,
ich habe zwar nicht alles gelesen, ist ein bisschen viel :-D, aber ein Beitrag ist mir aufgefallen.
Moin, ich versuchte mir vorzustellen wie es wäre mit
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:
<?php
register_frontend_modfiles('jquery','south-street','CDN');
oder
<?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
-
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.
-
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
-
die Sache mit der Jquery.ini (Post von Dietmar) interessiert mich persönlich schon, da sehe ich auch den meisten Nutzen drin, allerdings eben nicht mehr für den "normalen" User. Und da bin ich wieder bei meinem Problem von gestern: bauen sich 10 - 20 Leute ein CMS, das sie für sich als ideale Vorlage betrachten oder bin ich noch bei der Idee von Ryan?
Hello-World und das Template-Handbuch haben den Leuten die Möglichkeit gegeben, durch Kopieren von Codeschnipseln etwas eigenes zu bauen. Ist das nicht mehr gegeben, weil z.b. das Template-handbuch 20 Bände haben müßte, dann kann ich auch zu WP gehen, da gibt zig tausende Addons schon fertig.
-
Und da bin ich wieder bei meinem Problem von gestern: bauen sich 10 - 20 Leute ein CMS, das sie für sich als ideale Vorlage betrachten oder bin ich noch bei der Idee von Ryan?
Hello-World und das Template-Handbuch haben den Leuten die Möglichkeit gegeben, durch Kopieren von Codeschnipseln etwas eigenes zu bauen. Ist das nicht mehr gegeben, weil z.b. das Template-handbuch 20 Bände haben müsste, dann kann ich auch zu WP gehen, da gibt zig tausende Addons schon fertig.
Uwe, ich glaub da kann ich Dich beruhigen. :-)
Ich hab mich damals bei meinem Einstieg zu Ryans Idee bekannt und daran wird sich auch in Zukunft nichts ändern.
Allerdings soll das nicht bedeuten, dass jetzt schon 10 Jahre alter Code mit 100.000 Flickstellen auch in Zukunft bestehen bleiben kann. Das ist auf Dauer schlicht nicht möglich, da sich einfach die ganzen Grundlagen (Hardware, Betriebssysteme, Datenbanken und PHP-Interpreter ) in großen Schritten weiterentwickelt haben. Ein aktuelles Beispiel ist die derzeit aktuelle, fast schon zwangsweise Umstellung des Datenbanktreibers von mysql auf mysqli mit all ihren Problemen.
Was jedoch bleiben wird ist erst einmal das ganze Grundkonzept, modernisiert aber immer noch so, dass ein User von 2.7 sich auch in 2.12 noch -fast- auf Anhieb zurecht findet.
Die Möglichkeiten, selbst einfach und leicht verständlich Veränderungen vorzunehmen, wird es auch in Zukunft geben.. wenn auch evt. mit etwas anderen Techniken.
Auf gar keinen Fall soll aus WB ein müder Abklatsch von Typo3 und sonstigen Systemen werden. WB hat seinen eigenen Charakter und den soll es behalten. Auch wenn es eine Grundsanierung hinter sich hat. Was aber auch des öfteren nicht 'nice to have' sondern 'must not be' heißen wird.
Ach ja... 'Hello World' ... das wird es auch für die 2.8.4 wieder geben. Während das alte eingemottet wird, entsteht gerade ein völlig neues, top aktuelles im Wiki. ;-) So richtig nett mit direkter Downloadmöglichkeit der einzelnen Musterdateien, Codeschnipsel etc. pp.
Ein 'Muster-Template-Projekt ? Auch das ist vorgesehen. Das Grundgerüst von mir... alles andere 'darf' die Community im Wiki verewigen.
Aber bitte..... ich hab nur 2 Hände und ein Hirn (auch wenn Frauen mehreres gleichzeitig machen können :-P)
Manuela
-
Eigentlich nur als Hinweis gedacht:
Im Nachgang und Zusammenhang zu der hiesigen Diskussion und den verschiedenen Practise-Überlegungen ist mir heute früh noch folgendes aufgefallen:
Die von WB vorgesehene und empfohlene Technik mit einer 'template.css' zu arbeiten ist für die moderne Webseitenerstellung inzwischen auch schon (fast) überholt ... jedenfalls wenn man das hinsichtlich der Ladezeitenoptimieru ng betrachtet.
Nicht gemeint ist, dass man das nicht so machen darf es nicht funktionieren täte. Und natürlich wird das jeder so machen und organisieren wie er möchte und gerade die Datei-Organistation hinsichtlich CSS/JS unterliegt ja extremen Unterschieden. Der Hinweis soll lediglich sein:
Eine zentrale CSS-Datei in der alle weiteren CSS-Dateien (oder auch nur einige) per '@import' inkludiert werden ist bezüglich der Download-Geschwindigkeiten das langsamste was man machen kann. Zumindest habe ich, als ich mit WB angefangen habe, die Empfehlung so verstanden ...
Dabei gehe ich davon aus, dass moderne Seiten bzw. schon mittlere Projekte eigentlich schon alleine aufgrund der Übersichtlichkeit in der Regel nicht mit einer CSS-Datei auskommen.
Oder die Arbeitsweise/das Projekt ist schon so modern, dass SASS oder LESS eingesetzt werden und alles automatisch in eine template.css gepackt wird. Wobei ich aber vermute, dass der Durchschnitts-Designer hier damit wohl nicht arbeiten dürfte.
BTW:
Mich würde mal interessieren ob es hier (vor allem unter den hauptberuflichen Designern) schon jemanden (einige) gibt, die mit SASS/LESS arbeiten und ggf. welche Erfahrungen gemacht wurden?
-
BTW:
Mich würde mal interessieren ob es hier (vor allem unter den hauptberuflichen Designern) schon jemanden (einige) gibt, die mit SASS/LESS arbeiten und ggf. welche Erfahrungen gemacht wurden?
Ich verwende in der Regel eine editor.css, in der alle Schriften, Tags und Farben definiert sind. Und eine template.css, in der am Ende auch das mobile-Zeugs und die Abweichungen zu den Modul-frontend.css stehen. (letztere rühre ich nie an)
Meistens nehme ich als Basis ein vorhandenes Design, das ich dann ändere.
Mit LESS/SASS habe ich mich noch nie wirklich befasst, weil ich mir davon keine Verbesserung erwarte. Die versprochene Produktivitätssteig erung glaube ich nicht so ganz: Das Basis-CSS mache ich ohnehin nie von Grund auf, und das Finetuning wird mir SASS nicht abnehmen. Im Gegenteil: Ich müsste mich mit dessen Strukturen und Overhead befassen, meine persönliche Arbeitsweise anpassen. Genau das will ich aber nicht: Ich bin selbständig, weil ich so arbeite wie ich will. Nicht wie ich muss.
Etwas anderes wird es bei angestellten Webdesignern sein. Die müssen schnell in eine vorhandene Struktur gepresst werden und da haben Frameworks mit allem dran sicher ihre Vorteile.
-
Die von WB vorgesehene und empfohlene Technik mit einer 'template.css' zu arbeiten ist für die moderne Webseitenerstellung inzwischen auch schon (fast) überholt ... jedenfalls wenn man das hinsichtlich der Ladezeitenoptimieru ng betrachtet.
hatte das Abo für diesen Thread schon gelöscht, aber hier will ich doch mal nachfragen: wo kommt denn diese Empfehlung her? Hab ich noch nie von gehört und ich bin mir auch sicher, das es solche Empfehlung nicht gibt.
-
Uwe, das war nur der typische, aus der WB-History wohlbekannte, Ablauf:
Irgendjemand schreibt vor langer Zeit in seinem Template eine template.css.
Im üblichen Copy-Paste-Verfahren wird dies von 20 Leuten übernommen... und plötzlich hält es jeder für gegebenen Standard. ;-)
Sicher, es ist für herkömmliches HTML/CSS Design die einfachste und auch sinnvollste Lösung, eine CSS-Datei im Template mit zu liefern. Die Benennung und auch die Struktur jedoch ist jedem freigestellt. (ich nutze z.B. oft screen.css, print.css, etc.)
Manuela
-
wo kommt denn diese Empfehlung her?
Du, alles im Grünen Bereich ;-)
Das ist so eines von den ganz vielen Dingen, die so ganz normal unterschiedlich verstanden werden, wenn sich unterschiedliche Leute in ein Thema einarbeiten und Texte lesen ... ist Jahre her und hatte sich als von WB empfohlene Vorgehensweise so in meinem Kopf festgesetzt ... woher ist nicht mehr nachvollziehbar ... wahrscheinlich Benutzerhandbuch oder irgendwas im Forum. Übrigens waren die @importe damals durchaus aktuelle Technik über die CSS strukturiert und auch modularisiert wurde ... also damals wirklich nichts Verwerfliches sondern sogar Stand der Technik ... ;-)
Übrigens bedeutet das nicht, dass das so gemacht werden musst oder gemacht wurde. Denn:
Ich bin selbständig, weil ich so arbeite wie ich will. Nicht wie ich muss.
... gilt sicher auch in diesem Zusammenhang und ganz besonders im Zusammenahng mit der Template-Erstellung und unterschreibe ich zu 500 000 000 000 %. ;-)
Wobei ich zu SASS sagen muss, dass ich da auch erst skeptisch war ähnlich wie hier beschrieben.
Mich hat die eigene(!) Erfahrung da aber begeistert da werden von lassen.
-
ja, wie das zu Stande kam, kann ich mir schon denken, aber wenn ich den Satz mal zerlege:
Die von WB vorgesehene und empfohlene Technik
das würde bedeuten, das WB nach einer Datei mit diesem Namen sucht und da würde es schon einleuchten, das das eventuell etwas länger dauert. Es gibt keine solche Funktion innerhalb von WB, von daher spielt der Name der verwendeten CSS-Datei im Template keine Rolle, sofern dabei die Vorgaben für Dateinamen eingehalten werden.
P.S.: ein Eintrag im Benutzerhandbuch wäre eine solche "offizielle" Vorgehensweise. Glaub mir, da stand es definitiv nie drin.
Es ist schon so, wie Manu das sagte, in den 100 Templates im Archiv gibt es in fast jedem eine Datei template.css, da muß es ja eine Vorgabe geben :wink:
Bei mir heißen die CSS-Dateien grundsätzlich so, wie das Template. Zusätzlich gibt es eine print.css für die reine Printausgabe und die editor.css.
Auf @import verzichte ich komplett. Sollte es mal umfangreicher sein, werden diese CSS-Dateien direkt ins Template eingebunden
Noch ein Nachtrag: du sollst das nicht immer persönlich nehmen. Es geht nicht darum, das DU das gesagt hast, sondern darum, das offensichtlich viele Leute glauben, es gäbe diese Vorgabe.
-
Danke für die Rückmeldung.
Noch ein Nachtrag: du sollst das nicht immer persönlich nehmen.
Ne, keine Rede davon. Sorry, wenn es so wirkt. Vielleicht liegt es speziell heute auch an dem heutigen Frust ... speziell zu WB.
Ist so was wie mein persönlicher WB-Trauer-Tag. (Ernsthaft: ich zunehmend darüber nach, ob WB wirklich eine Zukunft hat, ... auch wenn sich das blöd anhört. Und als wirklich echter Fan knickt mich das schon ... vor allem was ich da so lese und wie das Projekt insgesamt so läuft ... ist ja nicht zu übersehen und kann man irgendwann auch nicht mehr schön reden ... gerade bei dem Potential was da eigentlich drinn steckt ... naja, letztendlich kann man nur akzeptieren, es so nehmen wie es ist und irgendwann reagieren ... und vielleicht ist es auch der Anfang eines von den vielen langen Abschieden hier. Ich stelle immer mehr fest: Die Musik spielt woanders, und Interesse am Konzert teilzunehmen scheint hier wohl nicht vorhanden zu sein ... :-( :-( :-( :-( :-(
-
Eins vorab: jeder, der WB einsetzt, egal, ob privat oder im Geschäft, muß für sich entscheiden, ob er der Sache vertraut oder nicht.
Was mich hier verwundert, ist der Zeitpunkt.
Über das Jahr wurde ziemlich viel zum Thema geschrieben. Wirklich relevant ist das, was DarkViper (Manuela) oder Luisehahne (Dietmar) schreiben, alles andere (wie auch meine Texte) sind persönliche Meinungen, die man teilen oder nicht teilen kann.
Nachdem wir Tester die WB 2.8.4 ver... haben, weil kleine, aber ganz wichtige Sachen nicht bemerkt wurden mit der Folge, das die Version zurückgezogen werden mußte, begann hier ein öffentlicher Spießrutenlauf für die Entwicklung. Das Manu am Ende nicht hingeworfen hat, sollte man eigentlich hoch anrechnen, ich hätte es sicher getan. Viele Modulentwickler waren schon gefrustet, weil andere User von ihrer Idee XY nicht begeistert waren. Eine Menge Leute hat es z.b. garnicht gepasst, das die Hauptentwicklerin mal nicht 16 Stunden täglich an WB arbeitet und das der Einzige, der noch Vereinsarbeit geleistet hatte und hat, gerade dem Tod von der Schippe gesprungen ist, hat auch nicht interessiert.
Seit Veröffentlichung des SP3 geht es eigentlich wieder vorwärts, das Problem ist halt, das es viele nicht interessiert, wie z.b. der Grundinhalt in ein Wiki kommt, wie das ganze Online-Projekt umgebaut wird, wie eine 2.8.4 entsteht, alle warten nur auf Lieferung. In den letzten Wochen gab es zahlreiche Postings der beiden oben Genannten, aus denen erlesbar oder sichtbar ist, das es voran geht, z.b. wenn man im erwähntem Wiki mal etwas stöbert oder die aktuelle 2.8.4-Rev testen kann.
Insofern wundere ich mich über den Zeitpunkt deines Trauertages und ich vermute da eher andere Ursachen, denn Zeichen, das es weitergeht, gab es doch zahlreich und das auch und vorallem im öffentlichem Bereich.
Ist es vielleicht etwas Frust, das dein vorgestelltes Modul nicht die erhoffte Begeisterung hunderter User gebracht hat oder das der Normal-User nicht die Welt rumdrehen möchte, um eine Millisekunde Ladezeit zu sparen? Beide Sachen bringen aus meiner Sicht nicht viele Vorteile auf den für WB üblichen 20 - 30 Seiten Projekten, auf der Max Mustermann seinen Tischlerei-Betrieb vorstellt oder Dank Bakery einen CD- oder Tshirt-Shop hat. Schaue ich in meinen WB-Nutzerkreis, sowohl geschäftlich wie auch privat, dann gibt es da lediglich drei Projekte, bei denen neben dem Eigner noch 2-4 Redakteure eingesetzt werden. Diese haben jeweils nur die Aufgabe, bestimmte Texte in verschiedene Eingabemasken einzutragen. Alle anderen Projekte gehen in die Richtung "ich stelle mich oder mein Unternehmen vor", fünf Seiten plus Kontakt + Impressum, ggf noch Bildergallerien, aber eben nichts, was den Einsatz des vorgestellten Moduls erfordert.
Ich teste gern das Technische oder das Drum und Dran, aber 100 Jammerpostings von mir, das ich das Modul nicht benötige, sind doch kaum hilfreich, denn für andere kann das schon wieder ein Schritt sein.
Am Ende mußt du für dich entscheiden, was der richtige Weg ist und wenn da noch ein Business hintersteht, wirds umso schwerer. Ich hab bei mir ja einen Großteil auf 2.8.4er Basis laufen und ich hab auch Kunden, die hier mitlesen und es gab schon ein paar böse Mails, nachdem, was hier im erstem Halbjahr ablief nach dem Motto: du hast mir den Sch... angedreht, nu schau auch, das es läuft. Aus heutiger Sicht war es die richtige Entscheidung, auf 2.8.4 zu setzen, denn all die Probleme mit PHP 5.5 / 5.6 (die den 2.8.3er SP3 nötig machten), hab ich heute nicht. Im Prinzip fehlt mir nur noch die Umstellung auf mysqli, aber das liegt jetzt eben in meiner Hand und wird mir nicht vom Provider vorgegeben. Viele der Probleme wären ja auch garnicht aufgetaucht, wenn man die über 4 Jahre alten Modul-Richtlinien beachtet hätte.
P.S.: Ich habe viele CMS-Systemwechsel in den letzten Jahren gemacht, aber noch keinen, der von WB wieder weg geht :wink:
-
@ jacobi22
Danke Dir für das (sehr!) nette Posting.
Zunächst:
Nein es liegt nicht am neuen Modul. Damit bin ich übrigens extrem zufrieden :-)
Selbstverständlich auch nicht das Thema Ladeoptimierung.
Das alles war interessant und im erwarteten Bereich oder sogar darüber.
Schon gar nicht geht es um Arbeitszeiten des Entwickler-Teams selbst.
Das Engagement ist vom Umfang her absolut zu begrüßen.
Der Grund für den Frust ist tatsächlich der Projektstand.
Und damit ist nicht(!!!) die Code-Entwicklung gemeint !!!
Ich sehe das tatsächlich so, dass WB viel an Attraktivität verloren hat.
Ich sehe auch, dass diese Einschätzung von vielen geteilt wird.
Ein Signal, dass da etwas nicht stimmt.
Modul-Entwickler sind über die Jahre gegangen - oder sagen wir es deutlich: viele wurden rausgegrault.
Bei einzelnen mag es sinnvoll sein einen Stopp zu setzen. Aber nicht in der Menge.
Das ist ein deutliches Signal, dass da was nicht stimmt.
Die Forenaktivität hat über die Jahre stetig abgenommen.
Egal, was geschrieben wird, ich weiß (und andere wissen) was war
... vielleicht traut man sich nicht nur weit genug zurück zu gehen.
Ein Signal, dass bei klarem Blick nicht zu übersehen ist.
Unterstützende WB-Seiten verschwinden mehr als neue entstehen.
Ein sehr deutliches Signal ...
...
Naja, die Dinge sind bekannt und werden von unterschiedlicher Seite auch immer wieder angsprochen.
Tatsächlich ist es so, dass solche Entwicklungen die Folge von Entscheidungen sind, die - und da beißt die Maus keinen Faden ab - auf der Projektleitungseben e fallen. Nämlich Entscheidungen, die dafür sorgen, ob eine Plattform (nochmal: da macht der Core gerade mal unter 25 Prozent aus) attraktiv ist und Leute anzieht oder nicht.
Die aktuelle Plattform tut das nicht (mehr).
Hier wurde also etwas versäumt. (Was ja auch schon mal passiert.)
Weißt Du: ich kann auch die schwierige Sitaution der Führung verstehen. Der Eindruck dort, dass einem das trotz extremen persönlichen Engagement immer mehr aus der Hand gleitet, muss erst mal verkraftet werden (egal was gesagt wird, das Gefühl ist sicher da ... und kein einfaches).
Bei dem dort vorhanden aktiven Engagement kann ganz sicher(!) nicht(!) sagen, dass an der Entwicklung von WB kein Interesse besteht. (Das wäre ausgemachter Quatsch und völliger Bödsinn.) Aber dass das Interesse daran, speziell die Plattform selbst zu entwickeln, nur sehr gering vorhanden ist, das kann man sicher sagen. Und der heutige Thread hat sehr deutlich gezeigt, dass die Maßnahmen, die für die Entwicklung notwendig wären und immer wieder von unterschiedlicher(!) Seite angesprochen werden und teilweise sogar angeboten wurden, dort kaum interressieren oder die Notwendigkeit teilweise negiert wird. Teilweise wurde auch deutlich gesagt: dafür bin ich obwohl ich das Projekt leite einfach nicht zuständig ... bzw. interessiert mich überhaupt nicht.
Naja, auch das muss man akzeptieren.
Aber es knickt einen schon, gerade wenn man wirklich Fan ist.
Aufhören werde ich sicher kurzfristig sicher nicht. Dazu fehlt mir die Zeit, mich woanders einzuarbeiten ... und das nächste Projekt ist auch gerade angelaufen ... aber doch, der Gedanke wächst. Und ja, das macht mich traurig.
-
Ja, so Trauertage, die kenne ich...
An sich ist es einfach:
Die geistigen Eliten hier ignorieren den Umstand, dass die Leute in Scharen weglaufen.
Sie verstehen nicht, dass ein CMS alles rundherum ist, nicht nur der Core.
Zum Core gehört nicht einmal das News-Modul, bald auch nicht einmal mehr der WYSIWYG-Editor. Dann wird WB wohl unbrauchbar sein, aber das ist egal.
WebsiteBaker ist ein Privatprojekt geworden.
-
Schau ich mir die letzten Postings im Bootstrap-Thread an, lag ich wohl nicht so falsch.
In den meisten Fällen der (ich sag mal) "Frustäußerungen" in diesem Jahr standen irgendwie immer eigene Projekte irgendwo im Hintergrund, aber nicht aus reinem Egoismus, sondern schon aus der Überzeugung, das der in diesem Projekt gewählte Weg doch eigentlich kein falscher sein könnte und durch die Idee doch auch ein Nutzen für die Gemeinschaft entsteht.
Natürlich entsteht ein gewisser Frust, wenn ich z.b. schon Modelle in der Schublade habe, die rein auf die WB 2.8.4 und deren Funktionen oder Strukturen aufsetzt, die aber niemand nutzen kann ohne eine 2.8.4 oder den Umbau auf gemeinsame Nutzung. Bei der Reparatur des MapBaker-Moduls, das seither ja auch schon fast 900 Downloads hatte, hab ich z.b. bewußt auf den Einsatz von Twig verzichtet und mir auch extra dafür wieder ältere WB-Versionen zum Testen erstellt. cwsoft versucht erfolgreich den Spagat, um die Nutzer älterer Versionen genauso anzusprechen wie auch die der zukünftigen. Es gab aber auch Modulautoren, die sich diesen Extra-Aufwand nicht angetan haben und in den Kundenprojekten bau ich auch nichts mehr ohne Twig oder mit einer Brigde zu älteren WB's. Niemand macht einen Downgrade und die meinigen Kunden-Module werden immer nur in einem einzigem Projekt eingesetzt. Ich brauch keine Abwärtskompatiblitä t.
Wenn du nun das Core-Projekt anschaust, dann kannst du dir diesen Schnitt zumindest aktuell nicht erlauben. Die User verstehen jetzt schon nicht, warum durch PHP < 5.4 Probleme in ihrer Installation auftauchen und grundsätzlich ist es immer Schuld von WB, wenn ein Modul XY nicht funktioniert. Das aber viele Module aus dem Zeitraum 2008 - 2010 stammen und dieser Zeitraum in der EDV Meilensteine sind, interessiert nicht.
Als Core-Entwickler mußt du nach allen Seiten schauen und wenn Manu sagt, die Technik ABC ist nicht unbedingt interessant, dann muß das nicht mal ihre persönliche Meinung zu dieser Technik sein, sondern bezieht sich auf deren Verwendung im WB-System.
Ich klau mal den Satz (http://www.WebsiteBaker.org/forum/index.php/topic,27781.msg193242.html#msg193242), der dich so mies umgestimmt hat
Aktuelle Module in ein Design-Framework zu packen ist, krass gesagt, derzeit Traumtänzerei. Wenn ich mir anschaue, wie 99% der Module ihr HTML schön versteckt in zig PHP-Files zeichenweise per echo() zusammenfrickeln... sehe ich da absolut keine vernünftige Lösung. Das wird erst wieder diskutabel, wenn auch Module konsequent auf den Einsatz von Twig umsteigen.
Was wird gesagt? Es geht in keinster Weise darum, das die im Thread besprochenen Frameworks Mist sind und auch nicht, das ein Einsatz innerhalb von WB für immer ausgeschlossen ist, sondern darum, das, wenn man es jetzt einbauen würde, kein Nutzen für das System WB entstehen würde. Nicht mehr - nicht weniger
Wie kommt es dann bei manchem an?
WB verweigert sich solcher Frameworks, die doch so beliebt sind und modern, das kann nur bedeuten, das WB unmodern ist und auch bleiben will. Punkt.
Und genau darum geht's eben nicht. Du brauchst Lösungen, die für alle nutzbar sind und das, ohne irgendwelchen Streß.
Ich kenne die "alten Sachen" nicht, die da zur Abspaltung geführt haben, habe so etwas aber auch schon bei anderen Systemen durchgemacht. Es ist streng genommen immer der Grund, das Leute ihre eigenen Ideen in einem Fork verwirklicht haben, egal, ob mit oder ohne vorherigem Streit. Rein ursächlich war dann irgendeine Funktion im CMS, die einer für super-sinnvoll hielt, weil er sie für sich (und seinem Freundeskreis) gebraucht hat. Kannst du durch die Geschichte blicken, war überall so, auch bei Joomla oder WP. Und das findest du auch durch das ganze Leben bis hin in deine privaten Lebensbeziehungen zu wem auch immer.
In jedem der Fälle hat sich der Enttäuschte nicht die Mühe gemacht, die Argumentation des Ablehners zu verstehen und was ich im realem Leben noch im persönlichem Gespräch schaffen kann, geht im Web ganz fix den Bach runter. Wenn einer schreibt, Uwe ist doof, das sind das 12 Tastaturanschläge, getippt, gesendet, gilt als gesagt, fertig. Schaut man sich aber in die Augen dabei, wird er schon vorher grübeln, wie ich denn reagiere und ggf einen Meter zurückgehen, falls da eine Faust geflogen kommt. :lol:
Das ein OpenSource-System die Möglichkeit für einen eigenen Fork mit all den eigenen Ideen bietet, macht es eigentlich unnötig, Kompromisse einzugehen oder auch nur über die Gegenargumentation nachzudenken.
Ein Fork ist ja nichts Böses. Man muß nur das Gute darin sehen, z.b. ist es auch ein Gradmesser, ob eine frühere Entscheidung, Idee XY abzulehnen richtig oder falsch war.
Ich denk, einig sind wir alle darin, das die Zeit vom Jahresanfang bis zum Erscheinen des SP3 dem Projekt WebsiteBaker nicht gut getan hat. Schade finde ich nur, das niemand versucht, Gründe dafür zu verstehen :roll:
-
Diese Debatte ob Twigs oder sonstwas - de wird letztlich immer als Mäntelchen hergenommen.
Wurde in den letzten 5 Jahren
- die mitgelieferten Templates geändert?
- Das News-Modul brauchbar gemacht?
- Wenigstens ein bisschen PR gemacht?
- versucht, Leute zu gewinnen, die sich engagieren?
Was mit einfällt, war das Form-Modul das einzige, das ein wenig aufgefrischt wurde.
Ja, klar: Das hat alles mit TWIGG zu tun.
-
[...] Post gelöscht
Verstehen hat etwas mit Wollen zu tun. Wo kein Wollen, da gibt es kein Verstehen und in diesem Fall wird jedes Wort sinnlos..
Manuela
-
[...] Post gelöscht
Verstehen hat etwas mit Wollen zu tun. Wo kein Wollen, da gibt es kein Verstehen und in diesem Fall wird jedes Wort sinnlos..
Manuela
Das könnte auch von mir sein.
Erklärs mir mal!
-
OK, ich erklärs dir:
- Warum seit Jahren die Templates nicht geändert wurden:
Ein Musterbeispiel: Es gab ellenlange Threads, Leute die sich bemüht haben, Abstimmungen.
Irgendwann kam dann schlagartig eine Vorgabe, die so haarsträubend und realitätsfern war, dass das Thema seither vom Tisch ist. (Die Vorgaben sind im internen Forum, und _jeder_ hat sie für haarsträubend und realitätsfern gehalten.)
Irgendwann kam nochmal die Aussage: "Wenn ich eine halbe Stunde Zeit hätte, würde ich selbst ein Template machen". Hast du eigentlich schon jemals eines gemacht?
- Warum das News-Modul so unbrauchbar ist?
Wer braucht denn schon ein News Modul. Und geht ja eh. Soll halt irgendwer anderer machen. Und dann schmeissen wirs weg.
- Kein bisschen PR gemacht wurde?
Ja wie denn?: Ein CMS das sich an der Oberfläche überhaupt nichts ändert? In Zeiten von Web2.0 (eh schon lange her!) tut sich der geneigteste Redakteur schwer, das vergammelte News-Modul, die abgehalfterten Tabellen-Designs und Module ala Gästebuch als innovativ zu verkaufen. Das Gesamtkonzept von WB - ja, das ist immer noch gut. Aber das alleine reicht nicht.
- versucht, Leute zu gewinnen, die sich engagieren?
Leute - das sind doch diese Störfaktoren, die immer irgendwas wollen. Wenn sie kuschen und betatesten, ok, aber sonst nicht.
Ein Blinder mit Krückstock sieht, dass WB gegen die Wand gefahren wird. Und da sind nicht irgendwelche äußeren Umstände schuld, sondern Unfähigkeit, Feigheit, falsche oder gar keine Entscheidungen.
Und wer hat das zu verantworten? Doch wohl die, die hier bestimmen. Oder TWIG?
-
@jacobi22
Also das verstehe ich jetzt wirklich nicht.
Ich weiß aber auch nicht ob Dein Posting als Antwort auf meinen Post gedacht war. Irgendwo ist ja mal wieder was gelöscht worden was nicht gelesen werden darf.
Von dem Wunsch irgendwelche Module oder Verbesserungen am Core vorzunehmen war im Zusammenhang mit meinem Frust zumindest auf meiner Seite keine Rede. Im Gegenteil ... lass genau das mal liegen ... das Konzentrieren darauf führt nämlich genau dahin, wo WB gerade immer mehr drauf zusteuert.
Was nützt mir ein Modul oder ein optimierter Core ...?
Wenn die Leute weglaufen. Und die kommen nicht wegen dem Core oder wegen Randmodulen.
Also: Meine Stimmung hat rein gar NICHTS mit dem Core zu tun oder das Ideen zu Modulen nicht aufgegriffen werden. Ehrlich gesagt sind mir solche Gedanken doch ein wenig fremd. Insofern kann ich Deine Ausführungen aktuell nicht zuordnen. Und nicht das Missverständnisse entstehen: an Gabelbissen hatte ich nie Interesse. Im Gegenteil ...
Aber wie gesagt, ich habe Deine Ausführungen nicht wirklich verstanden oder sie nehmen auf etwas Bezug, was von meiner Seite so nicht vertreten wird.
Ausdrücklich nicht an dich gerichtet ...
Verstehen hat etwas mit Wollen zu tun. Wo kein Wollen, da gibt es kein Verstehen und in diesem Fall wird jedes Wort sinnlos..
Ja. Das unterschreibe ich. Viele Rückmeldungen von verschiedenen(!) Seiten hier haben gleichen oder ähnlichen Inhalt. Mal weniger deutlich und subtil. Mal etwas direkter. Die meisten sagen nichts und gehen. Auch das ist eine Aussage. Sogar ein noch stärkere. Es gehört schon viel dazu, diese Inhalte ständig zu überhören. Naja, verstehen kann ich das tatsächlich ein wenig ... Aber hilfreich für WB ist das wohl nicht ;-)
-
damit wäre dieser Thread, der eigentlich, wie ich finde, recht gut begonnen hat, für mich auch erledigt.
die noch nicht veröffentlichte WB 2.8.4 mit den "eingebautem" Twig war vor ein paar Wochen der Grund, das ein engagierter und aktiver Modulautor hier Kritik geäußert hat. Natürlich kann man Module auch ohne dieses Twig bauen, aber wir standen nun mal kurz vor der Veröffentlichung der 2.8.4 , diese dort angebotene Technik zu nutzen, liegt bei neuen Modulen doch auf der Hand, könnten als Beispiele für weitere genutzt werden und bedeuten auch, das es noch Leben gibt. Natürlich ist Twig nicht die Wunderwaffe, es ist ein Baustein. Natürlich ist es schade, das diese Module nun in der Schublade warten müssen, zumal diese, nach dem, was ich weiß, sicher bei vielen Leuten Interesse gefunden hätten. Setzt man sich mit dieser Kritik auseinander, kommt man garnicht drum herum, sie als berechtigt anzusehen, denn es bedeutet eben mehr als ein, zwei oder auch sechs neue Module.
Aber wenn du Twig als Beispiel nicht magst, nehmen wir ein anderes, wie wäre es mit der Templatepräsentatio n.
Es gab eine Idee, ein paar Leute, die sie anpacken wollten und so oder so wäre eigentlich etwas dabei heraus gekommen, das WB einen Nutzen bringt. Man hat nur vergessen bzw die Hinweise ignoriert, das man solch Umbau nicht ohne die Webseitenadministra tion machen kann. Ich lass auch keinen Mauerer in meinem Haus rumdoktern, ohne das vorher mit ihm abzusprechen.
Ein paar kleine Fragen, läßt sich das so machen, passt das ins Konzept, hier mein Vorschlag, was hälst du davon? Wäre so einfach gewesen. Statt dessen lief das ab wie im Rausch und ruck-zuck lag die Lösung auf dem Tisch. Und eine Absage.
Jeder, der mit WB zu tun hat, weiß, das in Sachen Templates kein Weg an WebsiteBaker.at vorbei geht, andersherum nützt ein totes oder "privates" WB dieser Seite aber auch nichts, eigentlich die besten Voraussetzungen für einen Kompromiss, wo beide Seiten doch nur gewinnen können. Um das zu erreichen, müssen aber beide Seiten miteinander sprechen.
Natürlich kann ich die Enttäuschung nachvollziehen, man hat sich eingesetzt, eine mögliche Lösung präsentiert. Niemand freut sich über eine Absage, wäre aber vermeidbar gewesen.
Am Ende war eine die Böse und der andere hat sich beleidigt zurückgezogen und jede Woche mal ne Spitze gepostet - und das ohne Twig
@ Yetiie: hak meinen Text einfach ab
Was nützt mir ein Modul oder ein optimierter Core ...?
Wenn die Leute weglaufen. Und die kommen nicht wegen dem Core oder wegen Randmodulen.
Warum dann?
Natürlich hätte man auch den Core so lassen können bzw sich rein auf die Aufgaben beschränken können, die PHP, MySQL oder die Sicherheit vorgeben. Frag doch mal die Modulautoren, dort kamen doch die meisten Anregungen her. Ein Bakery z.b., das zu den meist genutzten "Randmodulen" in WB zählt, muß nicht 230 Dateien haben, es käme, neu aufgelegt mit den Möglichkeiten des umgebauten Cores und mit erweiterten Funktionen nicht mal auf die Hälfte und hätte Dank (Achtung! Böses T-Wort) Twig auch noch mehr Möglichkeiten, das Ausgabedesign an seine Bedürfnisse anzupassen.
Natürlich hätte man über die Jahre dem News-Modul ein paar neue Funktionen geben können, Ideen und Codebeispiele haben diverse User auch schon fertig gepostet. Geht man in der WB-Historie aber etwas zurück, findet man auch ein paar Ursachen, z.b. war eben nach meinem Kenntnisstand eine 2.8.4 nie geplant und ein News-Modul-Remake für die 2.9 vorgesehen, wenn all das im Core eingebaut ist, was geplant, gewünscht und gefordert war. Manch einer meint, hätte man noch in den SP3 einpacken können. Darüber gibt es verschiedene Meinungen, ein SP ist eben ein Core-Fix, keine Erweiterung. Mit etwas mehr Zeit vom Beginn der Arbeiten am SP3 bis zur Veröffentlichung wäre vielleicht sogar noch etwas gegangen, aber mit PHP 5.6 bzw der Tatsache, das mindestens zwei große deutsche Anbieter PHP 5.6 direkt am Tag des Erscheinens als Voreinstellung genommen haben, gab es hier einen Zugzwang.
Aber da sind wir wieder bei dem, was ich in den letzten zwei Postings versucht hab, zu erklären.
Es wird festgestellt, das ein Modul XY über die Jahre wenig verbessert wurde, aber es wird sich nicht die Mühe gemacht, zu hinterfragen, warum das so ist.
Ein anderer wichtiger Punkt, altes deutsches Sprichwort oder neudeutsche Redewendung, keine Ahnung
Wenn zwei dasselbe machen, ist es noch lange nicht das Gleiche.
DarkViper hat zu liefern, Fehler sind auszuschließen, Lieferzeitraum: gestern.
Auf der anderen Seite gibt es ein paar Module, die seit Jahren Fehler produzieren, teils Notices, teils richtige Stopper.
Kommen dann Anfragen von Usern, gibt es promt eine Reparaturanleitung, dabei wäre es so einfach, mal eine gefixte Version zu veröffentlichen. Das ist die Geschichte mit dem Glashaus oder dem Besen vor der eigenen Tür....
Wir sind alle nur Menschen, jeder hat seine Fehler und seine Sorgen und wenn sich jeder mal die Mühe macht, über seinen Tellerrand hinauszuschauen und mal versucht, sich in den anderen hineinzuversetzen, versucht, zu verstehen, warum eine Entscheidung genau so getroffen wurde, dann können wir uns das Gepoltere in den diversen Threads eigentlich sparen. Neben der scheinbaren Ruhe für die Öffentlichkeit sind solche Streit-Threads aus meiner Sicht die größte Schadensquelle
-
Hallo,
was mich absolut und tierisch nervt, sind die Heils- und Fortschrittsverspre chen, die auf WB 2.8.4 oder gar 2.9 Bezug nehmen. ICH habe keinen Zugang zu den geheimen internen Forenthreads. Ich weiß nicht, wie der Entwicklungsstand ist, woran gearbeitet wird, woran die Veröffentlichung der neuen Versionen scheitert. Für mich zählt, was verfügbar ist, und das ist die 2.8.3 SP3. Alles andere ist für mich ZUKUNFTSMUSIK. Zumal es ja nicht den Ansatz einer Zeitplanung gibt, ob und wann diese Versionen offiziell verfügbar sein werden. (BER lässt grüßen!)
Was mich weiterhin nervt, ist das Geraune über Module in der Schublade, die leider, leider noch nicht veröffentlicht werden können. Ja, super. Das Henne-Ei-Problem in Reinform.
Was mich extrem ärgert, ist das Über-einen-Kamm-Scheren bzw. die Unterstellung, dass irgendwer von Manuela 16-Stunden-Tage abverlangt. Ich sehe solche Threads nirgendwo im Forum. Das ist einfach Quatsch. Jedem halbwegs ernstzunehmenden WB-User ist klar, dass es sich bei WB um ein freiwilliges Projekt handelt, für dessen Weiterentwicklung die daran beteiligten Leute ihre Freizeit opfern.
Kritik an den Unzulänglichkeiten dessen, was auf absehbare Zeit für die Normalsterblichen verfügbar ist, sprich das WB-Downloadpaket mit News im Tabellendesign, einem kastrierten Form-Modul (im Tabellendesign) und dem altbewährten (ROTFL) FCKeditor sowie den wahnsinnig überzeugenden mitglelieferten Templates Round, Simple und AllCSS ist aber auch nicht gestattet. Dabei wäre es ein leichtes, an diesem Missstand etwas zu ändern - sogar im Rahmen des aktuell verfügbaren 2.8.3 SP3-Pakets. Eine 2.8.3 SP4 mit dem CKE statt FCKE, Miniform statt Form, einem Newsmodul ohne Tabellendesign und sinnvollen, zeitgemäßen Templates statt diesen schmerzhaften Peinlichkeiten - wo ist das Problem? Erklärt es mir. Bitte.
Mein Kenntnisstand ist: Selbst die 2.8.4 wird irgendwann mit dem hoffnungslos veralteten, dysfunktionalen FCKEditor ausgeliefert. Die Core-Module News und Form wurden nicht weiterentwickelt. Als Standardtemplates sind die Templates aus der WB-Steinzeit an Bord, die jedem halbwegs versierten Webworker die Schamesröte ins Gesicht treiben.
Mit dem Backend-Design von WB 2.8.4 (Rev. 2101 aus 02/2014, was anderes kenne ich nicht) habe ich übrigens so gut wie keine Probleme mehr. Es ist nicht schön, es ist ganz sicher nicht das Optimum an Usability, aber es ist auch (noch???) nicht so schlimm wie dasjenige von Contao, Typo3 oder Joomla. Yay.
Oh nein, ich stelle das ja gar nicht infrage, dass an WB bzw. dessen Doku weitergearbeitet wird. ES KRIEGT NUR KEINER MIT. Es wäre doch so einfach. Es gibt den Newsbereich der (gruseligen) WB-Website, es gibt den Announcement-Bereich hier im Popcornforum. Einfach nur mal ab und zu ein Statusupdate. Liebe Leute, aktuell arbeiten wir gerade da und daran, es gab noch die und die Probleme, aber die haben wir jetzt in den Griff bekommen; als nächstes steht auf der To-Do-Liste das und das. Aktuell klemmt es da und daran, wer hat eventuell eine Lösung dafür?
Doch stattdessen wird jegliche Kritik am unbefriedigenden Status Quo als Majestätsbeleidigun g gewertet. Da wird dann anklagend auf die Entwicklungsarbeit an WB 2.8.4 verwiesen, die allerdings im stillen Kämmerlein erfolgt. Da wird auf den großen Aufwand, das Wiki zu beschicken verwiesen, auf dessen Vorhandensein in einem Nebensatz in einem von drölfzigtausend Threads hingewiesen wird - während die auf der offiziellen WB-Homepage verlinkte Entwickler-/Anwender-/Templatedoku munter vor sich her gammelt und man dafür auch noch kritisiert wird, sich an selbige zu halten, weil ja total veraltet.
Dieses Kommunikationsprobl em ist es, was nicht nur ins Kraut sprießende Spekulationen begünstigt, sondern auch für fortschreitende Frustration bei den noch verbliebenden Stammbenutzern von WB sorgt und weshalb sich keiner mehr großartig engagiert, weder im Verein noch durch Beisteuern von Modulen o.ä. Und wenn doch neue Module kommen, schaffen es diese nicht ins offizielle Repository (z.B. Accordion) oder werden gleich in Bausch und Bogen als Traumtänzerei abgewatscht.
Aus diesem Frust heraus gibt dann ein Wort das andere, und man "unterhält" sich hier in einem Tonfall, der Flamewars à la Piratenpartei schon durchaus nahe kommt. (Sowieso deutliche Parallelen: eine im Grunde genommen tolle Idee/Ideologie wird dadurch zerstört, dass sich deren Anhänger gegenseitig zerfleischen. Glückwunsch.)
Lange Rede, kurzer Sinn: Es wäre aus meiner Sicht allerhöchste Zeit für ein Update von "WB, was war - WB, was wird". Und etwas mehr Verständnis für die Sichtweise der Anwender, ohne sich davon gleich angegriffen, unter Druck gesetzt oder missverstanden zu fühlen.
Gute Nacht,
-Florian.
-
Hallo,
was mich absolut und tierisch nervt, sind die Heils- und Fortschrittsverspre chen, die auf WB 2.8.4 oder gar 2.9 Bezug nehmen.
Genau das ist der Grund, warum keiner aus der Community sagt "ist bald fertig" jeder hat sich einfach zu oft die Finger daran verbrennt ;)
Mein Kenntnisstand ist: Selbst die 2.8.4 wird irgendwann mit dem hoffnungslos veralteten, dysfunktionalen FCKEditor ausgeliefert. Die Core-Module News und Form wurden nicht weiterentwickelt. Als Standardtemplates sind die Templates aus der WB-Steinzeit an Bord, die jedem halbwegs versierten Webworker die Schamesröte ins Gesicht treiben.
Editor:
Im Internen Forum gibt es eine Testversion des CK Editors.. nur so am Rande
Module:
Was willst denn bei dem veralteten Zeug weiterentwickeln? Willst noch mehr Copy & Paste verbrechen rein bringen?
Da gibt es nur eine vernünftige Lösung: den ganzen ... Löschen und neu machen... is halt nur meine Meinung ;)
Und wenn doch neue Module kommen, schaffen es diese nicht ins offizielle Repository (z.B. Accordion) oder werden gleich in Bausch und Bogen als Traumtänzerei abgewatscht.
Man muss nur eine zuständige Person z.B. Ruud anschreiben und schon ist es drinnen...
Aber was ich mich frage:
Wenn du so gut meckern kannst und jeden Fehler siehst ... warum nimmst dich nicht selbst beim Wort und machst z.B. einfach ein Backend-Design was in deinen Augen super und TOP ist.
Dann machst eine Umfrage was auch immer - somit hast die Community auf deinen Seiten und es muss rein...
-
Aber was ich mich frage:
Wenn du so gut meckern kannst und jeden Fehler siehst ... warum nimmst dich nicht selbst beim Wort und machst z.B. einfach ein Backend-Design was in deinen Augen super und TOP ist.
Dann machst eine Umfrage was auch immer - somit hast die Community auf deinen Seiten und es muss rein...
Nenne mir EIN Beispiel aus den letzten 5 Jahren, wo das so gelaufen ist.
Ich kann dir im Gegenteil einige Beispiele nennen, wo es gelaufen ist immer: Nichts passiert.
Was willst denn bei dem veralteten Zeug weiterentwickeln? Willst noch mehr Copy & Paste verbrechen rein bringen?
Übersetzt: Es wird nichts passieren. Das alte News-Modul bleibt wie es ist.
-
schau dir einfach den code von WB an - da siehst genug Beispiele...
-
Um den Code gehts nicht.
Kein Mensch stochert da drin herum.
Es geht um sichtbare Veränderungen.
-
Um den Code gehts nicht.
Kein Mensch stochert da drin herum.
Es geht um sichtbare Veränderungen.
Wenn du wüsstest wie oft man sich bei größeren Ausschreibungen verteidigen muss, da der Core ja nicht so schön aussieht wie z.B. typo3 ;)
-
Chio, Du bist doch Spezialist für 'Sichtbares'.
Weshalb zeigst Du mir (als Laie, die ich bin -vollständige Informatikausbildun g und jahrzehntelange Praxis in internationalen Konzernen lass mer da einfach mal weg) nicht wie das geht?
Bau ein, vielleicht auch zwei wirklich unterschiedliche Themes. Die Vorgaben dazu sind minimal und eigentlich für Jederman selbstverständlich:
- Die System- und Datensicherheit muss zu 100% erhalten bleiben
- Es dürfen keine Änderungen am Core vorgenommen werden
- Sämtliche Themes (auch das bisherige WbTheme) müssen frei umschaltbar/auswählbar sein
- Die Reaktionszeiten müssen auch auf sehr schwachen Rechnern in einem vernünftigen Rahmen bleiben
Das ist alles... nur diese vier, eigentlich selbstverständliche n, Punkte, die einzuhalten sind.
Ich erinnere nochmal an Deine Aussage:
Um den Code gehts nicht.
Kein Mensch stochert da drin herum.
Es geht um sichtbare Veränderungen.
Jetzt hast Du die Chance, nicht einfach nur zu labern und sinnbefreit andere zu kritisieren, sondern zu beweisen, dass Deine Aussagen Hand und Fuß haben. Zeig es mir!!!
Manuela
-
Hallo,
für den Anfang würde es doch reichen, Argos wieder zu ermutigen, "sein" Backend-Theme auch für 2.8.4 fit zu machen.
Ansonsten finde ich es schade, dass Ihr Euch nun an diesem Themethema festbeisst. Mir ging es im Kern um etwas anderes, nämlich die Informationspolitik .
@Badknight
1) habe ich irgendwo geschrieben, dass ich verbindliche Termine sehen wollen würde?
2) Ich habe nicht gesagt, dass das Newsmodul neu programmiert werden soll, sondern einfach nur per default kein Tabellendesign mehr ausspucken. Ich habe auf das fantastische Modul Miniform hingewiesen, das ein Top-Ersatz für das gakige Core-Form-Modul wäre. Wenn es im Entwicklerforum eine 2.8.4-Version mit dem CKE gibt, ist das ein großer Schritt in die richtige Richtung.
3) "Wenn du so gut meckern kannst..." - das ist Kindergartenniveau. Du kannst Dir gern mal meine letzten Forenbeiträge (http://www.WebsiteBaker.org/forum/index.php?action=profile;u=6109;sa=showPosts) anschauen und dann selbst prüfen, ob da "Gemecker" zu verzeichnen ist.
Aber warum sachlich bleiben, wenn man auch persönlich werden kann.
-f.
-
@manuela
Ich rede nicht von Backend-Themes, sondern von Ersatz für Round, AllCSS usw.
Da gibt es hunderte mögliche Kandidaten, nicht einmal alle von mir ;-) , auch von zb badknight.
Man kann JEDES hier nehmen: http://WebsiteBaker.at/wb-templates/
Such dir drei aus.
Dass man vielleicht noch mal drüberschauen sollte, ob die Standards eingehalten werden - ja klar. Mir ist ehrlich gesagt völlig egal, ob das Menü mit ob_start oder SM2_BUFFER oder direkt ausgegeben wird. Sag was Standard ist, und wir machen. Aber: Sags.
Dass das Argos-Theme unter WB 2.84 nicht läuft, ist mir nicht aufgefallen - und wenn: Das wird wohl leicht zu fixen sein.
Hier sehe ich keinen dringenden Handlungsbedarf. Das Argos Theme ist modern genug.
Ob in den Voreinstellungen für News und Suche immer noch unnötige Tabellen sind, weiß ich auch nicht.
Das wären mal die _allereinfachsten_ Sachen.
-
Hi,
Da gibt es hunderte mögliche Kandidaten, nicht einmal alle von mir ;-) , auch von zb badknight.
Man kann JEDES hier nehmen: http://WebsiteBaker.at/wb-templates/
Such dir drei aus.
Dass man vielleicht noch mal drüberschauen sollte, ob die Standards eingehalten werden - ja klar. Mir ist ehrlich gesagt völlig egal, ob das Menü mit ob_start oder SM2_BUFFER oder direkt ausgegeben wird. Sag was Standard ist, und wir machen. Aber: Sags.
Wo wir grad bei Butter bei die Fische sind. Würde mich bereit erklären zusammen mit Chio die "ausgewählten Frontend Templates" für die Ausgabe von Topics/Anynews/News/Nix fit zu machen - falls gewünscht.
Gruss cwsoft
-
Dass man vielleicht noch mal drüberschauen sollte, ob die Standards eingehalten werden - ja klar. Mir ist ehrlich gesagt völlig egal, ob das Menü mit ob_start oder SM2_BUFFER oder direkt ausgegeben wird. Sag was Standard ist, und wir machen. Aber: Sags.
Für Frontend-Templates gibt es in diesem Sinne keine 'Standards'. Höchstens Empfehlungen. (Abgesehen von den ganzen Deprecated-Meldungen, die natürlich beachtet werden sollten.)
ob ob_start() oder SM2::BUFFER (das ist bereits die neue Schreibweise für 2.8.4 - einfach Unterstrich gegen doppelten Doppelpunkt tauschen) ist normal laut Handbuch egal. Nicht egal ist jedoch der undokumentierte Umstand, dass ob_xxx in Verbindung mit include|require_once Probleme macht und oft seltsame Effekte auslöst.
Ebenfalls sinnvoll ist es, den <doctype>-Tag in die erste Spalte der ersten Zeile in der index.php des Templates zu setzen. So ist sichergestellt, dass keine unkontrollierten Whitespaces oder sonstige Zeichen vorher ausgegeben werden, die verschiedene Browser beim Darstellungsmodus beeinflussen könnten.
Ansonsten? Bei JS möglichst auf InlineCode verzichten... damit User evt. auch die Möglichkeit haben, DSP auf ihren Seiten zu aktivieren.
Den vom Browser gesendeten DNT-Header beachten...
Ist evt.mit etwas Aufwand verbunden, aber es soll noch Seitenbetreiber geben, die sich an Datenschutzregeln halten... eine ganz merkwürdige Spezies Mensch.
Größere Mengen PHP-Code evt. in Funktionen/Methoden verpacken und in eine seperate PHP-Datei auslagern, die am Anfang des Templates includiert wirt... und im Template dann nur noch die Funktionen aufrufen. Das macht Templates übersichtlicher und die HTML-Struktur besser wartbar.
Aber wie gesagt, das sind einfach nur Empfehlungen...
Dass das Argos-Theme unter WB 2.84 nicht läuft, ist mir nicht aufgefallen - und wenn: Das wird wohl leicht zu fixen sein.
Hier sehe ich keinen dringenden Handlungsbedarf. Das Argos Theme ist modern genug.
Argos hatte ein komplett neues Theme begonnen, aber trotz meiner Unterstützung aufgegeben, da das ohne größere Eingriffe in den Core nicht realisierbar war. Das wird wieder aufgegriffen, sobald die Trennung von Core und Anzeige komplett ist.
Ob in den Voreinstellungen für News und Suche immer noch unnötige Tabellen sind, weiß ich auch nicht.
Eine Reparatur der alten Module ist deutlich aufwändiger als komplett neue Module. Das ist derzeit nur eine Frage der verfügbaren Zeit.
Manuela