Jürgen Kuri vom Computermagazin c’t brachte es im Zusammenhang mit der NSA-Affäre auf diese einfache Formel. Nun hat TYPO3 absolut nichts mit der NSA-Saga zu tun, ich habe ich diesen Titel gewählt, weil er trotzdem irgendwie passt. Wie man liest, wurde das Erscheinungsdatum von TYPO3 Version 6.2 LTS um fast vier Monate verschoben, nämlich auf den 25. März 2014. Gleichzeitig wird der Support für die TYPO3 Verison 4.5 LTS bis zum März 2015 verlängert. Das ist eine gute und eine schlechte Nachricht zugleich. Positiv ist, dass man eine stabile Version präsentieren möchte, die TYPO3 endlich wieder zu dem macht, wofür es einmal stand. Negativ ist, dass diese Nachricht erneut geeignet ist, das Vertrauen in ein bislang bewährtes CMS weiter zu untergraben. Was mich bei TYPO3 seit geraumer Zeit stört, ist unter anderem Folgendes und darauf werde ich in diesem Artikel auch eingehen.
- Die Zunkunft sowie die weitere Unterstützung von TemplaVoila ist, obwohl sie mit über 330.000 Downloads insgesamt und über 6.700 Downloads in der aktuellen Version 1.8 zu den meistverbreiteten TYPO3-Extensions überhaupt zählt, recht ungewiss. Zwar wird darauf hingewiesen, dass TV auch in kommenden Versionen von TYPO3 unterstützt werden wird, das hört sich aber leider eher wie ein Lippenbekenntnis an, weil man allenthalben den „guten“ Ratschlag hört, künftig besser etwas „anderes“ zu verwenden. Ganz sicher werde ich „etwas anderes“ verwenden, wenn es denn sein muss, aber ebenso sicher nicht mehr TYPO3. Ich habe nämlich wenig Lust, mir in drei Jahren möglicherweise erneut anhören zu müssen, dass dieses „andere TYPO3 Konzept“ schon wieder nicht mehr zu verwenden sei, welcher Grund auch immer dann dafür ins Feld geführt werden mag.
- Die mangelnde Performance, die man TemplaVoila gerne unterstellt und die immer wieder mal als Grund für die Notwendigkeit, andere Template-Engines zu verwenden, geannnt wird, ist bei den 6er Versionen wohl schon im Core enthalten.
- Auch der angebliche „Mythos“, dass nämlich tslib_pibase basierte Extensions nicht mehr unterstützt werden, stellt sich leider immer wieder als Tatsache heraus. Warum ich das so sehe, steht auch in diesem Artikel.
Eine einfache Aufgabe für TemplaVoila
Eine Kunde möchte eine Box in der rechten Spalte, die eine Liste von Links enthält. Diese Links sollen nicht statisch sein, auch kein mit TypoScript generiertes Menü, sondern einfach eine vom Editor willkürlich festgelegte Auswahl von Seiten, die man promoten will. Dabei ist es völlig ungewiss, wieviele Links sich in den beiden Spalten der kleinen Box befinden. Es können drei, fünf oder auch zehn sein, und es versteht sich von selbst, dass wir keine leeren <li> Tags in den HTML-Code schreiben wollen. Auch ein Inhaltselement mit vielleicht 20 vordefinierten Eingabefeldern scheidet aus, weil das erstens recht unprofessionell daher käme und zweitens auch noch sehr unübersichtlich für den Editor wäre. Ein Traumjob also für TemplaVoila und dessen Sections und Container. Man sehe sich die Bilder an und staune. Dass das Ganze auch noch in zehn oder mehr verschiedenen Fremdsprachen funktionieren würde, ist ebenfalls eine nicht zu verachtende Tatsache. Der Redakeur kann selbst eine unbegrenzte Anzahl weiterer Link-Felder hinzufügen (siehe Abbildung „Eingabe im Backend“) und zwar ganz ohne IRRE zu werden. :) Welche andere Template-Engine für TYPO3 bietet diese Möglichkeit, mit automatischer Unterstützung für Fremdsprachen?
Das oben geschilderte Beispiel hat ein neuer Mitarbeiter zusuammengeklickt, der noch nicht einmal drei Monate bei uns beschäftigt ist, aber in der kurzen Zeit TemplaVoila bereits verstanden hat. Aber halt: Das darf man ja heutzutage nicht mehr verwenden, weil da XML-Code in die Datenbank geschrieben wird. Die PHP-Puristen und OOP-Freaks haben aber entschieden, dass das ab sofort pfui! zu sein hat – und fertig. Aber es funktioniert doch bestens? Egal, was anderes funktioniert schliesslich auch, das musst Du dann halt lernen! (wir wollen schließlich Schulungen verkaufen) Aber, aber… es funktioniert doch noch gar nicht! Macht nichts, hilf halt mit, dann funktioniert es bald (wenn nichts dazwischen kommt)!
Höre ich da schon wieder jemanden sagen, „ja aber es »performt« nicht“? Schließlich hat jede TYPO3 Site, die wir (wer immer das sein mag) aufsetzen mindestens 40.000 Besucher am Tag und 10.000 einzelne Seiten ist sowieso das Minimum, das geht mit TemplaVoila nicht. Nein? Richtig! Für solche Sites nimmt man dann halt was anderes, genauso wie man mit einem Golf nicht bei der Formel 1 mitfährt. Ich kann nur sagen, solche Sites sind selten und sie werden immer weniger mit TYPO3 gemacht. Ob das einen Grund hat? Keine Ahnung. Aber weil wir gerade von „performen“ sprechen…
Die Geschwindigkeit von TYPO3 Version 4.5 bis 6.2 beta
Der Bug #52949 ist für jedermann öffentlich zugänglich. Er beschäftigt sich mit dem Rückgang der Performance seit Version 4.5 von TYPO3. Ein Kommentator bemerkt dort trocken „Oh darling….“ und kommt zu folgendem Ergebnis (es wurde ApacheBench verwendet, 100 Zugriffe in Folge, aber keine konkurrierenden):
- Version 4.5 versus Version 6.0 — 6.0 ist um den Faktor 4 langsamer
- Version 6.0 versus Version 6.2 beta — 6.2 beta ist um den Faktor 2 langsamer
- Version 4.5 versus Version 6.2 beta — 6.2 beta ist um den Faktor 8 langsamer
In Anbetracht der Tatsache, dass lediglich Hello World ausgegeben wurde und nicht etwa ein komplexes Layout, ist das ein ziemlich erschütterndes Ergebnis und wird wohl einer der Hauptgründe für die Verschiebung des Release-Datums von Version 6.2 LTS gewesen sein. Man muss faierweise hinzufügen, dass eine Beta-Version mit einer stable Version verglichen wurde, es ist aber trotzdem eine Tatsache, dass Version 6.0 eben nicht mehr den Status beta hat, aber trotzdem im Vergleich zu Version 4.5 um den Faktor 4 langsamer sein soll.
Die Unterstützung von piBase basierten Extensions
Es ist das tägliche Brot von TYPO3-Entwicklern, winzigste und kleine Extensions erstellen zu müssen, weil der Wunsch des Kunden das nun einmal erforderlich macht. Vieles davon kann man mit TemplaVoila und seinen flexiblen Content Elementen (FCE) lösen, aber ganz sicher nicht alles. Wenn es darum geht, eine Datenbank-Tabelle um ein paar Felder zu erweitern, oder eine neue Tabelle zu erzeugen, damit der Kunde irgendwas in der gewünschten Weise präsentieren kann, dann leistete der Kickstarter in den 4er Versionen von TYPO3 stets treue Dienste. Er ersparte einem das langweilige Anlegen der Grundstruktur einer TYPO3-Erweiterung. Dieser Kickstarter funktioniert in Version 6.x nun nicht mehr. Theoretisch funktioniert er zwar, es gibt sogar einen Patch dafür. Wendet man diesen Patch an, kann man den Kickstarter auch unter Version 6.x aufrufen und solange damit arbeiten, bis man auf den Button „View Result“ klickt, der notwendig ist um das Ergebnis schließlich auf die Platte zu schreiben. In diesem Augenblick erscheint fatal Error und das war’s dann. Das wäre ihr Preis gewesen, fällt einem dazu dann nur noch ein. Es bleibt also nichts anderes übrig, als die Extension unter 4.5 zu erstellen oder die Extension-Grundstruktur eben per Hand anzulegen. Welch ein Fortschritt!
In manchen Foren liest man dann so etwas:
Der Extension Builder ist komplett anders und erstellt moderne Extensions mit Extbase und Fluid. hier musst du keine Sprachen mehr selektieren. Bezweifel, dass der alte pibase-basierte Kickstarter noch mal für 6.0 angepasst wird. Das pibase-Thema ist ja eigentlich Geschichte.
Ah ja, ich verstehe, also offenbar doch kein Mythos. Damit ich bei Version 6.x eine bestehende Datenbank-Tabelle um zwei, drei Felder erweitern kann und dazu den Kickstarter benutzen will, muss ich also erst einmal meine Mitarbeiter auf Schulung schicken, damit sie Extbase und Fluid lernen. Zwei Monate und vielleicht tausend Dollar später sind wir dann aber „modern und komplett anders“. Nun denn, bleiben wir eben altmodisch.
Bitte verstehen Sie mich nicht falsch, es ist klar, dass man in dieser Branche stets Lernprozessen unterworfen ist, denen man sich nicht verschließen darf. Ebenso klar ist, dass das piBase Konzept ein wenig angestaubt ist, trotzdem funktioniert es sehr gut, für viele Anwendungsgebiete. Um was es letztlich geht ist, dass ich eine Wahl haben möchte. Wenn mich ein System zu etwas zwingen will, dann mag ich nicht mehr. Ich lerne dann trotzdem dazu, aber ich lerne etwas anderes. Concrete5 wäre z.B. genau so etwas. Ich lerne ein System, das ebenso „modern und komplett anders“ ist, aber das nicht alle paar Jahre seine Paradigmen komplett ändert, nur weil gewisse Zeitgenossen unter Zuführung von erheblichen Geldmitteln sich das so ausgedacht haben und es offenbar keinen „Chef“ mehr gibt, der ‚mal mit der Faust auf den Tisch haut.
Fazit
Kontinuität hat nichts mit altmodisch oder mangelnder Lernbereitschaft zu tun. TYPO3 stand viele Jahre lang für Kontinuität. Heute wird es nur noch von Insidern bejubelt und von denjenigen hoch gehalten, die sich Profit oder Reputation davon versprechen. TYPO3 wurde Schritt für Schritt kaputt-optimiert und das genau seit dem Zeitpunkt, als Kasper ausgestiegen ist. Heute hört man nur noch „extbase, fluid und flow“ – das allenthalben und überall bejubelt wird. Wer sich dem verschließt, ist ein „ewig Gestriger“ oder hat einfach keine Ahnung. Solche Aussagen sind nichts anderes als pure Arroganz. Ich wünsche mir aus tiefstem Herzen, dass TYPO3 mit der Version 6.2 LTS doch noch die Kurve kriegt, denn eine Open-Source-Community lässt sich zu nichts zwingen. Es mag sein, dass das in Deutschland einigermassen klappt, auf internationaler Ebene klappt es aber bestimmt nicht. Das hat selbst Ubuntu mit seinem Unity-Desktop (den fast niemand haben will) zur Kenntnis nehmen müssen.
Der Artikel ist zwar jetzt schon drei Jahre alt, spricht mir aber auch heute noch aus der Seele.
Ich bin zwar kein Fan von TemplaVoila, aber das ist ja jedem selbst ueberlassen.
Allerdings moechte ich noch ein paar Anekdoten aus meinem Entwickleralltag mit Extbase u. Fluid (u. TYPO3 6.2 allg.) bringen.
Ich muss da leider dem Fazit zustimmen: „Heute wird es nur noch von Insidern bejubelt und von denjenigen hoch gehalten, die sich Profit oder Reputation davon versprechen. TYPO3 wurde Schritt für Schritt kaputt-optimiert und das genau seit dem Zeitpunkt, als Kasper ausgestiegen ist. Heute hört man nur noch „extbase, fluid und flow“ – das allenthalben und überall bejubelt wird.“
Ich merke immer wieder im Bugtracker wie ein leicht arroganter Unterton herrscht, bei dem offensichtliche Bugs runtergespielt werden, weil es anscheinend zu nervig ist, sie zu beheben. Das, oder die Bugs sind jahrelang offen und keiner kuemmert sich darum. (Beispiele folgen gleich.)
Weiterhin ist die Dokumentation fuer viele Bereiche unterdurchschnittlich schlecht, vieles muss man sich aus Blogs o. anderen Quellen zusammensuchen. Ein kleines Beispiel: Ich konnte keine offizielle Dokumentation finden, wie man in Extbase auf das Repository einer anderen Erweiterung zugreift. Erst in einem Blog konnte ich die entsprechende TypoScript-Konfiguration u. Erklaerung finden.
Ich bin selbst Entwickler: Ich weiss, dass Fehlerbehebungen und v. a. Dokumentationen schreiben nervig u. zeitaufwaendig sind, allerdings darf man hier nicht vergessen, TYPO3 hat den Anspruch ein Enterprise-CMS zu sein. Da muss man eben in den sauren Apfel beissen und entsprechende Arbeit abliefern.
Der Zustand wie es jetzt noch immer ist (sprechend von 6.2 LTS), hat leider den Charme eines Hobby-Projekts, das von ein paar (selbstverliebten) Core-Entwicklern mit akademischen, objekt-orientierten Konzepten vollgestopft ist. Es wurde ein richtiges Luftschloss erbaut, das auf den ersten Blick beeindruckend ist, aber bei naeherer Betrachtung an vielen Ecken broeckelt. Lieber wird Feature X u. Y eingebaut, anstatt essentielle Fehler zu beheben. Klar, ersteres ist natuerlich auch spannender (o. wie einer der Core-Entwickler hier meinte: „Entwickler-Porn“) und schmiert eher Balsam auf’s Ego.
Kurz zu meinem Hintergrund: Ich bin seit der 4er-Version dabei und habe in meiner Laufbahn fast alles erdenkliche bisher mit und in TYPO3 angestellt.
Wie versprochen, nun ein paar Beispiele, die mir bisher so begegnet sind. Das alles basierend auf der momentanen, stabilen 6.2.14 LTS. Man kann es nur noch mal betonen: Das soll eine stabile(!), Feature-vollstaendige(!), Long Term Support(!)-Version sein, an der man jahrelang gearbeitet hat.
Starten wir mit Fluid.
– und logische Verknuepfungen: https://wiki.typo3.org/Fluid#Logical_operators
Es ist noch immer nicht moeglich, logische Operatoren wie AND o. OR in if-Verzweigungen zu verwenden. Lange wurde empfohlen, stattdessen entsprechende if-Verzweigungen zu verschachteln um das gewuenschte Verhalten zu erreichen (das muss man sich mal auf der Zunge zergehen lassen – soviel zu „Enterprise“).
Inzwischen wird wohl auf die externe Erweiterung VHS verwiesen. VHS installiere ich seit laengerem standardmaessig, da es vieles repariert u. verbessert, was im Core einfach nur schlampig entwickelt wurde.
Auch verstehe ich noch immer nicht den Sinn u. Zweck warum soviel Energie in die Entwicklung von Fluid investiert wurde und dann sowas rauskommt. Bspw. Smarty kann all das und noch vieles, vieles mehr schon seit Jahren!
– Performance: https://wiki.typo3.org/Fluid#f:switch
In der aktuellen Dokumentation sieht man, dass von f:switch abgeraten wird, da es die Performance massiv beeintraechtigt. (Wenigstens wurde es in der 7er-Reihe behoben.)
f:switch zaehlt fuer mich auch zu den Basis-Features einer Template-Engine und so ein Bug sollte eher als kritischer Fehler (nicht als „Should Have“ – siehe: https://forge.typo3.org/issues/64449) angesehen werden, mit dem TYPO3 6.2 gar nicht erst haette ausgeliefert werden duerfen.
– : https://forge.typo3.org/issues/58621
Dieser View-Helper ist wohl in FLOW3 enthalten, aus irgendwelchen Gruenden allerdings nicht in TYPO3 6.2. Aus diesem Grund sollte es wohl einen Backport aus FLOW3 nach TYPO3 geben. Das Ticket steht auf „Resolved“, allerdings befindet sich dieser View-Helper noch immer(!) nicht in TYPO3 6.2.
Auch bezeichnend, das man dafuer ueber ein Jahr brauchte und trotzdem ist es noch nicht im Release enthalten.
War noch nicht genug? Kommen wir zu meinen Lieblingen in Extbase bzw. der TYPO3 API.
– BasicFileUtility: http://typo3.org/api/typo3cms/class_t_y_p_o3_1_1_c_m_s_1_1_core_1_1_utility_1_1_file_1_1_basic_file_utility.html
Ich hatte vor kurzem einen Datei-Upload in Extbase realisiert und suchte in der TYPO3 API eine Methode, die bzgl. der Bereinigung des Dateinamens mir Arbeit abnimmt. Ich stiess auf BasicFileUtility, die genau das mitbrachte (cleanFileName()). Dumm nur, dass saemtliche Methoden in dieser Klasse als „deprecated“ gekennzeichnet sind und von deren Benutzung abgeraten wird. Noch viel schoener ist, dass es wohl laut Kommentar noch im Core verwendet wird. Und das absolut beste ist, es steht nirgends(!) welche Methoden/Klasse man stattdessen verwenden soll.
– *ResultObject*->count(): https://forge.typo3.org/issues/62518
Das ist mein absoluter Liebling bisher. Ich hatte in einem Repository ein eigenes Query (Custom Statement) erzeugt. Standardverhalten ist, dass Extbase aus dem Ergebnis wieder ein Objekt erzeugt und man auf dieses Objekt wieder die Getter u. Setter wie getUid() aufrufen kann. So weit, so gut.
Allerdings wunderte ich mich, dass der Aufruf der Methode count() auf dieses Objekt immer 1 zurueckgab. Das Objekt war allerdings leer. Ich suchte und fand den oben verlinkten Bug-Report.
Ich finde diesen Bug-Report und v. a. die Antworten besonderes schoen, da man hier sehr gut erkennen kann, welchen geistigen Zustand einige (Core-)Entwickler haben.
Als „Loesung“ wurde hier vorgeschlagen, dass man hier stattdessen mit einem Array als Ergebnis arbeiten sollte (*QueryObject*->execute(true)). Was ist das denn bitte fuer eine Loesung? Was ist denn, wenn ich aber genau die Vorzuege des Objekts brauche? Was ist, wenn ich mit dem Array nicht viel anfangen kann? Warum erzeugt Extbase ueberhaupt standardmaessig aus einem Custom Statement ein Objekt, wenn es solche eklatanten Fehler gibt? Fragen ueber Fragen…
Ich gehe demnaechst zum Eisverkaeufer, verlange eine Schokoladenkugel, er haut mir Vanille drauf und sagt: Im Prinzip ist es auch Eis. Gleiche Konsistenz, gleiche Beschaffenheit, nur anderer Geschmack.
Anstatt sich so einem gravierenden Bug anzunehmen, wird das Ticket lieber geschlossen. (Die naechsten, geilen Features X warten ja schon. Solche Bug-Reports sind ja nur laestig…)
Noch immer nicht genug? Dann hier noch eine Anekdote zu TYPO3-Allgemein.
– Language Fallback: https://forge.typo3.org/issues/17354
In diesem Bug-Report geht um die Funktion, dass man ueber einen Language Fallback auf einer fremdsprachigen Seite, auf der noch keine Uebersetzungen vorliegen, die Inhalte einer anderen Sprache anzeigt. Bspw. sehr nuetzlich, wenn man eine US-amerikanische Version einer Webseite hat, auf der aber nur ein paar wenige Seiten unterschiedliche Inhalte zur britischen Version aufweisen. Fuer die unterschiedlichen Seiten legt man ganz normale US-amerikanische Uebersetzungen an. Fuer den Rest holt man sich ueber Language Fallback die Inhalte der britischen Version.
Ein absolutes, absolutes Kern-Feature, das allerdings nicht in TYPO3 6.2 funktioniert. (In TYPO3 4.5 LTS funktionierte dies noch!)
Hier wird jahrelang herumgedoktort und anscheinend jetzt erst vor zwei Tagen wurde es fuer die Integration in die Release-Version beruecksichtigt. (Fragt sich nur in welche!)
Am Rande moechte ich noch bemerken, dass es mit RealURL auch ein grosses Problem gibt, das einfach so hingenommen wurde. Viele Leute sind hingegangen (ich auch) und haben ganz normal eine Root-Seite angelegt. Darunter als Unterseite dann bspw. eine Seite namens „Startseite“ die – wie der Name schon sagt – dann als Starseite genutzt wurde. Die Root-Seite hat dann einen Shortcut auf die Startseite bekommen. Soweit alles kein Hexenwerk.
Bis zur 6er-Version von TYPO3 liess sich dann die Startseite wie folgt aufrufen: meineseite.de und man sah sofort die Startseite.
In der 6er-Reihe wird nun allerdings weitergeleitet. D. h. bei Aufruf von meineseite.de landet man auf meineseite.de/startseite. Von einem technischen Standpunkt aus mag das nun das korrekte Verhalten sein, allerdings ist es ein Schlag ins Gesicht fuer jegliche SEO-Bemuehungen.
Beim Upgrade von alten 4er-Seiten muss man nun hingehen und die Startseite entsprechend umbauen. Ich habe mit mehreren Entwickler-Kollegen gesprochen, allerdings haben wir keine zufriedenstellende Loesung dafuer bisher gefunden.
Das offensichtlichste, die Startseite zur Root-Seite zu machen, hat einen grossen Haken. Sollte sich die TYPO3-Installation in einem Unterordner befinden, werden saemtliche Links, die auf die Startseite verlinken, von RealURL falsch generiert. (Der URL-Teil mit dem Unterordner wird komplett ignoriert. Aus bspw. – richtig – meineseite.de/typo3basis/ wird – falsch – meineseite.de/)
Das war jetzt mehr, als ich eigentlich schreiben wollte. Das sind jetzt nur die Dinge, die mir bisher so aufgefallen sind. Und bisher habe ich in Extbase noch nichts sehr wildes gemacht (im Gegensatz zu piBase).
Ich finde deinen Beitrag hier sehr lustig und amüsierend, Peter :D
Aber nicht professionell und ganz sicher nicht ernst zu nehmend.
Für mich klingt das wie eine verzweifelte Kapitulation ^^
TYPO3 ist nunmal ein Enterprise-CMS, d. h. JA! du brauchst Experten!
Wenn du bei der Projektumsetzung darauf angewiesen bist fertige Extensions aus dem Repository zu verwenden und nicht dazu in der Lage bist eigene bessere Lösungen zu schreiben, dann kannst du nicht jammern.
Wenn ich schon TemplaVoila lese… kurz, ich mag die Extension nicht. Ich gehe gar noch einen Schritt weiter. Ich verwende keine Extensions mehr aus dem Repository, sondern entwickel alles selbst. Wenn man das macht, ist TYPO3 6.2 eine sehr gute Basis für die Entwicklung hochkomplexer Websites.
Was sicher ist, dass TYPO3 nicht DIE Lösung ist. Für sehr kleine Websites gibt es sicher einfachere Lösungen.
Du solltest ja hier meine E-Mail Adresse sehen. Wenn du noch Probleme mit TYPO3 Projekten hast, würde ich mich denen sehr gern annehmen. Ich bin mir sicher, dass alle lösbar sind.
Das ist doch nichts weiter als eine Unterstellung. Woher willst du wissen, wie ich das handhabe? Wir sind als Dienstleister darauf angewiesen, die Wünsche der Kunden zu erfüllen. Dazu gehört auch, dass man eben nicht jedes Mal bei Adam und Eva beginnen muss, sondern fertige Lösungen verwenden kann. Das Ganze nennt man dann „wirtschaftlich“.
Danke für das nett gemeinte Angebot, aber ich weiß recht gut, wie ich meine Probleme, wenn sie denn auftreten, alleine lösen kann. Mit oder ohne TYPO3.
Genau, deshalb baut man sich eigene Lösungen, die man wiederverwenden kann. Vergiss das Extension-Repository.
Wenn du mir ernsthaft erzählen willst, dass man mit TYPO3 nur weiter kommt, wenn man jede Extension selber entwickelt, dann hast du das gesamte Konzept von eben diesem TYPO3 ad absurdum geführt. Ja, nee is klar, ich muss jetzt aufhören zu schreiben… Ich muss mal eben ein Kernel-Modul programmieren. Runterladen kommt ja nicht in Frage. :)
Naja du hast zwei Optionen. Sich mit dem zufrieden geben, was du kostenlos bekommst oder Zeit/Geld investieren um zu schaffen was du willst.
Es geht leider nicht darum, was ICH will, sondern eher darum, was die KUNDEN wollen. Wenn ich dem erzähle, dass ich sein Plugin erst neu programmieren muss, weil ich das im TER vorhandene verschmähe, dann sehe ich den nie wieder. Wenn du solche Kunden hast, Gratulation.
Was du und viele andere Kommentatoren immer vergessen ist, dass die Akzeptanz von TYPO3 in Asien nicht besonders hoch ist, weil es unzählige Systeme gibt, die Out-Of-The-Box einfach funktionieren, auch ohne Handstände und Schulungen für Redakteure. Der Faktor Geld kann ja nicht völlig ausser Acht gelassen werden, da hilft auch der schönste Code nichts.
Naja wenns billige Lösungen gibt, dann nimm die. In Amerika ist ja auch eher Drupal vertreten.
Das ist eine dermaßen verzerrte Logik, dass man schon fast Absicht unterstellen muß. Es geht nicht um billige Lösungen, es geht darum, dass kein, aber auch wirklich kein Kunde (außer er ist TYPO3-Fanboy) es akzeptiert, daß fast jedes Update völlig unkalkulierbare Kosten nach sich zieht, die dann mit dem fadenscheinigen „Argument“, es sei doch klar „dass man immer lernern und Ahnung haben müsse“ ihre Rechtfertigung finden sollen.
Genau das ist bei anderen Systemen nicht so! Das hat aber nichts damit zu tun, dass die billig wären. Es gibt bei allen CMS gute und schlechte Anwender, gute und schlechte Programmierer sowie gute und schlechte Lösungen. Aber das hohe Ross, auf dem die meisten „TYPO3 Spezialisten“ alle sitzen, finde ich doch ziemlich gewagt. Kundenunfreundliches Release-Herumgeeiere hat nämlich nichts mit Professionalität zu tun.
Ob jemand nun mit TemplaVoila entwickelt oder mit GridElements, zu Fuß per TypoScript, mit Fluid oder was weiß ich mit was … Es sollte dem persönlichen Geschmack überlassen bleiben. Was bei TYPO3 läuft ist aber so was wie eine Religion. TemplaVoila ist plötzlich ein „falscher Gott“ und das nur aus einem Grund: Damit der zu erwartende Hype (die Fanboys spuren ja in aller Regel) um das neue System wieder Geld in die Kassen der Entwickler spült. Das ist eine unehrliche Herangehensweise. Auch das ist bei anderen Systemen nicht so!
Ich fand TemplaVoila nie gut :D
Und ich fand TYPO3 vor Extbase & Fluid nicht gut. Zumindest aus Sicht eines Entwicklers.
Davon abgesehen: Der Sprung von 4.5 auf 6.2 ist so groß wie der Sprung von Windows 98 auf Windows 7. Da funktionieren auch nicht mehr alle Programme. Irgendwann ist der Update-Prozess tot.
Und das mit dem hohen Ross, naja. Vielleicht etwas übertrieben.
Wo ich dir definitiv Recht gebe: Der Umstieg von TYPO3 4.5 auf 6.2 ist teurer und man sollte sich genau überleben ob er notwendig ist.
Du musst TV nicht gut finden. Dennoch eignet es sich hervorragend, wenn Agenturen fix und fertiges HTML inkl. CSS anliefern. Mit TV kann ich Heerscharen von relativ unerfahrenen Entwicklern hinsetzen und zu günstigen Preisen dennoch technisch einwandfreie Produkte ausliefern. Das mache ich jetzt mit concrete5 und nicht mehr mit TYPO3.
Man muss auch Gnome, KDE, Unity, Xfce, Cinnamon, MATE, LXDE und wie sie alle heißen, nicht gut finden. Man verwendet sie einfach nicht, wenn sie einem nicht gefallen. Trotzdem haben sie ihre Existenzberechtigung für die jeweiligen Anwender. Die „Anti-TV Kampagne“ indes, die bei TYPO3 gefahren wurde, war unwürdig. Unwürdig deshalb, weil das nur zugunsten anderer Systeme geschah und an den Anwendern vorbei.
Hohes Ross: Lese bitte die Mailinglisten.
Und inwiefern geht TV in Richtung der Anwender?
Es ist aufwändig, unverständlich, unnötig kompliziert extrem fehleranfällig und damit teuer. Darüberhinaus brauchst du einen TV Experten wenn du was anpassen willst. Es ist nunmal nicht gut. Da gibts auch außerhalb von TYPO3 viel besseres.
Gut, das ist deine Meinung, ich will sie dir nicht ausreden. Nach meiner Meinung ist sie falsch und zwar in allen von dir genannten Punkten. Ich beende diese Diskussion jetzt, weil mir das vorkommt wie ein Ping-Pong Spiel. Die Behauptung etwas sei „nicht gut“ ist objektiv nicht zu widerlegen.
Achso und sorry wenn es wie eine Unterstellung angekommen ist. Man beachte das Wörtchen WENN am Anfang des Satzes.
Also ich muss sagen, dass ich Dieter’s Argumentation sehr gut nachvollziehen kann. Ich arbeite sicherlich seit 8 Jahren mit TYPO3, bin kein Profi, aber auch kein Newbie… Die pi-based Extensions in Verbindung mit dem Kickstarter waren immer eine tolle Möglichkeit, Kundenwünsche schnell und effizient zu erfüllen. Ich habe mir einige Tutorials zum Extbase und Fluid angesehen. Ohne dass ich mich gegen neue Entwicklungen oder die Notwenigkeit, mich in neue Gebiete einzuarbeiten verwehre, kann ich für mich bisher keinen Vorteil an der „modernen“ Extension-Entwicklung erkennen. Erst gestern habe ich mir ein Tutorial angesehen, wie man fe_users um einen Flag erweitern kann und diesen in der Extension auslesen… Ich glaube es waren davon 6 Dateien betroffen und und es mussten zwei Klassen erstellt werden… und das ist ein Fortschritt? Früher waren das im Frontend-Plugin vielleicht 5 Zeilen Code und wenn ich die DBAL und die Template-Mechanismen des cObj verwendet habe, ist das m.E. doch für andere Entwickler auch nachvollziehbar, oder?
Das Templating ist auch so eine Sache… Sicherlich ist die Kombination Extbase/Fluid aus informatischer Sicht sauberer und verfolgt wohl strikter das MVC Pattern. Aber das ist ja nicht das einzige Argument bei der Diskussion um Ansätze. Ich denke, der wirtschaftliche Faktor sollte nicht vernachlässigt werden und der hängt nun mal oft von effizienten Workflows ab. Und den Workflow des Templating mit den cObj-Funktionen habe ich immer geliebt: Ich erstelle eine HTML-Datei, Style das Ganze ein bisschen, packe ein paar Marker und Subparts rein und fertig… Ich kann dem Kunden ein Layout zeigen und dann 1:1 verwenden, ohne es danach in x Teile zu zerpflücken und dann in x Ordner aufzuteilen, um diese Teile dann mit x Funktionen dann im Plugin wieder zusammenzufügen. Und… wie gesagt… Ich bin kein Experte, aber ich frage mich, ob es performanter ist, auf einem Server auf 10 Dateien mit je 5 Zeilen Code zuzugreifen oder eine große Datei zu laden und ein paar String-Operationen mehr zu verwenden…
Da hast Du den Nagel auf den Kopf getroffen. Die oben genannten Aspekte sind dafür verantwortlich, dass wir für kleine und mittlere Projekte nunmehr concrete5 oder eben Drupal (je nach Kundenwunsch) verwenden. Es ist wirtschaftlich ein Unding, wenn ich einen ausgebildeten TYPO3-Spezialisten brauche, um eine bestehende Extension um ein Datenbankfeld zu erweitern.
Leider Gottes scheint genau das wohl gewollt zu sein. Der Schornstein muss ja rauchen… Warten wir es ab, was das Release von Version 6.2 Ende März bringen wird.
Das sind die Kommentare, die ich liebe. Man baut sich ein Konstrukt aus Unterstellungen und darum herum argumentiert man dann. Selbstverständlich anonym, damit man nichts weiss und nicht dagegen halten kann. Aber sei’s drum, der Kommentar zeigt sehr schön, was es mit der vielbeschworenen „great Community“ wirklich auf sich hat. :)
Weil man damit keine Webseiten machen kann. Ansonsten ist das für zeitkritische Anwendungen gar keine schlechte Idee.
Es geht nicht darum, dass ich sie nicht verstehe oder mich „verschließe“, Mr. Stefanowitsch, sondern dass ich mich weigere, sie unter denjenigen Umständen unter denen sie entstanden sind, anzunehmen. Ich habe nicht das Problem, dass ich nicht etwas Neues lernen will, bzw. nicht weiss, dass zuweilen Paradigmen-Änderungen notwendig sind, sondern ich bin einfach auf der Suche nach einem anderen CMS, weil ich mich mit TYPO3 nicht mehr wohlfühle. Dein Kommentar ist auch nicht gerade geeignet, mich vom Gegenteil zu überzeugen. Denn wer so „argumentiert“, zeigt lediglich, dass er keine mehr hat. :)
Du musst das ja wissen. :) Kannst Du vielleicht einmal Deine Referenz-Liste posten? Dann werden wir ja sehen, wer den „Längsten“ hat.
Es freut mich, dass ich einen Kommentar beisteuern konnte, den du „liebst“. Das dies anonym geschehen ist, war nicht meine Absicht, darum nun auch mit Name und Bild.
Was mir beim Lesen Deiner Posts mit TYPO3 Bezug auffällt, dass Du stets nur anprangerst. Wieviel von dem angesprochenen Betrag, der zur Finanzierung von Flow/Neos rumgeistert hast Du dazu beigesteuert? Du tust so, als hättest Du für eine Leistung bezahlt, die Dir die TYPO3 Community nun schuldig sei. (Um es mal vorweg zu nehmen: Ich bin kein Assocmember, aber ich schreib auch keine Artikel darüber wie schlecht alles ist).
Wärend Du mir oben vorwirfst ich „baue ein Konstrukt aus Unterstellungen“, sind Deine gänzlichen Beiträge auf diesem Prinzip aufgebaut. Kostprobe? Aus der (wohl zutreffenden) Behauptung, dass der Kickstarter für 6.x nicht mehr funktioniert konstruierst Du, das PI Extensions für 6.x nicht mehr laufen würden.
Du unterstellst, dass „PHP-Puristen und OOP-Freaks“ entschieden hätten, dass XML in Datenbanken „ab sofort pfui! zu sein hat“.
Das das weder was mit PHP noch mit OOP zu tun hat – Schwamm drüber. Das das jedoch von schlechten Datenbankdesign zeugt, lernt man in der 2. Datenbankvorlesung und ist auch nicht unbedingt so eine neue Erkenntnis [1].
„Inspire people to share“ oder wie Adi [2] immer sagte „Mach mit, machs nach, machs besser“ ist das Credo. Jetzt könnte ich Dir natürlich vorhalten, dass Du den Fehler, welcher beim Speichern der Extension in 6.x auftritt, selbst (oder einer Deiner Entwickler) beheben kannst (das würde ich machen anstelle ellenlange Posts zu schreiben, wenn ich davon betroffen wäre). Du könntest ihn zumindest reporten. Ich habe von Dir nix gefunden. Keinen Hinweis auf den von Dir verlinkten Issuereport, noch einen neuen Eintrag. Wie soll der Entwickler davon wissen? Vielleicht funktioniert es bei ihm.
Das ist das Beste was ich seit langem gehört habe. Wo jetzt der Unterschied zu „verschließen“ und „weigern“ sein soll, müsstest Du mir nochmal näher erklären.
Was sind denn die Umstände von denen Du sprichst? Welche Umstände wären denn besser geeignet gewesen? Unter welchen Umständen ist Concrete5 entstanden?
Das Fazit ist also:
1) Du verweigest Dich Flow/Neos/Extbase/Fluid aus Prinzip
2) Die TYPO3 Community soll erstmal ihre Hausaufgaben machen und Dir ein CMS bieten, dass so läuft wie 4.2 oder 4.5 oder … naja wie früher halt. Da war doch alles besser
3) Bis das soweit ist schaust Du Dich mal nach anderen CMSystem um und setzt Dich dann wieder ins gemachte Nest falls es mit Neos doch noch was wird
4) Bloggst Du aus sicherer Entfernung (Wortspiel) über die Unzulänglichkeiten von TYPO3
[1] http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)
[2] http://de.wikipedia.org/wiki/Gerhard_Adolph
Ich weiss es nicht, war aber eine ganze Weile, als ich noch in Deutschland war, Mitglied der T3A. Ich würde es auch wieder werden, wenn etwas geschähe, was ich mittragen möchte. Das ist wie dem Kaninchenzüchter-Verein, wem die Kaninchen, die dort gezüchtet werden nicht mehr gefallen, der tritt aus. Überdies muss man nicht für etwas bezahlt haben, um es kritisieren zu dürfen. Dann dürfte man auch keine Linux-Distros mehr kritisieren… Wird aber trotzdem ständig gemacht, und mit Recht. Dadurch werden sie nämlich besser.
Ich bin doch bei Dir. Aber ich habe TemplaVoila nicht entwickelt. Ich wende es nur an. Und es funktioniert prima, für mich und viele andere. Und es wurde als „futuristic Template Building“ jahrelang angepriesen. Heute ist es in der Tat „pfui“. Die Gründe dafür haben, vorsichtig ausgedrückt, nicht nur mit Datenbankdesign zu tun. :) Wie speichern Flexforms nochmal ihre Daten? Ich glaube, das ist XML in einem Datenbankfeld. Ist das so?
Gerne. Wer sich verschließt, möchte auf immer und ewig seinen alter Trott weiter machen. Wer sich weigert, eine bestimmte Sache anzunehmen, der handelt aus irgendeinem Grund. Bei mir ist das im Falle von Neos/extBase/fluid & Co. die Tatsache, dass es von hinten durch die kalte Küche eingeführt wurde, unter Ausschüttung erheblicher finanzieller Mittel, ohne dass das von Anfang an so geplant war. Du kennst doch sicher das Berlin Manifest von 2008. Schau mal, wer da alles „unterschrieben“ hat.
http://typo3.org/roadmap/berlin-manifesto/
Ich verschließe mich aber Neuerungen nicht. Ich suche sie ja geradezu. Und vor allen Dingen möchte ich sie mir aussuchen dürfen, aber nicht bejubeln müssen, was mir grade vorgesetzt wird.
Diese oben genannten finanziellen Mittel fehlten jahrelang aber bei der Weiterentwicklung von TYPO3 (oder jetzt Version 6 oder TYPO3 CMS). Das besagte Kaninchen (TYPO3 CMS) starrte nur ständig den Wolf (Neos) an und implementierte alles, was von dort kam via Backport. Ob das nun so dolle ist? Ich weiss nicht so recht.
Soweit ich weiß unter den selben, wie einst TYPO3: Jemand hat es programmiert und veröffentlicht. Dieser Jemand hat bei concrete5 heute noch die Fäden in der Hand, bei TYPO3 nicht mehr. Auch das sehe ich als ein Problem an.
Die grundlegende Technologie ist ja da, das war, was ich meinte.
Naja, als Flow in die heiße Phase kam, hatten alle anderen leider schon Jahre, um das bei sich einzubauen.
Und wenn man sich anguckt, was Zend und Symfony so unter DI verstehen… das ist ja auch eher ne Konfigurationsorgie.
Und AOP… geht so mit dem Support, ne?
Über das Geld müssen wir nicht (mehr) sprechen.
Aber da ist vorher auch genug ausgegeben worden für Dinge, zu denen es bis heute kein Ergebnis gibt.
Das war falsch und es ist reagiert worden.
Wenn wir jetzt nachtragend sind, bringt das niemanden weiter.
Ich gebe Dir insofern Recht, als dass ausschliesslich Mitglieder der T3A das Recht haben, von dieser bestimmte Verhaltensweisen hinsichtlich der Budgetpolitik zu fordern.
Andererseits ist es aber auch so, dass die Dokumente bzgl. der Budgetvergabe ja nicht „geleakt“ wurden, sondern dass sie öffentlich einsehbar sind. Insofern muss es auch der Öffentlichkeit gestattet sein, die Budgetvergabe in manchen Punkten unfair finden zu dürfen. Nichts anderes tue ich und nicht anderes geschieht jeden Tag in Politik oder Wirtschaft: Der Jetzt-Zustand muss auch nach den Kriterien beurteilt werden, die zu eben diesem Zustand geführt haben, erst dann kann man den Status Quo beurteilen und der Zweck heiligt nicht automatisch alle Mittel.
Was TYPO3 CMS von der Neos-Entwicklung „geerbt“ hat, ist extBase, FLOW und Fluid. Alle drei sind Dinge, auf die ich persönlich gut verzichten kann, weil es zahlreiche Alternativen gibt. Folglich bin ich eben der Meinung, dass das Geld anderswo besser investiert hätte werden können. Diese Meinung muss erlaubt sein, insbesondere vor dem Hintergrund, dass die Entwicklung eines neuen CMS samt PHP-Framework von Anfang an ja so gar nicht geplant war.
Ich habe mich da unglücklich ausgedrückt.
Was ich meine ist:
Über das Geld, dass dort ungeprüft geflossen ist, müssen wir nicht mehr sprechen – da ist klar, dass das nicht in Ordnung war.
Wie gesagt: Die Meinung ist erlaubt, in meinen Augen teilweise richtig und soll auch nicht unterbunden werden.
Die T3A verteilt die Gelder jetzt aber anders, was ja Wunsch der Community war.
Die Budgets gehen massiv zugunsten CMS, was vorher nicht so war.
Nur als Tip und nicht als Schelte… Fluid solltest du dir auf jeden Fall angucken.
Als Standalone View, nicht mal zwingend in Verbindung mit Extbase.
Meiner Meinung nach ist das deutlich besser als unsere ###MARKER### Geschichte.
Wenn du Fluid als Templating Engine für die Website an sich nicht nutzen willst, ist das ja auch ok, da machst du ja ohnehin viel mit TV.
Aber ganz im Ernst… Extension-Ausgabe via substituteMarkerArray? Come on :)
Es tut, was es tun soll. Das Ergebnis ist immer HTML. Wir sind keine Code-Junkies, sondern Leute, die Webseiten für Kunden erstellen. Und da spielt, so schade das auch ist, oft auch der Preis eine Rolle. Vielen Kunden ist es schlicht wurscht, ob substituteMarkerArrayCached() verwendet wird oder Code, der für manche offenbar einen feuchten Traum darstellt.
Kurz, wir sind Leute, die auch einmal fertig werden und Feierabend machen wollen, daraussen scheint die Sonne und es hat 33 Grad… Und wenn ich ein Team habe, das mit substituteMarkerArrayCached() vorzeig- und verkaufbare Resultate liefert, dann werde ich den Teufel tun und denen sagen, dass das jetzt Schnee von gestern zu sein hat, nur damit anschliessend R.L. genug Geld verdient um dorthin zu fliegen, wo ich schon bin: An die Sonne und an den Strand. :) So, das musste jetzt auch mal sein.
Auch ich sehe die Verschiebung des Release-Termins positiv, das habe ich ja auch geschrieben. Weil es die Chance in sich birgt, eine absolut stabile und performante Version vorzustellen. Jeder, der TYPO3 noch irgendwie gewogen ist, wird es als positive Nachricht sehen, das ist klar. Aber es gibt eben auch andere… Insbesondere Kunden, denen ich TYPO3 empfohlen habe, die es abgelehnt haben und sich für etwas anderes entschieden haben, sehen sich jetzt bestätigt. Die gehen nicht in die Tiefe, die nehmen die Argumente, die für eine Verschiebung sprechen, nicht wahr, nein sie wollen sie erst gar nicht hören. Sie sagen nur „sehen Sie, hatten wir doch Recht mit unserer Entscheidung gegen TYPO3“ – und deshalb ist die Verschiebung eben auch gleichzeitig eine nicht so gute Nachricht.
Naja, also Fluid funktioniert bei uns intern sehr gut, weil wir den „reinen“ HTML Generierer nicht haben.
D.h. die Erstellung von Grids geht sehr schnell vor sich.
Der Benefit von Extbase (und nein, ich nutze das auch nicht) kommt dann zum tragen, wenn du ein Team hast, in dem die Leute öfter mal fremden Code in die Finger bekommen.
D.h. durch die starken Konventionen gibt es in gewissen Bahnen den Weg vor.
Das nervt im ersten Moment, aber im zweiten stellt man fest, dass man fremden Code innerhalb von 2min vollständig kapiert.
Jetzt schlagen wir die Brücke zur Anpassung des Cores.
Der Core ist ein sehr komplexes Feld aus Legacy Code (aber datt ging doch immer) und neuen Entwicklungen (mimimi, ich will aber Feature X).
Ab einer bestimmten Stelle passt das einfach nicht mehr zusammen.
Zum Thema „ewig gestriger“…
Ich weiß nicht, ob das der richtige Begriff ist, aber wirklich innovativ ist das Festhalten an altbekanntem ja auch nicht, oder was meinst du?
Da müssen wir alle gemeinsam eine Balance finden.
Abgesehen davon… alle Punkte, die du hier ansprichst, sind genau die Punkte, die wir lösen wollen.
Du siehst… wir haben durchaus gehört, was du sagst und setzen das auch um.
Aber lass uns mal was anderes machen…
Im Moment treffen hier immer wieder viele Emotionen auf einander, das führt zu Mißverständnis, Frontenbildung… wollen wir alle ja nicht, hoffe ich doch.
Mach dich mal frei von allem und stell dir vor, du hättest unlimitierte Ressourcen.
Was brauchst du für deinen Markt?
TV, das haben wir soweit verstanden.
Dann möchtest du, dass der Kickstarter wieder funktioniert.
Soweit glaube ich, das verstanden zu haben.
Was brauchst du noch?
Einfach mal sachlich runterschreiben, ohne „es muss doch klar sein, dass…“
Punkt ist: piBase funktioniert hervorragend.
Aber nicht „ohne Änderung“.
Ich glaube, hier ist insgesamt in der Kommunikation noch nicht eindeutig genug klar geworden, dass die Idee ist, dass man Extensions auch ohne Extbase machen kann, diese werden landläufig als piBase beschrieben.
Das stimmt inhaltlich aber nicht so ganz.
Weil plugin.meineExt = USER geht immer – so arbeitet nämlich auch Extbase :)
I have a dream: Neuerungen müssen sein, zuweilen gehen sie mit Inkompatibilitäten einher, no problem. Wenn es zu diesen kommt, steht irgendwo ein Artikel, eine Beschreibung oder ähnliches, wie man diese umschiffen kann, damit man seine gewohnten Werkzeuge weiter einsetzen kann, wenn man das will. Gleichzeitig kann man neue Systeme, Paradigmen und Herangehensweisen etablieren, die als Alternativen zum Althergebrachten dienen. Peu a peu überzeugt man die Community, dass das Neue besser ist und so löst es das alte langsam ab.
Aber ich möchte eine Wahl haben! Bei der Holzhammer-Methode, dass ich nämlich etwas so oder so zu machen habe, ansonsten sei ich eine Innovationsbremse, reagiere ich allergisch. Es war doch schon immer so, dass es Alternativen gab, bei TYPO3, die friedlich koexistiert haben und es für alles einen Kreis von Anwendern gab. Warum soll das nun vorbei sein? Weshalb ist jetzt nur noch fluid/extbase/flow3 das Himmelreich?
Vergleiche TYPO3 mit Ubuntu. Die Community hat nicht akzeptiert, dass es künftig nur noch einen Desktop geben soll, nämlich Unity und Canocical musste schmerzlich erfahren, dass die Leute, wenn sie Unity verwenden müssen sie sich lieber von Ubuntu insgesamt abwenden, als das zu akzeptieren. Man muss eine Wahl haben, um sonst geht es nichts, dann ist man viel eher bereit, neue Dinge zu akzeptieren und mitzutragen.
Beim I have a dream Teil sind wir uns dann ja einig.
Extbase tut’s jetzt seit… puh… 6 Jahren? Also viel Zeit, sich damit auseinander zu setzen.
Beim Teil „Wahl haben“:
Du übersiehst da ein paar Dinge.
Der Kickstarter muss gepatched werden, ja.
Extbase als einzige Lösung? Stimmt schlichtweg nicht.
Zumal ich offen gestanden das Problem überhaupt nicht verstehe, dass du da hast.
Du hast doch TYPO3 Profis bei dir am Start, die wissen doch, was das cObject USER tut.
Und Extbase ist ein cObject USER und piBase auf.
Und wir nutzen schon seit 10 Jahren ein „pibase“ mehr, also aus Zeiten, wo es Extbase noch nicht mal auf dem Papier gab.
Wo ich dir Recht gebe: Der Focus der Core Entwickler lag eher auf Flow, weil das ist einfach Developer Porn :)
Ich meine das hier auch nicht schnippisch oder so, aber da drauf müssten deine Jungs eigentlich total abgehen, weil es wirklich Spaß macht… also Spaß Spaß :)
Du siehst: Der ganze Fehler, über den du dich zurecht ärgerst, liegt nur darin, dass der Kickstarter nicht mehr läuft.
Den hat Kasper in einer Woche runtergeschrieben, d.h. den kann jeder andere auch in ner Woche runterschreiben.
Unterschied zu vorher: Jetzt kannst du ihn testen und so verbessern, ohne Bestehendes einzureissen.
Ich halte es nicht für ein Problem, dir den Extension Key „kickstarter“ zu übertragen – der ist ja nicht Teil des Core und war es auch noch nie.
Mit deinen PHP Jungs kannst du das Ding ruck zuck grade ziehen und genau deinen Traum erfüllen.
Damit wäre doch allen geholfen.
Jeder andere sicher nicht, aber ich weiss, was Du meinst. Um so mehr verstehe ich nicht, dass so ein Bug unbeachtet 8 Monate lang vor sich hin schimmelt. Ja, ich weiss, und ja Du hast recht, auch ich könnte was tun. Nur darum alleine geht es halt leider nicht. Auch ich bin weisungsgebunden und muss mich fragen lassen, weshalb ich ein System verwenden will, das Probleme hat, die es bei anderen Systemen so einfach nicht gibt.
Das tun wir ja auch, es ist ja nicht so, dass wir uns nicht zu helfen wüssten. Meinen Traum erfüllt das trotzdem nicht. Der ist nämlich, dass es bei TYPO3 wieder so wird, wie es einmal war. Dass man nämlich Alternativen hat, die alle funktionieren, weiter entwickelt werden und von denen man sich das für die jeweilige Aufgabe am besten geeignete heraussuchen kann. Das ist aber leider nicht mehr so, ich wünschte, es wäre anders. Es geht mir ausdrücklich nicht um die ewige Beibehaltung von alten Zöpfen, die können ruhig abgeschnitten werden. Aber bitte erst dann, wenn anderswo genug Haare nachgewachsen sind…
> Jeder andere sicher nicht, aber ich weiss, was Du meinst. Um so mehr verstehe ich
> nicht, dass so ein Bug unbeachtet 8 Monate lang vor sich hin schimmelt.
Du, das ist schnell erklärt.
Was würdest du höher priorisieren?
Ein Kickstarter, der es nicht tut oder das Problem, dass sobald du in Workspaces wechselst, alle Bildreferenzen verloren gehen?
Nichts desto trotz:
Die große Herausforderung beim Kickstarter war damals, das KONZEPT auf die Beine zu stellen.
Das Ding jetzt neu zu schreiben kann jeder, der PHP kann.
Das ist nichts anderes, als Bausteine in eine Datei kopieren.
> Ja, ich weiss, und ja Du hast recht, auch ich könnte was tun. Nur darum
> alleine geht es halt leider nicht. Auch ich bin weisungsgebunden und muss
> mich fragen lassen, weshalb ich ein System verwenden will, das Probleme hat,
> die es bei anderen Systemen so einfach nicht gibt.
Weil diese eine System seit 13 Jahren erfolgreich am Markt ist und bisher jeder Neuerung eigentlich recht locker getrotzt hat.
Flash durch HTML ersetzen? Lächerlich.
Bilder rendern? Peanuts.
Accessibility Guidelines (die sind hier gesetzlich vorgeschrieben)? Kein Thema.
Responsives Webdesign? Machste so und so.
Wenn wir alle mal ehrlich sind, jammern wir (ja, auch ich) eigentlich auf EXTREM hohem Niveau :)
> Das tun wir ja auch, es ist ja nicht so, dass wir uns nicht zu helfen wüssten.
> Meinen Traum erfüllt das trotzdem nicht. Der ist nämlich, dass es bei TYPO3
> wieder so wird, wie es einmal war. Dass man nämlich Alternativen hat, die alle funktionieren,
> weiter entwickelt werden und von denen man sich das für die jeweilige Aufgabe am besten
> geeignete heraussuchen kann.
Das verstehe ich alles.
Aber wenn jemand Extension X nicht weiterentwickelt, kann ich dem doch nicht die Knarre an den Kopf halten und sagen „los, sonst….“
> Das ist aber leider nicht mehr so, ich wünschte, es wäre anders. Es geht mir
> ausdrücklich nicht um die ewige Beibehaltung von alten Zöpfen, die können ruhig
> abgeschnitten werden. Aber bitte erst dann, wenn anderswo genug Haare nachgewachsen
> sind…
Du steckst im Core nicht wirklich drin, oder?
Kernfunktionalität ist nicht weg.
Alle Kernkonzepte sind noch da.
Es sind die Extensionentwickler, die nicht nachkommen und ihre Hausaufgaben nicht machen.
Streng genommen müßte man ja eigentlich nichts machen.
Lass uns ne 4.5 durch nen Audit schicken, das kostet einmal 75000 Euro und du hast alles am Start und brauchst auch keine Patches mehr, weil das Ding dann Rock Solid ist.
Auch ein kleiner Ausflug in die „man muss das alles erst lernen“ Ecke.
Die Schulungszeit für TYPO3 Flow beträgt bei uns einen Tag.
Danach rafft das jeder Dev bei uns.
Und weißt du, was RICHTIG Spaß macht?
Die brauchen 1/3 der Zeit und du musst dir keine Gedanken machen, ob dein Junior wieder ne Sicherheitslücke gerissen hat.
Ich hab LANGE…. wirklich lange gebraucht, das zu begreifen, was die Jungs da vor hatten.
Siehe dazu auch meine wirklich bösen Posts (dagegen bist du hier ja n Lämmchen :)) in der Vergangenheit.
Aber bei mir hat’s irgendwann klick gemacht und jetzt bin ich extrem guter Dinge.
Aktuell liegt das Problem in der fehlenden Motivation.
Alle stellen sich hin und sagen „ach, is doch scheisse, macht keinen Spaß mehr“.
Es ist unsere Aufgabe (explizit Deine und meine) diesen Blocker aufzuheben.
Details gerne via Skype (mathias.schreiber)
Und erklär mir mal bei gelegenheit, die man hier hübsch zitiert :)
Die Workspaces natürlich. Allerdings hätte ich, sorry dass ich das sage, Mehrsprachigkeit und Workspaces von Anfang an Top-Priorität eingeräumt. Dass man das so en passant kurz vor dem Release noch auf der Agenda hat, ist ja schon wieder ein neues Problem.
Es gälte herauszufinden warum manche Extension-Developer offenbar die Lust verloren haben. Wenigstens sollte man diese Extensions dann auch gnadenlos rausschmeissen. Was helfen mir über 6000 Extensions unter 6.x wenn nur ein Bruchteil davon überhaupt installiert werden kann? Wenn sie nicht installiert werden können, warum werden sie dann angezeigt, in einem System worunter sie gar nicht laufen können? Wenn man ausschließen kann, dass sie installiert werden, dann könnte man auch ganz einfach ausschließen, dass sie überhaupt angezeigt werden. Da fällt mir schon wieder der Spruch „das wäre Ihr Preis gewesen“ ein. :)
Ich für meine Person bin mit Feuereifer wieder dabei, wenn ich mich mit dem System wieder identifizieren kann, wenn ich mich darin wiederfinde. Das wird wohl bei FLOW3 nie der Fall sein, weil es, nach meiner Meinung, schlicht unnötig war, das überhaupt zu entwickeln. Das Geld wäre an anderen Stellen besser investiert gewesen, dann hätten wir viele Probleme heute gar nicht. Das Rad immer neu erfinden zu wollen, hat in der Software-Industrie noch nie zum großen Erfolg geführt.
Ganz normal mit blockquote. Keine Ahnung, warum der Disqus Editor die Möglichkeiten nicht anzeigt. Man kann aber etliche HTML-Tags verwenden.
http://help.disqus.com/customer/portal/articles/466253-what-html-tags-are-allowed-within-comments
Kickstarter und TV sind einfach 2 extensions. Wenn diese nicht kompatibel sind, bitte tu dich mit den jeweiligen Autoren zusammen
Erstens ist TV kompatibel, was anderes schreibe ich auch nicht. Mich stört nur, dass man sich dauernd „Grab-Gesänge“ über TV anhören muss, obwohl es prima funktioniert. Zweitens sehe ich TYPO3 als Gesamt-System an, bei dem bisher der Kickstarter ein wesentlicher Teil war, und wobei von offizieller Seite behauptet wird, dass es um einen Mythos handle, dass piBase in 6.x nicht mehr unterstützt werde. Und schließlich habe ich mich in der Tat mit diversen Autoren bereits „zusammen getan“. Nur nicht mit denen von TV, Kickstarter oder TYPO3 generell, sondern eher mit anderen…
Natürlich wird pibase noch unterstützt, das heißt jedoch nicht dass man nicht alle paar Jahre ein paar Zeilen anpassen muss. Wenn du deinen fatal error genauer beschreibst, wird man den sicherlich auch beheben können.
Das mit den „paar Zeilen anpassen, alle paar Jahre“ lasse ich jetzt einfach mal so stehen. :)
Es gibt einen Patch von Stefan Neufeind (danke dafür), der Bug ist 11 Monate alt und wurde zuletzt vor 8 Monaten aktualisiert. Er hat den Status „Accepted“ und die Priority „Must have“
http://forge.typo3.org/issues/44223
Wendet man ihn an, klappt’s wie beschrieben, nur dass man die Extension nicht auf die Platte schreiben kann. Der fatal Error, nämlich
„PHP Fatal error: Call to undefined method stdClass::importAsType() in
/var/lib/typo3-sites/dummy-6.0.4/typo3conf/ext/kickstarter/class.tx_kickstarter_wizard.php“
wurde bereits vor 8 Monaten von Søren Bryder in eben diesen Bug reingeschrieben. Glaubst Du wirklich, dass es etwas helfen würde, wenn ich das nun wiederholen würde? Also, ich glaub‘ nicht daran. Eher behebe ich den Fehler… Oder ich mache das Grundgerüst der Extension eben mit 4.5