Plugin zum Erstellen von Plugins

  • Hallo.


    Ja der Titel hört sich merkwürdig an, doch das Anliegen ist ernst gemeint ^^


    Ich hatte die Idee, dass man ein Plugin schreibt, dass im ACP eine Art eines kleinen Studios baut, das Plugins verwaltet. Dazu gehört, das Erstellen/Ändern/Löschen von Dateien durch einen Mini-Editor, visuellen XML-Buildern, Versionierung und Paket-Archivierung (.tar und .gz). Dies ist nur eine Vision und hat noch kein festes Vorhaben.


    Ich wollte einfach ein Paar Meinungen dazu einholen und fragen, was ihr als Entwickler davon halten würdet.


    Könnte dies nützlich sein oder ist das eher unpraktisch?


    Falls ein Moderator der Meinung ist, dass dies lieber unter Pluginentwicklung für die Allgemeinheit gehört, kann er das gerne verschieben.


    Gruß


    Sonne

  • Du meinst, dass es für dich als Entwickelr aufwändiger wäre, sowas zu benutzen?


    Wenn ja, weil? Workflow oder andere Gründe?

  • Dachte eher an die Umsetzung eines solchen Systems.


    Sicher gibt es den Ein- oder Anderen, für den das irgendwie von Nutzen sein könnte und wäre. Aber die meisten "Entwickler" haben halt einen gewissen Workflow (fängt ja schon bei der IDE an) und bemerken mit so einer Klicki-Bunti-Lösung allenfalls einen Effizienzverlust. Eine halbwegs ordentliche, sinnvolle und fehlerfreie Umsetzung eines Systems würde sicher Monate dauern, wenn nicht sogar länger und für die 10 Leute, die es am Ende wirklich nutzen, ist's das einfach nicht wert.

  • Was genau stellst du dir denn vor ?
    Auch das Verwalten / anlegen von ELs, useroptions usw ?
    Wenn ja fänd ich es ne super sache, finde das immer nervig wenn man nen Paket wegen einer kleinen Änderung erst mal neu packen muss ums dann zu updaten.

  • Was genau stellst du dir denn vor ?
    Auch das Verwalten / anlegen von ELs, useroptions usw ?
    Wenn ja fänd ich es ne super sache, finde das immer nervig wenn man nen Paket wegen einer kleinen Änderung erst mal neu packen muss ums dann zu updaten.

    Meine Idee dahinter war nicht, dass man die Plugins beim Entwickeln schon irgendwie direkt automatisch installiert oder sowas. Das könnte eher problematisch werden.


    Das nervige packen wäre trotzdem nötig..nur macht es das System halt selber. Man gibt halt an, welche Daten man packen möchte und drückt auf einen Button und das wird dann gepackt. Man könnte das Paket dann runterladen oder direkt vom System per Link auf das Paket installieren.


    //edit: Generell würde sich daran ja wie bisher nichts ändern. Nur hätte man es mobil, zentral und auch ein wenig spezifischer für das WCF/WBB.

  • Erinnert irgendwie ein wenig an das DevCenter von Plunts. Hin und wieder war das ganz hilfreich.





    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier.

  • Ich würde das ehrlich gesagt feiern wenn es sowas gäbe. Nicht nur weil ich immer beim Packen durcheinander komme, sondern auch immer nie weiß welche Dateien ich noch brauch und in welchem Ordner.


    Man könnte ja sagen, ich will das und das machen, wenns ein BB-Code plugin werden soll das die Dateien und Ordner soweit vorgeschrieben sind, man nurnoch seinen Inhalt reinschreibt und am ende auf Packen und Downloaden klickt.


    Für gewisse Dinge gibt es ja feste Dateien, bspw. für ein weiteres Menü im ACP, ne neue Seite, Berechtigungen usw.

  • Ich würde das ehrlich gesagt feiern wenn es sowas gäbe. Nicht nur weil ich immer beim Packen durcheinander komme, sondern auch immer nie weiß welche Dateien ich noch brauch und in welchem Ordner.


    Man könnte ja sagen, ich will das und das machen, wenns ein BB-Code plugin werden soll das die Dateien und Ordner soweit vorgeschrieben sind, man nurnoch seinen Inhalt reinschreibt und am ende auf Packen und Downloaden klickt.


    Für gewisse Dinge gibt es ja feste Dateien, bspw. für ein weiteres Menü im ACP, ne neue Seite, Berechtigungen usw.

    Naja das wird sich großartig auch nicht ändern... man muss schon wissen, was man macht :P das Plugin wäre nur eine Hilfestellung aber kein Ersatz für Kenntnisse.

  • Eigentlich wollte ich mein Plugin noch den entsprechenden Feinschliff verpassen, aber da hier gerade ein passendes Thema ist, gebe ich hier eine erste Übersicht:


    Das erste halbe Jahr von 2015 habe ich ein Plugin geschrieben, welches genau das macht, was du dir wünschst und vermutlich vieles darüber hinaus. Aktuell kann man damit im ACP Pakete anlegen und dabei alle relevanten Daten für die package.xml angeben (von Paketbezeichner, Name und Beschreibung bis hin zu Copyright; vorausgesetzte, optionale und ausgeschlossene Pakete). Im Anschluss kann man im ACP alles, was über PIPs importiert werden kann, in entsprechenden Formularen anlegen und dem Paket zuordnen: Optionen, Menüs, Listener, Sprachvariablen, Objekt Typen und Definitionen, Dashboard Boxen und eben alles andere, was man über PIPs importieren kann. Die Wahl der IDE wird durch mein Plugin nicht eingeschränkt. Man kann entweder direkt in einer WCF / WBB Installation arbeiten oder kann die Pakete auch in eigenen Verzeichnissen entwickeln und trotzdem live(!) testen, da ja sowohl die ganzen PIP Einträge in der Datenbank stehen als auch die Dateien vorhanden sind. Ist man fertig mit seinem Paket, kann man es mit einem Knopfdruck vollständig exportieren und hat das gepackte und installierbare Archiv. Ändert man jetzt etwas am Paket, werden die Änderungen mitverfolgt und beim nächsten Exportieren des Pakets werden automatisch die Update Anweisungen erstellt. Kurzum: Man bekommt als Entwickler, wenn man das möchte, keine eine .xml Datei zu sehen geschweige denn das innere des Paket Archivs.


    Nun der Grund, warum ich es noch nicht veröffentlicht habe: Ich würde das Plugin gerne kostenlos anbieten, damit es alle Entwickler für das WCF leichter haben und zudem die exportieren Pakete durch die Automatisierung weniger Fehler beinhalten. Auf der anderen Seite bin ich noch eine Weile Student und könnte Einnahmen aus dieser Arbeit gut gebrauchen, da die Zeit, welche ich in das Plugin investiert habe nicht gerade wenig war und ich logischerweise damit nichts verdient habe. Daher war meine Idee, dass ich mit dem fertigen Paket an WoltLab herantrete und frage, ob sie es mir abkaufen - quasi für die Allgemeinheit freikaufen. Haltet ihr das für realistisch? Ich würde es halt sehr gerne kostenlos für die Entwickler anbieten, da es das Arbeiten wirklich unendlich viel leichter und angenehmer macht, gerade für Neueinsteiger, welche noch keinen richtigen WCF Workflow haben.


    Kurz: Glaubt ihr es ist möglich, dass WoltLab mir das Plugin für einen einmaligen Preis abkauft (falls sie es für gut befinden), um es dann seiner Entwickler Community kostenfrei anbieten zu können?

  • Kurz: Nein, ich glaube nicht.


    Für WoltLab ist das bisherige Verfahren ganz gut und damit sind auch keine Kosten verbunden. Nachfragen kannst du immer noch unter woltlab@woltlab.com .


    Aber schön zu wissen, das jemand anders auch auf diese Idee gekommen ist :)


    Würde mich freuen, wenn du dies freigeben könntest oder ein Abnehmer sich findet.

  • Mal schauen, ob ich sie mit einem entsprechend guten Produkt überzeugen kann. Der Vorteil für WoltLab liegt schließlich klar auf der Hand: Neueinsteiger und auch fortgeschrittene Entwickler, welche aber noch keinen für sich zufriedenstellenden Workflow aufbauen konnten, können mit einem Plugin von WoltLab ihre lokale Installation des WCF zu einer Art Entwicklungsumgebung umfunktionieren. Es gibt potentiell mehr Entwickler, es gibt schneller und sauberer entwickelte Plugins, also insgesamt mehr Plugins im Pluginstore. Das wiederum kann zu mehr Kunden führen, da sie das WCF/WBB ihren Bedürfnissen durch die Vielfalt der Plugins anpassen können, und natürlich zu mehr Einnahmen aus dem Pluginstore. Es könnte also durchaus eine Investition Wert sein. Ich verstehe sowieso nicht, wieso WoltLab die Entwickler doch ziemlich ins kalte Wasser springen lässt mit dem WCF 2.X. Neben der Wiki, welche glaube ich auch nicht mehr fortgeführt wird, gibt es doch keinerlei aktuelle Dokumentation oder Entwicklerhilfe, oder?


    Übrigens kann man auch problemlos bestehende Pakete in mein Plugin einpflegen und von da an dort weiterentwickeln und exportieren ;)

  • @Sonnenspeer


    Bisher noch nicht. Ich habe noch eine automatische Versionierung der Datenbank hinzugefügt, sodass man nicht mehr mit phpMyAdmin oder ähnlichem die Tabellen für die eigenen Plugins anlegt, sondern direkt im Projekt Manager. Hat man bereits eine Version des eigenen Plugins exportiert und ändert nun etwas an der Datenbank, benennt beispielsweise eine Column um oder fügt einer Tabelle eines fremden Packages eine Column hinzu, löscht eine eigene Tabelle etc. wird dies alles automatisch verfolgt und die entsprechenden Updateroutinen in das neue Paket eingebaut. Man muss auch überhaupt nicht mehr beachten, was die SQLParser Klasse im WCF für Queries annimmt und welche nicht, da die GUI des Projekt Managers nur die Eingaben zulässt, welche das WCF letztendlich auch annimmt.


    Da es noch immer ein paar kleinere TODOs gibt und ich mit meiner Community gerade auf das WCF2 und WBB4 umziehe, kann ich noch nicht genau sagen, wann ich eine rundum gut funktionierende Version zur Vorschau an WoltLab schicken kann. Hat man allerdings den Thread Ausblick WoltLab Community Framework 2.2 verfolgt, sieht man ja, wie groß das Interesse seitens der Entwicklercommunity an Unterstützung durch WoltLab ist.
    Vielleicht ist mein Entwickerplugin ja genau der erste Schritt :)


    Ich hoffe es bis Mitte November zu schaffen, eine gut funktionierende Version samt Angebot an WoltLab zu schicken. Je nach dem, wie sich WoltLab entscheidet und wie schnell es dann geht, könnte es entsprechend dieses Jahr noch klappen.

  • Ich finde so ein Plugin wirklich sehr interessant. Auch wenn ich habe mir bereits ein Script geschrieben welches mir meine Plugins packt, klingt dein Tool aber so verführerisch, dass ich geneigt wäre umzusteigen.


    Bezüglich deines Konfliktes Geld verdienen zu wollen, aber andererseits dein Werkzeug für alle Entwickler kostenfrei zur Verfügung zu stellen, hätte ich ein paar Denkanstöße:


    Zum einen ist da die Größe des Marktes. Aktuell gibt es -nach meiner Schätzung- etwa 2-3 Dutzend Plugin Entwickler, davon wird mehr als die Hälfte bei ihrem System bleiben wollen. Wenn Woltlab irgendwann tatsächlich ernsthaftes Interesse bekäme, dass WCF bekannter zu machen und den Einstieg in die Entwicklung vereinfachen möchte, dann wird die Zahl sicher steigen, aber niedrig dreistellig bleiben. Das Problem: Muss man für dein Plugin bezahlen, werden es viele Neueinsteiger ignorieren. Wer will schon für den Einstieg in ein Framework Geld bezahlen?


    In deinem Sinne hoffe ich auf die Einsicht von Woltlab, dass man nicht mehr Features braucht, sondern eine lebendige Entwicklergemeinschaft. Sollte das aber nicht geschehen, dam solltest du dir überlegen, dein Plugin in zwei Versionen anzubieten:


    Die Community Edition
    Kostenfrei. Voll Funktionsfähig. Setzt aber hinter bzw. neben das Coypright "erstellt mit ramius SuperPluginPackGedöns". Zudem verbietet deine Nutzungslizenz die Erstellung kommerzieller Plugins.


    Die Professional Edition
    Kostenpflichtig. Setzt keine Copyrightergänzung, kommerzielle Plugins erlaubt.


    Eine dritte Variante wäre, wenn man einen Internetdienst für Woltlab Entwickler anböte.
    Mit einem Wiki, Blog und Forum. Dort kümmert sich die Community hauptsächlich um die noch fehlende Dokumention. Das Plugin ist online verfügbar, dafür erhält aber jeder Entwickler Zugriff auf ein Weblaufwerk auf denen per symlink WCF + X verfügbar sind. Zugang zur eigenen Datenbank und einer Testinstallation runden das Angebot ab und erleichtern den Einstieg enorm. Niemand braucht mehr einen eigene Testumgebung.


    Finanziert über Werbung, Premium Mitgliedschaften, extra Serviceleistungen, auch sollte Woltalab als Sponsor / Werbepartner einspringen. Nachteil und Gründe warum so etwas nicht funktioniert: Woltlab müsste alle kostenpflichtigen Produkte als Testversionen freigeben, da jeder Benutzer eine Instanz zur Verfügung hat. Jemand müsste die Anfangsinvestition übernehmen. Zudem steht und fällt das ganze mit der Bereitschaft der Community alles Wissen zusammenzutragen und zu sortieren.

  • Das Problem: Muss man für dein Plugin bezahlen werden es viele Neueinsteiger ignorieren, wer will schon für den Einstieg in ein Framework Geld bezahlen?

    Das ist genau der Punkt. Der Einstieg soll ja leichter und nicht schwerer werden.


    Voll Funktionsfähig. Setzt aber hinter bzw. neben das Coypright "erstellt mit ramius SuperPluginPackGedöns". Zudem verbietet die Nutzungslizenz die Erstellung kommerzieller Plugins. Kostenfrei

    Einen solchen Hinweis halte ich für verkehrt. Wenn man ein Plugin wie einen TeamSpeak3 Viewer oder eine Shoutbox anbietet, ergibt so ein Hinweis sicherlich Sinn, da jeder Nutzer auch ein potentieller Kunde ist. Hingegen sehe ich nicht, wenn bei einem TS3 Viewer oder einer Shoutbox steht, dass diese Plugins mit meinem Plugin erstellt wurden, wem dieser Hinweis weiterhelfen soll, außer vielleicht meinem Ego 8o


    Eine Unterteilung in zwei Versionen oder besser gesagt in das Produkt selbst und zusätzlich eine Lizenz zum kommerziellen Nutzen des Projekt Managers halte ich wiederum für in Ordnung. Natürlich setzt das ein gewisses Vertrauen voraus, dass zumindest ein Teil, welcher kommerzielle Plugins damit erstellt, auch die Lizenz kauft.


    Eine dritte Variante wäre, wenn man einen Internetdienst für Woltlab Entwickler anböte. Mit einem Wiki, Blog und Forum. Dort kümmert sich die Community hauptsächlich um die noch fehlende Dokumention.

    Das wäre sicherlich auch unabhängig vom Projekt Manager eine gute Sache.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!