01. August 2013

Wohin geht die Reise?

in ExtBase/Fluid, Extension, Flow, TYPO3

Hallo TYPO3-Freunde,

schon einmal ein TYPO3 4.5 und ein frisches TYPO3 6.2 aufgesetzt? Die Standardseite im Backend ist für gewöhnlich die „About Modules“ und schaut bis auf ein paar Abständen zwischen Texten, Links und Icons exakt gleich aus. Zwischen diesen beiden Versionen liegen nun 2,5 Jahre und natürlich stellt sich Einigen die Frage: „Was ist passiert?“ oder „Wo soll die Reise eigentlich hingehen“ oder noch krasser: „Wo sind die Features, die sonst mit den neuen Versionen heraus gekommen sind?“

Die Features sind unter der Haube

Ich kann Fans und andere TYPO3-Begeisterte auf jeden Fall verstehen, wenn sie ständig die neue Version von TYPO3 einspielen und kaum Neues zu Gesicht bekommen. TYPO3 arbeitet an vielen Stellen immer noch auf einer Codebasis, die uralt ist. Seit Ewigkeiten schleppt TYPO3 diese Senioren mit sich und es wird endlich Zeit, diese an moderne/zeitgerechte Programmierungen anzupassen. Nicht selten steht man als Entwickler vor Dateien, die länger als 7000 Zeilen lang sind. Mit der IDE Eclipse hatte ich bei einigen dieser Dateien sogar Darstellungsfehler beim Syntaxhighlightning. Kapselung muss wohl ein Fremdwort gewesen sein. Viele dieser Dateien wurden bereits überarbeitet und mit jeder neuen TYPO3-Version wurden weitere Dateien in mehrere kleine Dateien aufgesplittet und falls erforderlich die Anzahl der Zeilen innerhalb von Methoden verringert. Dies steigert die Übersichtlichkeit erheblich und hilft dabei Fehler schneller zu finden. Die Wartung wird also erheblich verbessert.

Nun könnt Ihr Euch bestimmt vorstellen, dass TYPO3 nicht gerade klein ist. Hey…Kasper hat 10 Jahre seines Lebens in dieses System gesteckt, da kann man nicht erwarten, dass das Core-Team diese Leistung „mal eben“ in 2-3 Jahren komplett neu schreibt und zusätzlich auch noch neue Features für TYPO3 einbaut. Dann kommt auch noch hinzu, dass das Core-Team immer ein gewissen Maß an Rückwärtskompatibilität gewährleisten muss.

Und trotzdem: Auf dem 6.2 LTS Kick-Off Meeting wurde auch ein neues Design für TYPO3 angesprochen. Wenn ich richtig informiert bin, dann soll das neue Backend auch Tablet tauglich werden. Smartphones werden allerdings nicht unterstützt.

Der Wechsel zu 6.2

TYPO3 6.2 wird wie schon damals die 4.5er Version wieder eine LTS (long time support) werden und wird im Oktober diesen Jahres veröffentlicht. Um den Kunden Zeit zum Wechseln zu ermöglichen, werden sich die LTS-Versionen immer um ein halbes Jahr überlappen. Das ist auch der Grund, warum die 4.5er LTS-Version um ein halbes Jahr verlängert wurde. Wer mal versucht hat übergreifend für alle TYPO3-Versionen eine Extension zu schreiben, wird wissen, was das für eine Qual ist. Aber TYPO3 will hier Abhilfe schaffen. „Smooth Migration“ heißt das Zauberwort. Eine zusätzliche Extension für TYPO3 4.5 soll dem Kunden/Entwickler dabei helfen auf bestimmte Probleme und bekannte Fehlerquellen hinweisen. Zusätzlich wird es eine Migrations-Checkliste geben, mit der alle zu tätigenden Arbeiten abgehakt werden können. Auf diese Weise kann eine ganz bestimmte Reihenfolge eingehalten werden und wichtige Zwischenschritte werden nicht vergessen. Und wenn alle Stricke reißen, könnte es auch eine Extension geben, die auf TYPO3 6.2 installiert wird, um alte Extensions dennoch auf der 6.2er Version zum Laufen zu bringen.

Wohin geht die Reise?

Auf dem TYPO3 Camp in Stuttgart habe ich an einer Session von Benni Mack teil genommen und konnte Ihn als Release Manager der 6.1er Version mal fragen, warum man sich für Namespacings entschieden hat. In erster Linie geht es darum, um in Sync mit TYPO3 Flow zu sein. Je ähnlicher sich diese beiden Produkte sind, desto einfacher ist es TYPO3 Flow in TYPO3 CMS zu implementieren. Es ist noch nicht klar welche Versionsnummer nach der 6.2 kommen wird. Aber in der 6.3 bzw. 7.0 will man versuchen Flow in den TYPO3-Core zu implementieren. Da die Pakete von Flow auf Composer arbeiten wird es ein eigenes Extensionverzeichnis für Flow basierte Extensions geben: typo3conf/packages/ während die piBase und Extbase-Extensions weiterhin im Verzeichnis typo3conf/ext/ liegen werden. Innerhalb des neuen Verzeichnisses wird dann die Struktur der Namespaces kontinuierlich eingehalten, was dann auch eine saubere Differenzierung zwischen den Vendors ermöglicht. Bisher wird der Vendorname aus dem Namespacing jedoch noch nicht ausgelesen. Heißt: Wenn Firma1 und Firma2 eine Extension mit dem Namen „shop“ erstellen, kann man diese beiden Extensions nicht parallel in TYPO3 installieren und das, obwohl sie sich in einem völlig anderen Namespace befinden. Dank Composer (dem Paketmanager) stellt sich auch die Frage, ob man damit die ext_emconf.php ablösen kann. Evtl. wird bereits für Extensions in der 6.2er Version schon die Möglichkeit für Composer gegeben sein. Aber das bleibt noch abzuwarten.

Die Reise geht also stark in Richtung TYPO3 Flow. Dank Extbase werden Extensions bereits jetzt schon immer Flow ähnlicher und Dank der Namespaces wird auch der Core immer Flow ähnlicher. Bereits in der aktuellen TYPO3 6.2 (GIT-Version) wurden alle Dateien aus dem t3lib-Verzeichnis verbannt und in eigene Verzeichnisse innerhalb des TYPO3-Cores verschoben und auch hier wieder im Namespacing erfasst. Zur Veröffentlichung wird es dieses Verzeichnis also nicht mehr geben. Evtl. wird es in weiter Zukunft keine Extensions mehr geben, sondern alles nur noch über Composer und Pakete gesteuert. Auch Abhängigkeiten zu anderen Paketen können mit diesem neuen System verwaltet werden.

Mein persönliches Fazit

Viele Entscheidungen von TYPO3 werden intern kommuniziert oder eher Häppchenweise an die Öffentlichkeit getragen. Ich oder evtl. auch Du sehen diese Entscheidungen nicht als Ganzes. Da kommen auf einmal Namespaces und das warum wird mit „Ja…ist in Flow auch so und wir übernehmen es halt“ beantwortet. Cool fand ich auch die Antwort: „Weil das Feld für den render_type nur 255 Zeichen lang ist“. Au man…

Es gibt die News, dass TYPO3 Flow nun ein eigenständiges Produkt wird. Dann kommt Neos, dessen Basis dieses Flow sein wird. Ich kann mich nicht erinnern jemals eine News gelesen zu haben in der es heißt, dass es Flow als Paket (oder wie auch immer) in TYPO3 CMS integriert werden soll.

Viele solcher News haben meiner Ansicht nach den User eher verwirrt und ich hatte das Gefühl das TYPO3 eher auseinander bricht. Aber nun ist zumindest für mich wieder eine klare Linie zu erkennen. Ich sehe wie die Fäden wieder zusammen geführt werden und diese ganzen News-Brocken als eine Einheit wieder ihren Weg zusammen finden.

Als Programmierer lege ich meine Hoffnung nun auf 6.2, was ich von den Versionen 4.6, 6.0 und 6.1 nicht behaupten konnte.

PS: Nein. Ich habe 4.7 nicht vergessen 🙂

Über rege Meinungen und Kritiken freue ich mich auf jeden Fall.

Stefan

25 Reaktionen zu “Wohin geht die Reise?”

Kommentare abonnieren (RSS) oder TrackBack URL

So ganz stimmt dies nicht.

Die Namespaces wurden schon mit 6.0 eingeführt, zusammen mit FAL (File handling Abstraction Layer). Dabei wurden alle Klassen umbenannt und dabei an passende Orte verschoben.
Dadurch kann man zum ersten mal im TYPO3 Core die Klasse für eine Aufgabe anhand der Namenskonventionen finden und vice-versa.
In 6.2 wurden nur die alten Dummy-Dateien entfernt, sodass Extensions nun den seit 4.3 (!!!) verfügbaren Autoloader zwingend nutzen müssen.

Bzgl. Flow, Neos:
TYPO3 Flow ist ein eigenes Produkt und ganz Framework (im Gegensatz zum CMS, das beides ist). TYPO3 Neos ist ein CMS Aufsatz auf Flow, welcher sich besonders auf verzweigte Datenstrukturen konzentriert (Node-Tree). In CMS gibt es ja nur Pages und Records, in Neos wird es nur noch Nodes, geben, die jedoch auch immer als Elternode (Page in CMS) fungieren können.

In 7.0 soll Flow teilweise in CMS integriert werden. D.h. es sollen insbesondere die redundanten Code Teil durch die richtigen Flow Funktionalitäten ersetzt werden. Dies betrifft insbesondere das Caching-Framwork und Fluid, da dieser Code quasi eine 1:1 Kopie des Flow Codes ist.
Natürlich sollen dann nach und nach weitere Komponenten folgen.
Darüber hinaus kann man dann Flow Pakete (zumindest Code mäßig) in CMS nutzen.
Man könnte dann also TYPO3 Neos zum Frontend Editing verwenden.
So werden die verschiedenen TYPO3 Produkte also zusammenwachsen, wie es ja auch seit dem Berlino Manifesto angeregt wird.

Zuerst kommt jedoch nochmal eine LTS mit erheblichen Verbesserungen des zugrunde liegenden Codes, sodass einer 3-(oder sogar mehr) jährigen Wartung nichts im Wege steht.

Philipp Gampe am 01. August 2013 um 17:52

Wo genau hat er was anderes zu Namespaces geschrieben?

Mathias Schreiber am 02. August 2013 um 00:02

Die zeitliche Abfolge stimmt nicht. Das Namespacing wurde nicht wegen Flow eingeführt. Auch die Struktur ist nicht wegen Flow so, sodern primär MVC.
Außerdem wurden nicht für die 6.2 die Dateien verschoben, sodern schon für die 6.0. In 6.2 wurden nur die Dummy Dateien für alle include(_once) Aufrufe wieder entfernt.

Durch das Namespacing kann man jetzt aber über solche Stunts wie die Flow Integration nachdenken. Dies war vorher einfach unmöglich.
Außerdem ist es jetzt möglich, TYPO3 CMS Code mit anderen Code zu kombinieren, e.g. gleichzeitig Drupal und TYPO3 CMS zu laden um irgendetwas Abgefahrenes zu machen.
Diese Möglichkeit bestannt vor der 6.0 einfach gar nicht.

Philipp Gampe am 02. August 2013 um 13:48

„Und wenn alle Stricke reißen, könnte es auch eine Extension geben, die auf TYPO3 6.2 installiert wird, um alte Extensions dennoch auf der 6.2er Version zum Laufen zu bringen.“

wenn in der aktuellen Alpha2 eine leere Datei unter typo3/sysext/cms/t3lib/
class.tslib_pibase.php angelegt wird, laufen alte Extensions ohne Problem. Ob das jetzt so gewollt ist muss wohl das Core Team entscheiden.

mario am 02. August 2013 um 16:16

@mario: Oder man schmeißt die require(_once) einfach raus. Den Autoloader gibt es ja erst seit 4.3 😉

Philipp Gampe am 03. August 2013 um 00:55

@Philipp das kann man auch machen, aber ein einfaches anlegen ist schneller gemacht als 10 Ext. anzupassen.

Ich sehe das eher als Migration Feature in der 6.2!?

mario am 05. August 2013 um 09:16

Das ist ein Feature 🙂

Die Extensions hätten schon vor fünf Jahren angepasst werden sollen.

Dafür ist t3lib jetzt endgültig Geschichte.

Philipp Gampe am 05. August 2013 um 09:31

Ich verstehe das Paradigma nicht so ganz.
Wortlaut ist ja, dass eine Klasse mit 100 Funktionen unübersichtlich ist.
80 Verzeichnisse mit 80 Klassen, die je eine oder 2 Funktionen haben, soll übersichtlicher sein.

Für mich ist das austäuschig.

Wie aufwändig das letztendlich ist, es umzubauen, wird sich zeigen.
Die wirklich leidtragenden sind leider die, die sich nah am Core aufgehalten haben, API Funktionen genutzt etc.

Und es zeigt sich in der Praxis, dass es sehr schwer bzw. oftmals unmöglich ist, diesen Aufwand für ein Update zu rechtfertigen.

Ich habe Verständnis dafür, dass man da am Code was machen will.
Mein Vorschlag wäre allerdings, sich ab jetzt wieder auf die Aufgabe eines CMS zu konzentrieren:
Probleme von Redakteuren beheben.

Nach meinem Wissensstand war das ja vorher nicht möglich bzw. nicht sinnvoll, da die Codebasis das ja nicht her gab.

Mathias Schreiber am 05. August 2013 um 09:38

Dafür ist t3lib jetzt endgültig Geschichte.
Und das ist ein Vorteil, weil: …. ?

Peter am 05. August 2013 um 16:21

Und das ist ein Vorteil, weil
konnte mir auch keiner beantworten, aber es scheint wichtig zu sein.
Ich selbst hab t3lib_div in bestimmt 50 nicht-TYPO3-Projekten als Swiss Army Knife drin.
Jetzt muss ich das wahrscheinlich in ein Vendor Package packen… also generell mit sowas arbeiten, selbst wenn ich das gar nicht will.
So schaut halt die schöne Freiheit aus.
Auf der anderen Seite sei gesagt, dass WENN man Package basiert entwickeln will (was man sich ja jetzt nicht mehr aussuchen darf, sondern diktiert bekommt), macht das echt Spaß.

Mathias Schreiber am 05. August 2013 um 16:43

„Wortlaut ist ja, dass eine Klasse mit 100 Funktionen unübersichtlich ist. 80 Verzeichnisse mit 80 Klassen, die je eine oder 2 Funktionen haben, soll übersichtlicher sein.“

Ich tippe auf die jeweils präferierte IDE: PHPStorm (und alle JAVA-IDEs) kann wirklich gut mit vielen Ordnern und kleinen Dateien umgehen. Meine alte IDE konnte besser mit großen Dateien mit vielen Funktionen umgehen. Die ist jetzt nicht mehr zeitgemäß … wobei sich für mich die Henne-Ei-Frage stellt: Paradigma oder IDE? 🙂

Wenn ich mir den fileadmin-Ordner des Introduction Package anschaue, so wird eine IDE auch für Integratoren zwingend. Die konsequente Extbase-Schreibweise (Ordner in UpperCamelcase, Dateien in LowerCamelcase) bei TS-Dateien wirkt jedenfalls überzeugend. Dabei könnte man Dateinamen eigentlich weglassen, schließlich heissen fast alle Dateien setup.ts. Bis auf die paar constants.ts natürlich, aber es wäre ja nur konsequent dafür auch noch Ordner einzuführen. Dann könnte man jede Datei einfach nur index.ts nennen.

Das ist schon irgendwie irre:
fileadmin/default/TypoScript/Block/ContentLeft/setup.ts
und darin diese beiden Zeilen Code:
lib.contentleft = COA
lib.contentleft.20 < styles.content.getLeft
Hat was 🙂

Peter am 05. August 2013 um 17:19

@Matthias: t3lib_div ist nicht gleich t3lib. Lag da zwar drin, aber die Funktionen von t3lib_div gibts noch, allerdings in der Klasse GeneralUtility. Ich bin mir nicht 100%ig sicher, aber so weit ich weiß, funktionieren die Aufrufe dieser Methoden nach wie vor, und zwar ohne Änderung, sie werden nur umgelenkt auf die neue Klasse. Was nicht mehr geht, ist das Includieren von Klassen über include() oder require(), aber das musste man ja mit der t3lib_div nicht. Ich meine, bei den meisten Extensions sollte es ausreichen, diese includes durch die Autoload-Funktion zu ersetzen. Probleme werden ber mit deprecated-Methods auftreten, nicht nur mit TYPO3 sondern auch mit PHP 5.4. Da gibts einige Extensions, die deswegen hops gehen.
—
Beispiel tt_news, diese Zeile:
$t3version = t3lib_div::int_from_ver(TYPO3_version);
in der ext_localconf.php
führt zu diesem Fehler im Backend von TYPO3 6.1:
Fatal error: Call to undefined method TYPO3\CMS\Core\Utility\GeneralUtility::int_from_ver() in /Users/peter/Sites/typo3_61/typo3conf/ext/tt_news/ext_localconf.php on line 48
Heißt, dass die richtige Klasse aufgerufen wird, es dort die Methode int_from_ver aber nicht mehr gibt.

Peter am 05. August 2013 um 17:57

schönes Beispiel eigentlich.
Ich hab selbst mit Rupi an diesem „Fehler“ gesessen.
Lösung ist jetzt, dass man (performance-mäßig teuer) andauernd prüfen muss, ob eine Funktion sich noch an der Stelle befindet, wo sie mal war.

Ich hab nix gegen Breaking Changes, aber bei so Brot-und-Butter Funktionen, die man benutzt, weil man es eben besser machen will als die Jungs, die gar nichts testen und dir einfach nur ne Extension himschmeissen, sollte 2-10x nachgedacht werden, ob die jetzt wirklich an eine andere Stelle müssen.

Wenn man in Ruhe drüber nachdenkt…
Die zentrale Funktion, um rauszufinden, in welcher TYPO3-Version man ist, darf man nie nie nie nie woanders hin bewegen, da sie sonst jeglichen Sinn verliert.

Mathias Schreiber am 05. August 2013 um 18:05

@Peter @Mathias ist Funktion ist seit 4.6 (also auch in 4.5, 4.7, 6.0) deprecated gewesen. Wie lange sollen wir den Altlasten mitschleppen?

Selbst in 4.5 seht schon ein Hinweis:
t3lib_div::int_from_ver
Returns an integer from a three part version number, eg ‚4.12.3‘ -> 4012003 This method will be deprecated in TYPO3 4.6. You are encouraged to start using t3lib_utility_VersionNumber::convertVersionNumberToInteger() instead

Man muss tatsächlich nur die require/include Aufrufe entfernen, um die meisten Extensions lauffähig zu bekommen.
Und tatsächlich macht PHP 5.4 mehr Probleme als TYPO3 CMS.
Außerdem sind die TYPO3 Entwickler in diesem Punkt einfach (IMHO) zu verwöhnt.

Philipp Gampe am 05. August 2013 um 18:31

Wie lange sollen wir den Altlasten mitschleppen?

Gute Frage, gute Antwort:
2 LTS lang.
Schaut man sich die Verteilung an, spielt nämlich 4.6, 4.7 und 6.0 nicht wirklich eine Rolle im Markt.
Daher ist dies eine Altlast, die – wenn man sich mit dem Markt beschäftigt – durchaus mitgeschleppt werden sollte, da sich viele ernsthafte Kunden nämlich von LTS zu LTS hangeln werden.

Und der Hinweis mit 4.5 ist leider nicht hilfreich, wenn man mehr Versionen abdecken möchte.
Hier wird ein Riegel vorgeschoben, weil irgendjemand lieber Ordner als Dateien hat.
Eine echte Begründung jenseits von „Ich find das aber schöner so“ kam leider bisher noch nicht.
Sollte es die geben, mag die Situation anders aussehen, wobei ich es bei diesem Beispiel stark anzweifle.
Außerdem sind die TYPO3 Entwickler in diesem Punkt einfach (IMHO) zu verwöhnt.
Da schätzen wir uns glücklich, dass Du entscheidest, wer verwöhnt ist und wer nicht.
Oder was „Verwöhnen“ bedeutet.
Was du „verwöhnt“ nennst, nennen viele meiner Kunden „planungssicher“.

Du siehst, die Meinungen gehen auseinander und deswegen ist es für alle Beteiligten kriegsentscheidend, zu sprechen.
Dieses Beispiel ist ein Grund dafür, warum eine Art Product Board notwendig ist.

Und bitte auch nicht (wie so oft) falsch verstehen:
Es geht nicht darum, Refactoring zu verbieten.
Es geht nur darum, mehr Weitblick bei den Auswirkungen zu zeigen.
Wer auch immer diese Funktion weg geschoben hat, hätte doch nur einmal realistisch schauen müssen, was die LTS „gebracht“ hat.
80% Marktanteil der bekannten Installationen.
Dann muss man nicht lang nachdenken, um zu sehen, dass LTS ein Erfolg war und ist.
Von dort aus bewegt man sich mental weiter zu „ok.. was erhoffen sich Nutzer von LTS? Ah… wir machen breaking changes… das ist ok… wie sorgen wir dafür, dass Breaking Changes geprüft werden können? Jo, wir behalten die eine Funktion (und falls es noch mehr gibt, die eine solche Prüfung sicherstellen auch die) bei und sterben den einen, kleinen Tod.

So würde man das im Profi-Segment machen.
Wir machen’s leider nicht und daran sollte man etwas ändern.

Mathias Schreiber am 05. August 2013 um 18:48

@Matthias:
–
Ich habe gerade eine pi_base(!)-Extension von mir unter 6.2 alfa getestet.
–
1. pibase funktioniert, die Klasse wird problemlos erweitert.
2. ich hatte in einer flexform eine userfunc, die musste ich über den autoloader einbinden. Das war einfach.
3. ein schöner Fehler war in substituteMarkerArray: Ich hatte als 4. Parameter das hier einen leeren String – geht nicht mehr in PHP 5.4, das muss jetzt array() sein. Schlampig programmiert von mir, was PHP 5.4 nicht mehr durchgehen lässt.
4. tx_gwisem_pi1_wizicon ist etwas blöd, da scheint readLLXMLfile nicht mehr zu funktionieren. Ich habe mir aber eine andere Schreibweise bei der news-Extension abgeschaut, das geht in 5 Minuten – pro Plugin.
5. in einem der drei Plugins verwende ich noch die alte Mailklasse, die seit 4.6 obsolet ist. Das muss ich austauschen, aber das habe ich in den meisten meiner Extensions schon gemacht; das dauert so etwa 15-20 Minuten.

—

Fazit: Auswand ist da, hält sich aber in Grenzen. Ich schätze für diese Extension mit drei Plugins etwa 1 bis 1,5 Stunden.

– das Erweitern der pi_base-Klasse geht einfach.
– das Einbinden von anderen Klassen geht über den Autoloader wirklich einfach.
– die von mir verwendeten API-Aufrufe aus der t3lib_div funktionieren alle noch.
– tx_gwisem_pi1_wizicon muss angepasst werden, aber begrenzt
– Namespacings braucht es nicht.

Die größte Änderung ist ohne Zweifel die neue Mailklasse, da die aber schon seit 4.5 existiert, habe ich die bei den neuen Extensions eh schon verwendet. Und der Aufwand, die umzuschreiben hält sich in Grenzen. Ich schätze mal, ältere Extbase-Extensions anzupassen dürfte aufwändiger sein.

Das war schon mal ein ganz optimistischer Anfang, würde ich sagen. Ich musste letztens eine eigene PHP-Programmierung von PHP 4 auf PHP 5.4 hochheben, da war deutlich mehr zu machen 🙂

Peter am 05. August 2013 um 20:21

PS: an den Blog-Gestalter: das Theme hier erinnert mich immer an die alten Monitore mit weisser, gelber oder grüner Schrift auf schwarzem Grund. Die waren extrem ermüdend … Die Schrift hier ist das auch. Insbesondere die Kommentare sind für mich kaum lesbar, der Text beginnt nach 2/3 Zeilen regelrecht zu flimmern. ich muss mir den Text rauskopieren um ihn lesen zu können …

Peter am 05. August 2013 um 20:43

für sowas gibt es „ctrl +“ bzw „ctrl mousewheel“.

kommentator am 05. August 2013 um 21:32

Nur zur Information: int_from_ver() wurde in 6.x wieder eingeführt, um genau diese Probleme zu vermeiden:
https://git.typo3.org/Packages/TYPO3.CMS.git/commit/160ddfeab23a708592fd8de8d3074da69bb8ef27

Markus K am 06. August 2013 um 09:04

Hey Peter, Hey Komentator, das ist in Arbeit wird aber noch ein paar Tage dauern. Ein neues Design liegt bereits in der Schublade 🙂 Besserung ist in sicht…

Tim Lochmüller am 06. August 2013 um 09:44

Ein Hoch auf Helmut für den mutigen und vor allem richtigen Schritt

Mathias Schreiber am 06. August 2013 um 09:52

Wir haben bei einigen Projekten unglaubliche Probleme mit Templavoila, RealURL etc gehabt, weswegen wir uns bei bestimmten Aufgaben auch auf 4.5 LTS festgelegt haben. Sind aber auch gespannt auf den Übergang. 🙂

Browserwerk Internetagentur - Gerrit am 06. August 2013 um 20:29

Ein interessanter Beitrag und eine interessante Diskussion.
Ich bin ein bekennender Technikfan. Daher kann ich gut nachfühlen, dass die Entwickler Refactoring eine hohe Priorität einräumen. Die hier propagierten künftigen Möglichkeiten klingen gut, wobei es mir jetzt noch erschwert, ob ich meinen Webseitenrelaunch (bei dem alle Extensions selbst entwickelt werden) auf TYPO3 CMS Basis mache oder schon Neos.

Ich hoffe, dass
– künftig wieder mit jeder neuen TYPO3 Version Features ausgeliefert werden, die dann vornehmlich den Redakteuren dienen (also eine Balance aus Refactoring & Features) – Ein Feature kann auch eine Komfortfunktion sein – das verbessern der Abläufe aktueller Funktionen etc.
– es eine klare Zielgruppentrennung zwischen Neos und CMS geben wird und gute Infoseiten, die einfach mit Beispielen erklären, was wofür geeignet ist. Meinetwegen ggf. dann auch, wie die verschiedenen TYPO3 Produkte zusammenwirken (können).
– ein überarbeitetes Extension Management, die RIchtung in die es geht, gefällt mir.
– TYPO3 Neos bald stable wird. 🙂

Extension Management:
Da ich ein Fan von Breaking Changes bin im Sinne: Ich hasse es aus Kompatibilitätsgründen unglücklich zu programmieren / Workaround zu nutzen / Code-Relikte beizubehalten. Ich fände es gut, wenn der Extension Manager dafür die Parallelentwicklung unterstützen (sagt es mir bitte, falls er es schon kann) würde im Sinne:
Ich kann eine Extension entwickeln und mit hochziehender Versionsnummer, können alte TYPO3 Installationen, weiterhin die alten Versionen runterladen und ihnen wird diese auch direkt angeboten, und nur ein Hinweis, dass es eine neuere gibt, die aber nur für neuere TYPO3-Versionen ist. Damit sollte es dann möglich sein, alte Extensions nur für Sicherheitsfixes für alte TYPO3-Versionen zu aktualisieren. Zusätzlich müsste markierbar sein, wenn alte Extensionsversionen für alte TYPO3-Versionen eben noch gepflegt werden (ganz, nur Sicherheitsupdates o.ä.) mit einer kleineren Versionsnummer. Ich fand das bei Powermail schon verbesserungswürdig. Ansonsten hat man als Entwickler ja nur die Möglichkeit, eine neue Extension zu machen, doch das finde ich aus „Marketinggründen“ unglükclich.

Hauke am 13. September 2013 um 12:51

Weiß Jemand, ob bei der 7.4.0 auch noch alte pi_base Extensions laufen wie in 6.2?

Danke und Grüße

Kevin am 17. September 2015 um 17:25

Ja… wenn ordentlich Namespaces benutzt werden. Aber laufen tun diese…

Tim Lochmüller am 17. September 2015 um 18:12

Kategorien

Archiv