Erweiterungs-Repository

[andreas.schempp]

Ich fände eine einfache, zentrale Möglichkeit zur Dokumentation gut. Ich bin mir allerdings nicht sicher ob das https://contao.org-Wiki dafür gedacht ist...

Irgendwie finde ich typolight-forge auch nicht optimal, weil die Erweiterungen ja zentral abgelegt werden, aber bei -forge alles etwas dezentral ist.

[ku-ma-122]

Ich muß sagen, die Entwicklung der Erweiterungen finde ich prima, und mich stört es auch nicht, das es viele "kleine" Erweiterungen gibt.

Was ich aber viel erschreckender für TL-Neulinge finde ist die langsam unübersichtlich werdende Menge an Anlaufstellen. Das ganze Projekt wird auf immer mehr Webseiten aufgespalten und dadurch gerade für Neueinsteiger immer schwieriger zu durchblicken.

https://contao.org
www.typolight-community.de
www.typolight-benutzerhandbuch.de
www.typolight-forge.org
https://contao.org/wiki/GermanDocumentation
usw....

Demnächst noch:
www.typolight-templates.biz

Wieso kann da nicht eine einheitliche Oberfläche geschaffen werden?

[planepix]

Hallo Markus,
www.typolight-benutzerhandbuch.de
ist
www.typolight-handbuch.de oder?

[spirelli]

Alle dieser TL Seiten sieht etwas anderst aus. Unterschiedliche URLs finde ich ok, aber das Auftreten sollte so gleich wie möglich daher kommen. Wie wäre es, wenn es mit der neuen Haupt-TL-Seite eine Richtlinie gibt, wie auch alle anderen "offiziellen" TL-Seiten aussehen müssen, z.B. gleicher Header.

Zu den Erweiterungen:

Ich fände mehrere Entwickler pro Erweiterung super. Wenn man auf eine Erweiterung setzt, dann kann man auch geich and der Zahl der Entwickler sehen, wie zuverlässig die wohl für die Zukungt sein kann.

Erweiterungen zusammenlegen wäre auch wunderbar.

[FloB]

Ich weiß nicht ob ich das richtig verstanden habe, aber ihr habt vor an den Erweiterungen von anderen selbst Code in den Hauptdatenbestand zu schreiben? Das halte ich für einen großen Fehler. Jeder hat da etwas andere Vorstellungen was die Extension machen soll und so endet alles irgend wann in einem großen durchenander. So was ist einfach nicht Handlebar.
Wenn ich mal wieder auf Debian verweisen darf, viele Leute schreiben Code, aber nur wenige Maintainer packen die Pakete zusammen.

So war das nicht gemeint. Klar, es gibt die "Chefentwickler" und es gibt Mitentwickler (vielleicht sogar alle angemeldeten Benutzer im Forge?). Nur der Chefentwickler (oder andere autorisierte) können ein "finales Paket" schnüren, was dann im ER landet. Aber jeder kann und soll mitentwickeln – das ist ja grade der Vorteil an OpenSource und einer Versionsverwaltung wie SVN: Alle Änderungen können jederzeit mit Diff eingesehen werden und diese nachvollzogen werden (oder nicht ). Zudem können neue Entwicklungszweige aufgemacht werden. Ideal wäre es, wenn jeder Benutzer praktisch selber einen Zweig anlegen und dort "rumpfuschen" könnte. Der Chefentwickler kann sich das anschauen und entscheiden, ob er es in den Hauptzweig übernimmt.
Soetwas würde ich mir übrigens beim Core auch wünschen, aber ich verstehe auch, warum Leo SVN nicht frei zugänglich macht. Aber das ist nicht das Thema .

Aber genau diese kleinheit der Extensions ist es doch was TL ausmacht. Es ist nun mal eine Tatsache, dass man eine anspruchsvolle Webseite nicht einfach aus fertigen Extensions zusammenkopieren kann, ds funktioniert einfach nicht.

Ich und sicherlich alle anderen auch haben nichts gegen kleine Erweiterungen, im Gegenteil. Es geht aber darum, dass Miniaturänderungen in jeweils eine Erweiterung gepackt werden – und dass das overkill ist. Fragmentierung in allen Ehren, aber irgendwo muss auch eine Grenze sein. Zudem, wie schon angesprochen, gibt es einige Erweiterungen mit dem selben / ähnlichen Funktionsumfang. Ich spreche nicht von großen Erweiterungen wie die Shops, sondern von kleinen, die, wie gesagt, besser in einer "größeren" aufgehoben werden. Natürlich sollen sie dabei klein und leichtgewichtig bleiben!

Des weiteren bezweifele ich, dass es einen speed-unterschied macht ob 3 kleine Extensions geladen werden oder eine große. Wenn man mal von der Skalierbarkeit absieht, dann ist es dem Server eigentlich egal ob er $GLOBALS auf einmal initialisiert und aus allen einzelzeilen zusammen setzt oder dazu mehrere Files durchliest. Den unterschied sollte man erst am 500+ Erweiterungen geringfügig merken.

Es kommt auf die Seite an. Eine private Homepage kommt sicherlich mit 500+ Erweiterungen gut zu potte, aber eine Seite, die viele Zugriffe hat, zieht die Serverlast ordentlich nach oben, wenn bereits ein Bruchteil davon installiert ist – denn bei jedem Request wird alles neu durchlaufen. Da gibt es keinen Cache, der diese Daten für verschiedene Requests zwischenspeichert.

Ich kann euch als (aktivster) Erweiterungen-Autor ein paar Dinge sagen, und gerne auch meine Ideen.
…

Kannst du konkrete Änderungswünsche, Ideen oder auch kleine Anregungen bitte im Repository-Diskussionsthread posten? Dann haben wir beisammen, was zusammen gehört. Auch so eine Art "ideale Ablaufskizze" für ein bequemes Einrichten und Verwalten von Erweiterungen als Entwickler wäre sehr hilfreich.

…
- Das mit dem Zusammenlegen von Erweiterungen finde ich nicht schlecht, aber wer ergreift hier die Initiative?

Ich würde mich gern für ein Überarbeiten der Erweiterungen einsetzen, aber bis mindestens September bin ich dazu nicht in der Lage. Vielleicht schaff ich es davor ein paar Sachen zu machen.

Was ich aber viel erschreckender für TL-Neulinge finde ist die langsam unübersichtlich werdende Menge an Anlaufstellen. Das ganze Projekt wird auf immer mehr Webseiten aufgespalten und dadurch gerade für Neueinsteiger immer schwieriger zu durchblicken.

Das Problem sehe ich auch, und hier sollte eine klare Regulierung erfolgen. Nicht unbedingt vom Aussehen (sicherlich ist das wünschenswert), aber von der Organisation. Wenn die Seiten offiziell sind (was sie ja zur Zeit großteils nicht sind – nur quasi-offiziell, jedoch gilt hier, finde ich, das Selbe: ), sollten sie untereinander klare Abgrenzung schaffen, aber sich gegenseitig verlinken, jeweils mit Infos, über was sich die Seite kümmert. Eine klare Struktur und Koordinierung sollte es für neue Nutzer einfacher machen, sich in der "TYPOlight-Welt" zurechtzufinden.

Das Ganze sollte wie TYPOlight selber aufgebaut sein: Einfach in der Benutzung, aber leistungsfähig und leicht erweiterbar, wenn man es braucht. Also für den Laien einfach, für den Fortgeschrittenen lehrreich und für den Profi informativ.

[Toflar]

Wieso kann da nicht eine einheitliche Oberfläche geschaffen werden?

Ganz einfach: Aus Haftungsgründen.

Irgendwie finde ich typolight-forge auch nicht optimal, weil die Erweiterungen ja zentral abgelegt werden, aber bei -forge alles etwas dezentral ist.

TL-Forge war nie und ist nicht dazu gedacht, irgend einen Teil von TL zu ersetzen, verbessern o.ä.
TL-Forge ist ein Hilfsmittel für alle Entwickler, die gerne ein Ticketsystem usw. für ihre Erweiterung haben möchten und dies nicht selber zur Verfügung haben. Dieser Service wird von lindesbs gehostet und basiert auf völlig freiwilliger Basis. Niemand zwingt Entwickler, TL-Forge zu benutzen...
Es ist ganz einfach ein geniales Hilfsmittel, nicht mehr und nicht weniger

[ku-ma-122]

Hallo Markus,
www.typolight-benutzerhandbuch.de
ist
www.typolight-handbuch.de oder?

Klar meinte ich die, so verwirrt bin ich schon

as Problem sehe ich auch, und hier sollte eine klare Regulierung erfolgen. Nicht unbedingt vom Aussehen (sicherlich ist das wünschenswert)...

Ich denke gerade vom Aussehen her, so kann Leo z.B. den offiziellen Seiten das Layout erlauben (bzw. vorschreiben) und den nicht offiziellen eben nicht. Das würde für den Einsteiger einen nicht unerheblichen Mehrwert darstellen. Man sieht eben immer gleich: "Aha TYPOlight, da bin ich richtig" ;-)

Ob Typolight-forge offiziell ist weiß ich jetzt nicht, aber als ich dort das erste mal war hab ich schon überlegt ob ich da richtig bin Das soll keineswegs das Design, die Seite an sich oder die Arbeit dahinter schmälern. Aus marketingtechnischer Sicht ist es aber eher suboptimal, das die alle Seiten in unterschiedlichen Designs daherkommen. Der Wiedererkennungswert ist da nicht besonders groß.

Gerade bei OpenSource ist das eigentlich Standard (siehe auch T3 oder Joomla), aber bei kommerziellen Systemen nicht. Hier könnte TYPOlight auch eine klare Abgrenzung zum restlichen Sumpf schaffen wenn eine einheitliche CI bei allen offiziellen Seiten dies dem Nutzer auch direkt signalisiert.

Ich schreib es gerne dazu: Das ist keine Kritik an den Seiten oder dem Design, sondern nur eine Idee TL - trotz OpenSource - noch ein bisschen professioneller werden zu lassen.

[Toflar]

Ob Typolight-forge offiziell ist weiß ich jetzt nicht, aber als ich dort das erste mal war hab ich schon überlegt ob ich da richtig bin Das soll keineswegs das Design, die Seite an sich oder die Arbeit dahinter schmälern. Aus marketingtechnischer Sicht ist es aber eher suboptimal, das die alle Seiten in unterschiedlichen Designs daherkommen. Der Wiedererkennungswert ist da nicht besonders groß.

Wie oben erwähnt. Es ist nicht offiziell und darf es auch nicht sein, weil es Third-Party-Extensions sind. Sprich: Wenn da jemand etwas entwickelt, was TL zum Absturz bringt, haftet Leo keineswegs. Wird die ganze Sache aber unter https://contao.org geführt, mit offiziellem Logo usw., dann weiss ich nicht, wie das aus rechtlicher Sicht aussehen würde.

Aber wahrscheinlich eher schlecht. Ist auch der Grund, weshalb die Foren von TL abegrennt wurden und zwar sogar noch in den verschiedenen Sprachen auf unterschiedlichen Domains...

[ku-ma-122]

Ok, TYPOlight-forge ist dann vielleicht auch von mir ein schlechtes Beispiel, da es ja eher Entwickler wie Neulinge anspricht...

...beim Handbuch (welches ja eine offizielle Seite darstellt) oder auch hier im Forum wäre es schon wünschenswert.

[tinoo]

Guten Morgen allerseits

Für mich gibt es zwei Arten von Erweiterungen:
- solche, die den Core um grundlegende Funktionen erweitern
und
- solche, die den Core um spezifische Funktionen erweitern.

Ich bin der Meinung, dass alle Erweiterungen mit grundlegenden
Funktionen irgendwann in den Core aufgenommen werden sollten.
Beim Thema Kalender z.B. gibt es diverse Erweiterungen die Funktionen
anbieten, die meiner Meinung nach in die Grundfunktionalität gehören!

Oder als generelles Beispiel: Ich kann in MS Word einen Text schreiben.
Um den Text fett zu drucken, muss ich aber nicht extra eine Erweiterung
installieren...

Ich denke, wenn man nach diesem Kriterium die Erweiterungen analysieren
würde, könnte man schon diverse Erweiterungen irgendwann streichen...

[Toflar]

...beim Handbuch (welches ja eine offizielle Seite darstellt)

Für's Handbuch ist Nina verantwortlich...Leo hat damit nichts zu tun: http://www.typolight-handbuch.de/impressum.html

[ku-ma-122]

Moment mal, du verwechselst da glaube ich was, nicht nur wenn Leo im Impressum steht ist eine Seite offiziell.

Nina ist ja auch Mitglied vom TL-Team

[Toflar]

Ja klar ist sie Mitglied, verantwortlich ist trotzdem Leo...

Aber eben, all diese rechtlichen Diskussionen bringen uns auch nicht weiter

[ku-ma-122]

Jaja, der Grat zur erbsenzählerei ist sehr schmal

Aber zurück zum Thema.

[andreas.schempp]

Ich bin der Meinung, dass alle Erweiterungen mit grundlegenden Funktionen irgendwann in den Core aufgenommen werden sollten. Beim Thema Kalender z.B. gibt es diverse Erweiterungen die Funktionen anbieten, die meiner Meinung nach in die Grundfunktionalität gehören!

Ich kann dir soviel sagen, in der aktuellen Situation (Leo als alleiniger Entwickler) werden keine Erweiterungen welche nicht von Leo sind in den Core aufgenommen. Das hat auch Lizenzgründe (siehe Joomla-Probleme). Aus meiner Sicht sollte das aber nicht bedeuten dass alles von Leo in den Core muss ;-)

[joe]

Hey,

ich habe das Thema mit Spannung verfolgt. Ich sehe Andreas seine Ideen und Vorschläge auch als sinnvoll und notwendig. Was viel schockierender ist ist die Tatsache das es zig anlaufpunkte gibt die alle Elementar sind, wie von ku-ma-122 angesprochen.

Ich kenne da ein js Framework das meines erachtens das beste auf dem Markt ist welches in typolight eingebunden ist. Die Rede ist von Mootools. Mit einer der Gründe warum sich andere Frameworks weiter verbreitet haben ist der Grund das es kein vernünftiges Repository gab/gibt, das Forum abgeschafft wurde uvm. rund um wurde die Community von den Entwicklern leider mehr oder minder ignoriert. Natürlich gibt es da noch mehr Gründe die mit den angesprochenen Themen nichts zu tun haben.

Ich hatte vor eine about-typolight.com Seite aufzuziehen, nur habe ich mir irgendwann die Frage gestellt warum auch ich nun mein eigenes Süppchen kochen soll?

Ich bin dabei in jeder Art und Form das Projekt zu unterstützen nur dann bitte mit Hand und Fuß.

Meine Idee
Es gibt eine offizielle Typolight Community und das ist typolight-community.de / com. Bestandteil sollten dinge sein die von der Community auch kommen. Sprich Handbuch, Forum, Tutorials, Tests, News und Reviews von Extensions usw. Auch das forge könnte bestandteil sein da es um Entwicklungen von der Community/Membern kommt

Auf der https://contao.org ist der offizielle Teil. Sprich downloads von Extensions, des systems usw. Zwingend notwendig ist es das es Leute gibt die alle Extensions testen und bewerten. Bei Typo3 gab es mal einen ähnlichen Ansatz, manche extensions hatten den Status profed by typo3 core team. Ich denke das ist auch sehr wichtig um die qualität der extensions zu erhalten. Dazu sollte es eine Demo Plattform geben auf der alle extensions installiert ist quasi ne sandbox.

[klaschatx]

Ich kann dir soviel sagen, in der aktuellen Situation (Leo als alleiniger Entwickler) werden keine Erweiterungen welche nicht von Leo sind in den Core aufgenommen. Das hat auch Lizenzgründe (siehe Joomla-Probleme). Aus meiner Sicht sollte das aber nicht bedeuten dass alles von Leo in den Core muss ;-)

Ich kann die Argumentation nachvollziehen und vielleicht wird darin sogar ein gewisser Sachzwang deutlich, dem man sich schlecht entziehen kann. Aber ich finde den Ansatz trotzdem wenig ideal. Mit Priorität im Vordergrund sollte doch eigentlich eher die Frage stehen, welche Funktionen ein cms braucht, um die häufigsten Bedarfe abzudecken. Ich finde es z. B. schwierig, dass TL von Hause aus keine Möglichkeit bietet, flv-Videos abzuspielen.
Ein anderes Beispiel sind meine geliebten optional_rows. Ich weiß noch gut, dass im alten Forum ein Code-Schnipsel veröffentlicht wurde, das die gleiche Funktionalität ermöglichte. Leo bedankte sich damals ausdrücklich für diesen wichtigen Hinweis an die Community. Nun gibt es die Erweiterung optional_rows, die wohl nichts anderes macht, als diese Funktion (und den mehr oder weniger gleichen Code?) per Häkchen im Backend verfügbar zu machen. Für mich als DAU-Anwender super! Viel besser, als irgendwo im Code rumzupfuschen. Jetzt meine Frage: Was spricht dagegen, so etwas in den Core aufzunehmen. Die eine Option macht TL nicht fetter, aber erhöht die Usability so was von ungemein. Nur, weil die Erweiterung von Psi stammt, kann sie nicht integriert werden? Meine Güte, dann kann man den Autor doch anfragen, ob er was dagegen hat - ich kann mir das kaum vorstellen bei einer solchen Mini-Erweiterung. Puh - langes Beispiel.

Zurück zum Thema: Ich fände es gut, wenn TL im Grundbestand oder durch offizielle (!) Erweiterungen die häufigsten und wichtigsten Bedarfe und Funktionen abdecken würde. Freie Erweiterungen sollten dann entweder einen erweiterten Funktionsumfang zur Grundfunktion bilden (Beispiel: FG und EFG) oder Nischenbedarfe abdecken (Beispiel: Bahnauskunft).

Die Entscheidung über Core/Nicht Core und Offiziell/Nicht Offiziell rein an der Autorenschaft festzumachen? Finde ich nicht wirklich gelungen.

Grüße
klaschatx

[Toflar]

Ich kenne da ein js Framework das meines erachtens das beste auf dem Markt ist welches in typolight eingebunden ist. Die Rede ist von Mootools. Mit einer der Gründe warum sich andere Frameworks weiter verbreitet haben ist der Grund das es kein vernünftiges Repository gab/gibt, das Forum abgeschafft wurde uvm. rund um wurde die Community von den Entwicklern leider mehr oder minder ignoriert.

Ich kenne das Framework auch und habe regelmässigen Kontakt mit Dev's...mootools ist in einer Übergangsphase. Ich hab einige inoffizielle Dinge bereits gesehen. Neue Doku und viele, viele neue Demos. Warte auf 2.0 und dich wird's umhauen, versprochen!

Aber eben, BTT

[Franko]

Hallo,
ich finde diesen Thread sehr wichtig - von daher hier meine Anmerkungen:

Zunächst einmal bin ich dafür, die bisherigen 'Core' Anwendungen auch in TL zu belassen und auch nicht weiter auszubauen. Dies ist mit ein Grund warum ich mittlerweile von Typo3 gewechselt bin. Mit dem TL Grundsystem kann man sicherlich 80% aller Anwendungen abdecken. Ich möchte halt nicht wieder zwischen X Versionen von News-Systemen, Newsletter oder Login-Systemen entscheiden/recherchieren/pflegen/updaten müssen.

Zu den Vorschlägen zur Einführung von Kategorien möchte ich nur folgendes anmerken. Kategorien werden nichts wesentlich verbessern, da die möglichen Einteilungen immer subjektiv bleiben und ein jeder unterschiedliche Vorstellungen haben wird.
Hier würde mir eine detaillierte Suche ausreichen.

Wichtig sind daher vor allem, Dokus, FAQ und eben halt die Community. Dieses ist mit dem neuen Forum doch schon gegeben. Bei den Beiträgen zu den Erweiterungen würde ich mir evtl. eine FAQ je Bereich wünschen, die die gelösten Themen je Erweiterung kompakt beschreibt und angeht.

Ansonsten finde ich die Suche nach Möglichkeiten zur Reduzierung von gleichartigen Erweiterungen als einzig sichere Möglichkeiten langfristig - unnötigen - Wildwuchs zu umgehen.

Mehrere Entwickler zusammenzuführen ist sicherlich günstig, benötigt aber auch Aufwand an Administration und Disziplin.

Eventuell wäre eine Lösung, quasi Basis Erweiterungen zu schaffen, die nur von einem engen Kreis gepflegt und auch eingestuft werden. Entwickler können sich dann mit den eigenen Erweiterungen in diese Basis Apps einklincken.

Beispiel: Die vielfältigen Effekt Erweiterungen wie Accordion, MultipleCollapse, ContenSlider, TabControl etc. basieren letztlich lediglich auf entsprechende Script Lib's und CSS. Die separaten Erweiterungen bieten die Möglichkeit diese bequem im TL Backend zu verwalten und die Variablen der Scripte durch einfache UI Elemente zu variieren.

Da ich mich in der TL Backend Programmierung nicht so auskenne mache zumeist folgendes wenn ich andere Effekte einbinden muß: Kopiere mir ein bestehendes Modul, tausche die Javascript und CSS Bibliotheken aus und passe diese an.

Ein obiges 'Basis Modul' könnte evtl. hierbei folgende Aufgabe erfüllen:
Im Backend die rudimentären Strukturen zu bieten, damit die Start/End Anweisungen (s. Accordion/ContenSlider/TabControl) zur Verfügung stehen und die Möglichkeit sich auf verschiedene ScriptLibraries und Templates beziehen zu können.

Eine neue Erweiterung z.B. x999Slider kann dann diese 'Basis Erweiterung' nutzen und eigene, notwendige Daten und Einstellungen bereitstellen.
Der 'User' wählt dann, basierend auf der 'Basis Erweiterung' zwischen Accordion, TabControl, x999Sllider und .... aus.

Mit den gängigen Scripts wie Slimbox, multiplebox, mootabs, lightbox etc. kann man dann sicherlich schon eine Vielzahl an 'Erweiterungen' zusammenfassen, deren Doku sich aber dann auf die eigentliche Funktion des jeweiligen Scripts reduzieren könnte - die Nutzung der zu Grunde liegenden 'Basis Erweiterung' bleibt ja immer gleich.

Wie gesagt - ein Gedankenansatz - die TL Profis können dies sicherlich hinsichtlich Machbarkeit beurteilen.

Frank

[tinoo]

Hoihoi

Ich kann dir soviel sagen, in der aktuellen Situation (Leo als alleiniger Entwickler) werden keine Erweiterungen welche nicht von Leo sind in den Core aufgenommen. Das hat auch Lizenzgründe (siehe Joomla-Probleme).

Das mit den Lizenzgründen wird man ja wohl in den Griff bekommen, oder? Es geht ja nicht darum, alle Erweiterungen auf einen Rutsch und blind in den Core zu übernehmen, sondern ausgesuchte Erweiterungen so aufzubereiten, dass sie Leo's Standards in Sachen "Ordnung im Quellcode" erfüllen (Stichwort: Spaghetti-Programme). Ich denke es geht eher darum oder?

Unter "Aufnahme in den Core" verstehe ich nicht unbedingt, dass die Erweiterung irgendwo in den Tiefen irgendwelcher PHP-Dateien verschwinden müssen, sondern als Plugins - analog z.B. TinyMCE - in den Plugin-Ordner wandern. So hat der Ursprungs-Entwickler immernoch die Möglichkeit, die Weiterentwicklung voranzutrieben. Oder die Erweiterung kann gelöscht werden, wenn sie hinfällig oder inkompatibel wird, wenn sie nicht mehr weiterentwickelt wird.

An zweiter Stelle der Popularität liegt der EFG. Warum wird dann nicht der EFG als Standard erklärt und der "alte" Formulargenerator verabschiedet, wenn eh jeder die Erweiterung installiert? Das macht doch keinen Sinn...

Dass ein CRON Scheduler nicht unbedingt in den Core gehört, kann ich nachvollziehen, denn 99% der User werden gar nicht wissen, was das ist...

Ich denke, das wird eine dieser Endlos-Diskussionen. Auf der einen Seite sind die Entwickler, die vielleicht mit ihren Erweiterungen Geld verdienen wollen, auf der anderen Seite die Community, welche viele Wünsch an den Tag bringt, aber natürlich kostenlos...

[FloB]

Mehrere Entwickler zusammenzuführen ist sicherlich günstig, benötigt aber auch Aufwand an Administration und Disziplin.

Es soll niemand gewzungen werden mit mehreren zusammenzuarbeiten. Und es ist klar, dass das erhöhten Verwaltungsaufwand bedeutet. Jedoch gibt es ja schon mit TYPOlight Forge eine Plattform für Entwickler, sodass der Aufwand minimiert wird. Es bleibt natürlich der Aufwand beim Code vergleichen und prüfen.

[FloB]

Ich kann euch als (aktivster) Erweiterungen-Autor ein paar Dinge sagen, und gerne auch meine Ideen.

1. Es ist enorm Aufwändig die Versionierungen von TYPOlight mit den Erweiterungen aktuell zu halten. Es gibt keine "Mehrere Bearbeiten"-Funktion, bei >50 Erweiterungen muss ich für jede einzelne ca. 10 Klicks machen, um für einen neuen TL-Build frei zu schalten. Soweit ich weis werden die Subversionen (2.7.1/2.7.2) im Repository nicht mehr geführt, da darin nur noch Fehlerbehebungen enthalten sollten.

2. Es ist nicht sooo einfach eine Erweiterung ins Repository zu stellen. Ich habe hier sicher nochmals 10 bis 20 Erweiterungen welche ich reinstellen könnte. Einige sind - aus meiner Sicht - nicht reif genug, andere nicht getestet genug und dritte so spezielle das sie wohl wenige benutzen werden. Die Erweiterung zu veröffentlichen ist ja eine Sache, aber es benötigt immer Beschreibung, Tags usw. in 2 Sprachen, und am liebsten hätten alle ein ausführliches Handbuch!

3. Aus Erfahrung haben wir gesehen, dass die Bewertungs- und Rezessionsfunktion nicht wirklich genutzt wird. Aus meiner Sicht wäre es sehr gut ein Team zu haben, welches Erweiterungen im Details anschaut, aber ich habe das Gefühl dazu sind wir (noch) zu klein. Oder würde gerne jemand Handbücher zu meinen Modulen schreiben? ;-)


Nun meine Ideen bzw. Wünsche:

- Mehrere Authoren für eine Erweiterung fände ich sehr gut. Hier kommt natürlich im Idealfall ein SVN zum Einsatz, aber ich denke das ist nicht Aufgabe des Core/Repository.

- Pakete habe ich mir auch schon überlegt, und sind ja im Prinzip mit den Abhängigkeiten auch möglich. Hier kommt mir der iTunes Store in den Sinn, bei dem Mitglieder selber Empfehlungen zusammenstellen können.

- Das mit dem Zusammenlegen von Erweiterungen finde ich nicht schlecht, aber wer ergreift hier die Initiative?

Aus einem anderen Thread.

[andreas.schempp]

Unter "Aufnahme in den Core" verstehe ich nicht unbedingt, dass die Erweiterung irgendwo in den Tiefen irgendwelcher PHP-Dateien verschwinden müssen, sondern als Plugins - analog z.B. TinyMCE - in den Plugin-Ordner wandern. So hat der Ursprungs-Entwickler immernoch die Möglichkeit, die Weiterentwicklung voran zu treiben. Oder die Erweiterung kann gelöscht werden, wenn sie hinfällig oder inkompatibel wird, wenn sie nicht mehr weiterentwickelt wird.

An zweiter Stelle der Popularität liegt der EFG. Warum wird dann nicht der EFG als Standard erklärt und der "alte" Formulargenerator verabschiedet, wenn eh jeder die Erweiterung installiert? Das macht doch keinen Sinn...

Dass ein CRON Scheduler nicht unbedingt in den Core gehört, kann ich nachvollziehen, denn 99% der User werden gar nicht wissen, was das ist...

1. Plugins-Ordner = nicht Module für das System

2. Der EFG baut auf dem Formulargenerator auf, er funktioniert gar nicht ohne. Ich habe in all meinen Projekten den EFG 1 mal benutzt, und zwar nur wegen dem Bestätigungs-Mail.

3. Der Cron-Scheduler ist ja im System integriert (Poor Mans Cron) und wird auch zwingend benötigt, z.B. um die Sitemap-XML einmal pro Woche automatisch neu zu erstellen.

[Budman]

Also ich würde gerne nochmal auf das grundsätzliche Thema eingehen, das meiner Ansicht nach, nicht unbedingt etwas mit den Erweiterungen und deren Entwicklung an sich zu tun hat.

Was mich ehrlich gesagt schon von Anfang an stört ist die nicht vorhandene Übersicht bei Erweiterungen. UNd genau da würde ich gerne ansetzen.

Daher meine Idee bzw Vorschlag, dass alles an ein paar Leute zu bündeln, die sich entsprechend darum kümmern.

Eben ein Team, das sich nur um Erweiterungen kümmert: Validierung, Beschreibung, evtl. Dokumentation, Rezension.

Das ganze sollte (meiner Idee nach) auf einer Plattform stattfinden und dort uneingeschränkt betruet werden können durch eben dieses Team. Das heisst nicht automatisch, das dort auch die Erweiterungen liegen oder runter geladen werden können.

Mir ist das Problem aus meinen phpBB Zeiten sehr wohl bekannt. Ohne Katalog, der entsprechende Suchmechanismaen hat, läuft vieles ins Leere.

Da aber eben innerhalb eines Teams von ein paar Leuten wesentlich besser entscheiden werden kann, was wohin laufen, wie etwas kategorisiert ist und wie man es beschreibt, würde das m.E. auch dem Entwickler einiges an Arbeit abnehmen.

Konkreter gefasst ungefähr so:

• http://einenochzuüberlegendedomain.tld
• Erweiterungen werden eingereicht und dann validiert
  Wenn jemand als Autor das nciht möchte, macht ja nix, nur sollten eben geprüfte Erweiterungen das auch zeigen können (Einfach nur als Hinweis für den Benutzer)
• Beschreibung der Erweiterung durch Team (Kurzbeschreibung)
• Katalogisierung der Erweiterung durch Team (dadurch guter Katalog mit verschiedensten Suchmöglichkeiten)
• Evtl. auch Doku und Tutorial zur Erweiterung durch Team und/oder Autor

Wie gesagt, ich bin da gerne dabei!

@Toflar
Vielleicht könnten wir die nächsten Tage mal irgendwie in einem Zweiergespräch mal etwas konkreter werden?

[FloB]

• Beschreibung der Erweiterung durch Team (Kurzbeschreibung)
• …
• Evtl. auch Doku und Tutorial zur Erweiterung durch Team und/oder Autor

Ich finde, dass ein Team nicht die "Arbeit" eines Entwicklers abnehmen soll. Ich würde die Punkte so formulieren:

• Prüfen der (Kurz-)Beschreibung einer Erweiterung und ggf. Verbesserung(svorschlag) in Absprache(?) mit Entwickler einbringen.
• Dokumentation überprüfen und ggf. nachbessern, ggf. Tutorials schreiben.

Grade die Dokumentation ist ja eine Sache, die der Entwickler am besten kann – da er um alle Features weiß. Jedoch kann man es so machen, dass, wenn ein Entwickler wenig Zeit hat eine ausführliche Doku zu schreiben, dieser eine kurze schreibt (Stichwort-, Listenformat), die dann das Team "erweitert" / ausformuliert. Dies wäre dann eine Art Qualitätssicherung bei der Dokumentation.

[lindesbs]

Ich persoenlich aus Entwicklersicht finde es sinniger, wenn andere Doku schreiben wuerden. Der Entwickler selbst gibt die Moeglichkeiten vor.
Ich persoenlich mag Doku schreiben nicht.
Wenn ich Funktionalitaeten beschreibe ist es fuer andere einfacher Prosa drumherum zu schreiben. Zumal ein Entwickler immer einen sehr engen Blick hat, und viele Bugs seiner Entwicklung aus Wissen umgeht.
Ein "unerfahrener" merkt sehr schnell, ob eine Funktionalitaet gut umschrieben ist.

[BugBuster]

Dem kann ich "lindesbs" nur zustimmen. Als Freizeit Entwickler habe ich nicht genug Zeit die Doku für jeden verständlich zu schreiben. Daher haben auch alle meine Module einen Handbuch Link ins Wiki, dort sind die Beschreibungen zumindest so geschrieben, das jeder der das Prinzip von TL verstanden hat mit den Modulen ohne Probleme klar kommen sollte. Und treu dem Wiki Prinzip kann natürlich jeder dort Verbesserungen einbringen.

Ein weiteres Thema was mir öfters aufgefallen ist, wir haben teils durch Programmierfehler teils durch Mischung von aktuellen und nicht aktuellen Modulen das Problem der Inkompatibilität bzw. gegenseitiger Beeinflussung.
(Schuld bekommt immer das nicht funktionierend Modul obwohl es meist ein anderes ist)

Hier wäre natürlich es sehr nützlich alle Module / Plugins / Widgets etc. in einer Installation zu haben um einen Test im Zusammenspiel durchzuführen wie schon mal vorgeschlagen wurde.
ABER, wer soll das denn bitte tun? Das nimmt dermaßen viel Zeit in Anspruch und benötigt auch Kenntnisse aller Module.

Auch gibt es immer öfters neue Module ohne einer Bekanntmachung im Forum oder Beschreibung irgendwo.
Hier wäre es glaub ich sinnvoll eine Art Richtlinien festzulegen an denen sich jeder halten sollte. (Mindeststandards)

[Toflar]

Wie gesagt, ich bin bei allem dabei, was ich für sinnig empfinde...

Und die letzten paar Beiträge gehen jetzt in diese Richtung
Aber naja...was, wenn Leo schon viel weiter als wir alle gedacht hat?
@Bud: Wir sollten echt noch ein bisschen abwarten...

Denkt ihr, User schreiben einfach so Doku's? Schon jetzt sind Doku's im Vergleich zur Anzahl an Erweiterungen sehr rar...man müsste das Dokuschreiben irgendwie belohnen mit Credits oder was weiss ich...
Was man damit aber dann kann, weiss ich auch nicht
Jemand eine Idee? Oder ist das grundsätzlich doof?

[FloB]

Dem kann ich "lindesbs" nur zustimmen. Als Freizeit Entwickler habe ich nicht genug Zeit die Doku für jeden verständlich zu schreiben. Daher haben auch alle meine Module einen Handbuch Link ins Wiki, dort sind die Beschreibungen zumindest so geschrieben, das jeder der das Prinzip von TL verstanden hat mit den Modulen ohne Probleme klar kommen sollte. Und treu dem Wiki Prinzip kann natürlich jeder dort Verbesserungen einbringen.

Jedoch kann man es so machen, dass, wenn ein Entwickler wenig Zeit hat eine ausführliche Doku zu schreiben, dieser eine kurze schreibt (Stichwort-, Listenformat), die dann das Team "erweitert" / ausformuliert.

Das habe ich damit gemeint .

Hier wäre natürlich es sehr nützlich alle Module / Plugins / Widgets etc. in einer Installation zu haben um einen Test im Zusammenspiel durchzuführen wie schon mal vorgeschlagen wurde.
ABER, wer soll das denn bitte tun? Das nimmt dermaßen viel Zeit in Anspruch und benötigt auch Kenntnisse aller Module.

Am besten wäre eine Installation, auf die alle Entwickler (und vielleicht noch mehr) Zugriff haben – dort kann dann jeder seine Erweiterung installieren, einrichten und die Interaktion mit anderen Erweiterungen testen.

Auch gibt es immer öfters neue Module ohne einer Bekanntmachung im Forum oder Beschreibung irgendwo.
Hier wäre es glaub ich sinnvoll eine Art Richtlinien festzulegen an denen sich jeder halten sollte. (Mindeststandards)

An sich gibt es ja sowas in der Erweiterung "rep_notify". Da schließe ich mich aber einem anderen Wunsch an, soetwas in das Repository auf der Hauptseite einzubauen. Es reicht ja sowas wie ein RSS Feed und die Übersicht wie im Entwickler-trac – dort kann dann sowas wie "Neue Erweiterung XYZ: (description) (release-notes)" oder "XYZ wurde aktualisiert: (release-notes)" stehen. Da fällt mir grade ein, das könnte die Entwickler dazu verleiten, ausführlichere Release-Notes zu schreiben – noch eine Sache, die positiv zu bewerten wäre .

[FloB]

Wunsch zur Information bei Änderungen des Repository (von matze) hinzugefügt:

• RSS-Feed / Timeline zu Änderungen im Repository (wie im trac).

Habe außerdem mal alle genannten Ideen im ersten Post aufgelistet.

@Mod: Das Thema wäre besser in der Entwickler-Ecke aufgehoben – kann das jemand verschieben? Danke!

[BugBuster]

An sich gibt es ja sowas in der Erweiterung "rep_notify". Da schließe ich mich aber einem anderen Wunsch an, soetwas in das Repository auf der Hauptseite einzubauen.

Wobei mir es hier nicht nur nur darum ging davon zu erfahren sondern was ich genau wie damit tun kann. Es kam erst vor kurzem genau so eine Anfrage hier im Forum "... und was mach ich damit?".
Die Beschreibung im ER reichte da nicht.

Da könnte man wieder auf den Gedanken kommen, Erweiterungen zu bewerten.
Aber mal ehrlich, wer interessiert sich dafür? Solange Nutzer Module installieren ohne zu überlegen, obwohl sie wissen das diese nicht für diese TL Version freigegeben sind (2.6er Module in TL 2.7), wird eine Bewertung auch nicht helfen.

Habe auch kein Rezept wie man die Qualität steigern könnte, aber das etwas dran getan werden sollte bin ich auch der Meinung.

[WebDucer]

Hallo.

Mein Vorschläge zum Repository im Backand aus Sicht eines Übersetzers.

Momentan kann nur ein Übersetzer an einer Erweiterung arbeiten. Bei vielen Erweiterungen ist es auch kein Problem, da diese relativ klein sind. Bei größeren Erweiterungen (Forum, Shop) ist es im Alleingang einfach nicht zu machen. Hier wäre eine Zuteilung an mehrere Übersetzer sinnvoll und effizient.

Als Teamleiter des Übersetzungteams sehe ich auch leider nicht, wer an welcher Übersetzung arbeitet. Die Namen der momentan "belegten" Erweiterungen können nur direkt beim Erweiterungsprogrammierer erfragt werden. So kommt es immer öffter vor, dass aus meinem Team keiner an einer Übersetzung sitzt und diese trotzem für die Sprache belegt ist. Das schlimme ist, dass es oft auch nicht übersetzt wird.

Gruß

[Budman]

Ich finde, dass ein Team nicht die "Arbeit" eines Entwicklers abnehmen soll. Ich würde die Punkte so formulieren:

• Prüfen der (Kurz-)Beschreibung einer Erweiterung und ggf. Verbesserung(svorschlag) in Absprache(?) mit Entwickler einbringen.
• Dokumentation überprüfen und ggf. nachbessern, ggf. Tutorials schreiben.

Grade die Dokumentation ist ja eine Sache, die der Entwickler am besten kann – da er um alle Features weiß. Jedoch kann man es so machen, dass, wenn ein Entwickler wenig Zeit hat eine ausführliche Doku zu schreiben, dieser eine kurze schreibt (Stichwort-, Listenformat), die dann das Team "erweitert" / ausformuliert. Dies wäre dann eine Art Qualitätssicherung bei der Dokumentation.

Da ist mein Standpunkt eher aus der Erfahrung geboren. Ich weiss, auch aus anderen Projekten raus, wie schwer sich "der Entwickler an sich" mit Doku schrieben tut. Er lässt es!

Geht mir ja auch nciht anders. Was sich jedoch in Projekten als sehr guter und erfolgversprechender Weg heraus gestellt hat, ist eben diese Aufgabe von den Schultern des Entwicklers zu nehmen. Die sollen sich auf Ihren Part konzentrieren, und wer immer das auch will, soll sich auf sein Business stürzen, in dem Fall Doku.

Zumal eine Variante wie Entwickler entwickelt, Doku wird vorgeschrieben und dann schlussendlich nur noch redigiert durch den Entwickler als echt zeitsparender Ansatz heraus gestellt hat.

Unsere Texter arbeiten in den meisten projekten nicht anders. Kunde kommt, will Text, wir schreiben nach Einarbeitung ins Thema vor und Kunde prüft und verbessert. Dann hat man beide Seiten in einem Boot, und der Leser hat nicht nur den totalen Technikblick, sondern auch eine anderer Seite mit bei.

@Toflar
Ich schreibe Leo mal eine Mail, ich hab sowieso noch eine geschäftliche Anfrage und möchte ihn ausserdem zum Usertreffen in München überreden, da kann ich diesen Thread hier auch noch kurz anreissen. Wird mich schon nicht köpfen.

[Nina]

Moderationshinweis Nina: Ich habe die Beiträge rund ums Repository jetzt mal alle zusammengeführt, damit da nicht fast identische Diskussionen parallel laufen. In einem gemeinsamen Thema macht das mehr Sinn.

Ihr könnt hier gerne weiterhin eure Anregungen zur Verbesserung des Extension Repository sammeln. Wir haben als Team natürlich ein Auge auf die Vorschläge und werden schauen, inwiefern sie zu den bereits bestehenden Plänen fürs Repository passen. Da wir als Team im Interesse der Masse der Nutzer sowie entsprechend den langfristigen Planungen für TYPOlight entscheiden müssen, können wir aber nicht alle Wünsche einzelner Nutzer umsetzen.

Zum Thema Doku von Third Party Extensions:
Ich finde es eine gute Idee, wenn sich Community Mitglieder bereit erklären, den Extension-Entwicklern beim Erstellen der Dokus unter die Arme zu greifen. Es muss ja nicht immer gleich ein schick ausgearbeitetes Handbuch sein, oft würden schon stichpunktartige Kurzanleitungen helfen.

[FloB]

Ui, jetzt wirds aber ein bisschen unübersichtlich :-/

[Simon]

Tach!

Es gab mal eine Datei im Forum zum Download, wenn man bei 2.7.2 keine Erweiterungen mehr installieren konnte. Leider finde ich diese Datei nicht mehr. Kann mir jemand weiter helfen?

[MacKP]

Hallo Simon,
in TL 2.7.2 ist das Problem behoben...
Die Datei sollte nicht mehr benötigt werden. Hast also ein anderes Problem.

(Wobei auch in den anderen Versionen das Problem von leo mit einer Server Einstellung umgangen wurde soweit ich mich erinner).

Viele Grüße

[Simon]

Hab die 2.7.2 eben erst neu installiert. Die Installation der Erweiterungen wird zwar laut Ausgabe richtig durchgeführt, jedoch fehlen im Adminmenü die entsprechenden Menüpunkte der Erweiterungen. Bin mir auch relativ sicher, dass es erst mit der 2.7.2 kam.

Ich meine der Hack kam von andreas.schempp. Wie gesagt, es ist alles komplett neu, lässt sich jedoch trotzdem nicht richtig installieren.

Danke für die Hilfe.

[lindesbs]

Schalt mal die Fehlermeldungen wieder ein. Hast Du vorher mal die Rechte kontrolliert ?

[Simon]

Musste den Save-Mode-Hack einschalten, weil er die Dateien nicht geschrieben hat. Warum auch immer. Danke für die Hilfe.