Erweiterung in der Managed-Edition installieren

[WebRoxx]

Hallo,

ich möchte mich jetzt mit den Erweiterungen für Contao 4 beschäftigen. Bevorzugt nutze ich allerding die Managed-Edition.

Leider sehe ich hier nicht wirklich ein Stich was ich wie und wo anlegen muss :/

https://docs.contao.org/books/extend...naged-edition/

Klar könnte ich meine Erweiterung die 3.x.x ready ist auch in Contao 4 nutzen aber ich würde schon gern eher auf die neue Strucktur umsteigen

Wäre fürs Gedanken anstoßen sehr dankbar

[BugBuster]

Ein Ansatz wäre das hier:
https://docs.contao.ninja/de/erweiterung-c3-c4.html

[WebRoxx]

Oh cool. Werde ich mir anschauen

[WebRoxx]

Eine Frage habe ich da gleich.

So wie es aussieht soll man es ja in den Ordner "src" legen. Nur was ist wenn ich mehrere Erweiterungen habe?

[BugBuster]

Das ist je Erweiterung. In dieser Anleitung geht es nicht darum, eine Erweiterung direkt in Contao 4 zu entwickeln.
Das geht auch, ist hier im Forum irgendwo schon mal beschrieben worden. Dazu muss man aber noch ein wenig mehr vom Symfony Konzept wissen.

Ich habe ein Verzeichnis /entwicklung/demobundle/ und darin lege ich dann die ganze Struktur an.
Später, wird auch in den Folien gezeigt, sage ich dann per Composer, er soll das ganze in meine Contao Installation installieren (entweder alles lokal, oder wie üblich über GitHub/GitLab/Bitbucket/... + Packagist)

[WebRoxx]

Okay,

jetzt bin ich aber ewtas verwirrt. Wenn ich nicht in COntao 4 entwickeln kann wo dann?


Hätte jetzt eher gedacht das geht so in der Art

src/MeinExtesion1Bundle
src/MeinExtesion2Bundle
etc.

Okay da muss ich mal im Forum schauen

[BugBuster]

jetzt bin ich aber etwas verwirrt. Wenn ich nicht in Contao 4 entwickeln kann wo dann?

Na eben außerhalb und dann instrallieren lassen.
Bei Contao 3 ging das noch darin, da die Erweiterungen auch dort landeten /system/modules/...) wo man diese entwickelte. (aber auch hier nicht zwingend musste)
In Contao 4 landen aber die installierten Erweiterungen alle unter vendor/<vendorname>/<paketname>/...

Es gibt in Contao 4 auch Erweiterungen die nur für diese eine Installation gelten, die kann man dann direkt darin anlegen.

Kommt also ganz drauf an, was du vorhast.

[WebRoxx]

In der Regel sind es Erweiterungen die nur für die eine Installation gelten.

Würde allerdings dennoch den Weg über das Vendor verzeichnis gehen. Also dann doch deinen Vortrag einfach mal durchgehen

Da ist es aber Wurst ob Standart oder Managed-Edition ?

[BugBuster]

Da ist es aber Wurst ob Standart oder Managed-Edition ?

Eine Erweiterung die für die Manged Edition entwickelt wurde, funktioniert auch in der Standard Edition. Dort muss man dann aber händisch nach der Installation noch in Symfony Eintragungen machen.

[WebRoxx]

Also mal ganz doof gefragt.

Für was sollte man denn Entwickeln. Ich komme mit diesen 2 Versionen einfach nicht klar
Wenn ich das richtig versteh gibts es ja jetzt mittlerweile 3 Wege für Erweiterungen

Standart-Edition
Managed-Edition
oder eben die 3er Extension Contao 4 ready machen

Ist irgendwie verwirrend

[BugBuster]

Die 3er Extension für Contao 4 ready machen, würde ich nur tun, wenn es schnell gehen soll oder man eben keine Lust hat zwei Erweiterungen getrennt zu pflegen. (eine für Contao 3 und eine für 4)

In der Bundle Struktur besteht die Managed Edition kompatible Version nur aus einer einzigen Datei (Klasse) mehr und eine kleine Zeile in der composer.json.
Der Aufwand ist also verschwindend gering.
Von daher würde ich immer für Managed Edition entwickeln.

[BugBuster]

Nachtrag: die "kompatible" Variante funktioniert nicht in Contao 5. Ist zwar noch ne Weile hin, aber von daher habe ich alle meine Erweiterungen neu als Bundle angelegt um daraus dann Stück für Stück mich an Symfony anzunähern.

Es gibt auch ne Anleitung wie man Erweiterungen gleich in Symfony Manier schreibt. Siehe Link in meinen Folien.

[webstar]

Ergänzend zu bugbusters Worte: wenn man für die managed edition entwickelt, ist man automatisch auch für für Standard Edition kompatibel.

Da muss halt nur der Nutzer der Erweiterung mehr hand anlegen bei der Konfiguration

[WebRoxx]

Ah okay. Das ist schon mal gut zu wissen

Dann werde ich das wohl auch so machen. Eigentlich scheint ja auch nur das "einrichten/installieren" das kompliziertere zu sein. Der Reste (DCA usw) ist ja so geblieben.

[WebRoxx]

Okay. Nachträge jetzt erst gelesen ^^

Da ich mich arbeitsbedingt eh mit Symfony beschäftigen muss passt es ja.

Frage trotzdem nochmal wie genau man außerhalb entwickeln soll. Also wenn ich zum Beispiel die contao Events etc erweitern will brauch ich ja eine contao Installation egal ob Local oder auf dem Server :/

Das ist mir Grad noch ne ganz klar.

[BugBuster]

Bei mir ist das durch meine IDE gelöst, ich lege da ein Projekt an wo nur die Struktur meiner Erweiterung liegt, und gebe als include Pfad eine lokale Contao 4 Installation an.
Die IDE parst dann alles durch und ich kann dadurch auf alles Zugreifen und habe Dinge wie Syntax Vervollständigung und sowas.

[WebRoxx]

Okay, geht es denn auch ohne IDE ?

Würde mich interessieren, werden doch schon einige was entwickeln

[webstar]

Okay, geht es denn auch ohne IDE ?

Würde mich interessieren, werden doch schon einige was entwickeln

Geht es dir darum, dass du in der IDE weißt, welche Mathoden und Klassen zur Verfügung stehen oder um das Testen?

Für ersteres: Ich installiere mir in jedem Projekt die Abhängigkeiten über composer. Eine zentral verwaltete Bibliothek, wie Bugbuster es sagt, hat sich bei mir nicht durchgesetzt, da halt unterschiedliche Abhängigkeiten bestehen.

Für letzteres: Ich nutze dafür eine Testsinstallation, in dem ich mir das Entwicklungspaket installiere. Composer bietet dafür die Möglichkeit in der Installation Repositories zu definieren. Interesannt sind die Typen path und vcs. Bei path kannst du die Option symlink setzen. D.h., wenn du etwas aktualisierst in deiner Entwicklung ist es in der Testinstallation auch geändert.

• https://getcomposer.org/doc/05-repositories.md#path
• https://getcomposer.org/doc/05-repositories.md#vcs

Ob path inzwischen im Contao Context einwandfrei funktioniert, kann ich nciht sagen. Ich hatte damit Probleme, da dann die Pfade zu Templates usw. falsch erzeugt werden - aber in meinem Kontext kommt noch Docker zum Einsatz.

[WebRoxx]

Also langsam ist mir das leider etwas zu verwirrend.

Warum kann man nicht einfach sich ein Contao installieren und darin entgwickeln so wie in der 3er? Der Weg sollte doch denke ich auch gehen, oder ist das wirklich garnicht möglich ?

[do_while]

Ich habe das so gemacht.

Meine Erweiterung habe ich in der Struktur für Managed-Edition auf GitHub vorbereitet, die entsprechenden Dateien erstellt.
Dann habe ich dieses Gerippe über Packagist als Developerversion bei mir installiert.
Mit einem normalen Editor kannst Du jetzt in den Dateien die Funktionalität der Erweiterung einbauen/anpassen. Wenn alles soweit läuft, schiebst Du den Stand wieder zu GitHub hoch.
Erweiterung deinstalliert und den neuen Stand installiert und getestet.

Wenn alles läuft, kommt alles in den Master und wird getagt. Dann ist die Erweiterung offiziell über Packagist verfügbar.
(Kurzfassung )

[BugBuster]

Für ersteres: Ich installiere mir in jedem Projekt die Abhängigkeiten über composer. Eine zentral verwaltete Bibliothek, wie Bugbuster es sagt, hat sich bei mir nicht durchgesetzt, da halt unterschiedliche Abhängigkeiten bestehen.

Hatte ich auch mal, nur hat man dann alles im vendor Verzeichnis innerhalb deiner Erweiterung zu liegen. Und wen nich 20 Erweiterungen habe, dann 20 mal Contao. Das wurde mir irgendwann mal zu viel.

Für letzteres: Ich nutze dafür eine Testsinstallation, in dem ich mir das Entwicklungspaket installiere. Composer bietet dafür die Möglichkeit in der Installation Repositories zu definieren. Interesannt sind die Typen path und vcs. Bei path kannst du die Option symlink setzen. D.h., wenn du etwas aktualisierst in deiner Entwicklung ist es in der Testinstallation auch geändert.

• https://getcomposer.org/doc/05-repositories.md#path
• https://getcomposer.org/doc/05-repositories.md#vcs

Ob path inzwischen im Contao Context einwandfrei funktioniert, kann ich nciht sagen. Ich hatte damit Probleme, da dann die Pfade zu Templates usw. falsch erzeugt werden - aber in meinem Kontext kommt noch Docker zum Einsatz.

Das habe ich so (beides) in Betrieb, ist auch in den Folien so beschrieben.

[BugBuster]

Also langsam ist mir das leider etwas zu verwirrend.

Warum kann man nicht einfach sich ein Contao installieren und darin entgwickeln so wie in der 3er? Der Weg sollte doch denke ich auch gehen, oder ist das wirklich garnicht möglich ?

Du musst einen Weg für Dich finden der praktikabel ist.
Du könntest z.B. die Erweiterung in GitHub anlegen, die nur aus einer composer.json und einer readme besteht, diese dann installieren lassen in deiner lokalen Contao Installation (über vcs Angabe in der composer.json) und dann direkt in den installierten Pfaden entwickeln. Und irgendwie das dann wieder zu GitHub zurück spielen. Machbar, aber schräg. (Cache Problematik)

[WebRoxx]

Also Fakt ist schonmal das anscheind nicht um den composer herrum kommt?

Auf GitHub kann ich ja nicht mal eine private anlegen ohen dafür zu zahlen. :/

Also so ganz geheuer ist mir das alles irgendwie noch nicht ich find das macht das "schnelle" erweitern von Contao echt verzichtungswert :/

[mandrake]

Also Fakt ist schonmal das anscheind nicht um den composer herrum kommt?

Auf GitHub kann ich ja nicht mal eine private anlegen ohen dafür zu zahlen. :/

Also so ganz geheuer ist mir das alles irgendwie noch nicht ich find das macht das "schnelle" erweitern von Contao echt verzichtungswert :/

Als Alternative zu GitHub bietet sich GitLab oder Bitbucket an. Bei beiden Anbietern kannst Du private Repositories kostenfrei nutzen.

[WebRoxx]

Okay. Aber wahrscheinlich doch erstmal in den Composer einlesen. Brauchte ich bisher noch nie geschweige denn großartig mit Console arbeiten war nie gefordert

[WebRoxx]

So habe mir jetzt eine SSH Verbindung auf dem Server eingerichtet.

Wie kann ich denn jetzt eine Erweiterung zumb Beispiel das xing-bundle von BugBuster installieren?

Kann man auch Erweiterung von einen eigenen Webspace holen und installieren also ohne GitHub und co?

[BugBuster]

Xing: ist hier beschrieben, je nach dem was du hast und was du kannst:
https://github.com/BugBuster1701/con...ALLATION_DE.md

[WebRoxx]

1. composer require "bugbuster/contao-xing-bundle" woher weiß denn Contao wo es suchen muss?
2. wenn ich es gebe composer require "bugbuster/contao-xing-bundle" sagt es mir composer not found. muss ich den erst installieren? dachte der ist dabei in der mangend edition?

[WebRoxx]

Okay, das eine geht jetzt so php contao-manager.phar.php composer require "bugbuster/contao-xing-bundle"


trotzdem woher weis er das er wo er die findet?

[WebRoxx]

Okay. Hab jetzt erstmal github eingerichtet

Jetzt gibt es ja in der composer.json sicher Pflichtangaben.

Werde mal sehen wie weit ich komme. Wenn es eine Möglichkeit gibt auch von wo anders Extension zu laden wie von einen anderen Server oder so wäre das natürlich für mich besser weil die meisten Extension sind nur für meine Zwecke oder eben später auf Arbeit.

[WebRoxx]

Die Console sagt mir immer:

Could not find package githubuser/test-bundle at any version for your minimum-stability (stable). Check the package spelling or your minimum-stability

githubuser = mein Username klein


meine composer

{
    "name":"githubuser/test-bundle",
    "description":"Contao 4 test Bundle",
    "type":"contao-bundle",
    "license":"LGPL-3.0+",
    "authors":[
        {
            "name":"Ralf",
            "role":"Developer"
        }
    ],
    "require":{
        "php": ">=5.6.0",
        "contao/core-bundle": "~4.4"
    },
    "autoload": {
        "psr-4": {
            "GitHubUser\\TestBundle\\": "src/"
        },
        "classmap": [
            "src/Resources/contao/"
        ],
        "exclude-from-classmap": [
            "src/Resources/contao/config/",
            "src/Resources/contao/dca/",
            "src/Resources/contao/languages/",
            "src/Resources/contao/templates/"
        ]
    }
} 

[BugBuster]

1. composer require "bugbuster/contao-xing-bundle" woher weiß denn Contao wo es suchen muss?

Da es mehr als nur GitHub gibt (Gitlab, Bitbucket, ..) und Composer die nicht alle kennen kann bzw. durchsuchen kann, gibt es eine zentrale Registrierungsstelle Packagist.org.
Dort muss deine Erweiterung registriert sein um per Default dort gefunden zu werden.

Du kannst aber auch, steht in meinen Workshop-Folien, ansagen, dass deine Erweiterung direkt von GitHub geladen werden soll.

[WebRoxx]

"repositories": [
{
"type": "vcs",
"url": "https://github.com/Vendor/demo-bundle"
}
],
"require": {
"vendor/demo-bundle": "dev-develop"
}, 

ist das beides Pflicht? und die URL muss nicht den usernamen enthalten ?

[BugBuster]

"repositories": [
{
"type": "vcs",
"url": "https://github.com/Vendor/demo-bundle"
}
],
"require": {
"vendor/demo-bundle": "dev-develop"
}, 

ist das beides Pflicht? und die URL muss nicht den usernamen enthalten ?

Vendor ist der Username!

    "repositories": [
            {
                "type": "vcs",
                "url": "https://github.com/GithubUser/test-bundle"
            }
        ],
    "require": {
        "githubuser/test-bundle": "dev-develop"
    },

Sofern du von dort den develop Brunch installieren willst.

[BugBuster]

ist das beides Pflicht?

Na Logisch. Das erste sagt ja nur wo ein weiteres Repository zu finden ist.
Das zweite was davon zu installieren ist.

Wie im meinen Folien zu sehen, die Namen können sich auch unterscheiden, in deinem Falle sind die identisch.

[WebRoxx]

Okay da versuche ich das morgen nochmal. :-) melde mich da wieder ;-)

[WebRoxx]

Also hier mal meine komplette composer.json

Es kommt immer noch die Meldung nicht gefunden :/ Was ist denn jetzt falsch?

{
    "name":"githubuser/test-bundle",
    "description":"Contao 4 Test Bundle",
    "type":"contao-bundle",
    "require":{
        "php": ">=5.6.0",
        "contao/core-bundle": "~4.4"
    },
    "repositories": [{
        "type": "vcs",
        "url": "https://github.com/GitHubUser/test-bundle"
    }],
    "require": {
        "githubuser/test-bundle": "*"
    },
    "autoload": {
        "psr-4": {
            "GitHubUser\\TestBundle\": "src/"
        },
        "classmap": [
            "src/Resources/contao/"
        ],
        "exclude-from-classmap": [
            "src/Resources/contao/config/",
            "src/Resources/contao/dca/",
            "src/Resources/contao/languages/",
            "src/Resources/contao/templates/"
        ]
    }
} 

[alexgr]

Also hier mal meine komplette composer.json

Es kommt immer noch die Meldung nicht gefunden :/ Was ist denn jetzt falsch?

Du hast einmal oben

"name":"githubuser/test-bundle", 

und dann weiter unten

"require": {
    "githubuser/test-bundle": "*"
}, 

stehen. Wenn das die composer.json Deiner Erweiterung ist, dann requiret die Erweiterung jetzt sich selbst, was ja so nicht gewollt sein kann. Das require und die Github-Quelle unter repositories gehören in die Contao-composer.json, die im Root Deiner Contao-4-Installation liegt. Nur das name steht in der composer.json Deiner Erweiterung. Wenn das alles so stimmt wie beschrieben und es trotzdem nicht geht, dann poste bitte sowohl die composer.json Deiner Erweiterung als auch die composer.json Deiner Contao-Intallation.

[WebRoxx]

Mh okay,

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0+",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "require": {
        "php": ">=5.6.0",
        "contao/calendar-bundle": "^4.4",
        "contao/comments-bundle": "^4.4",
        "contao/faq-bundle": "^4.4",
        "contao/listing-bundle": "^4.4",
        "contao/manager-bundle": "4.4.*",
        "contao/news-bundle": "^4.4",
        "contao/newsletter-bundle": "^4.4",
        "madeyourday/contao-rocksolid-columns": "^2.0",
        "madeyourday/contao-rocksolid-custom-elements": "^2.0",
    "githubuser/test-bundle": "*"
    },
    "repositories": [ {
        "type": "vcs",
        "url": "https://github.com/GitHubUser/test-bundle"
    }
    ],
    "conflict": {
        "contao/core-bundle": "<4.4.1"
    },
    "config": {
        "component-dir": "assets"
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    },
    "autoload": {
        "classmap": [
            "app/ContaoManagerPlugin.php"
        ],
        "psr-4": {
            "AppBundle\\": "src/AppBundle/"
        }
    }            
} 

{
    "name":"githubuser/test-bundle",
    "description":"Contao 4 Test Bundle",
    "type":"contao-bundle",
    "require":{
        "php": ">=5.6.0",
        "contao/core-bundle": "~4.4"
    },
    "autoload": {
        "psr-4": {
            "GitHubUser\\TestBundle\": "src/"
        },
        "classmap": [
            "src/Resources/contao/"
        ],
        "exclude-from-classmap": [
            "src/Resources/contao/config/",
            "src/Resources/contao/dca/",
            "src/Resources/contao/languages/",
            "src/Resources/contao/templates/"
        ]
    }
} 

So oder wie? Meldung kommt nach wie vor

[alexgr]

Ja, das sieht jetzt nach der richtigen Struktur aus. Jetzt müsste nur noch dieser Teil der Meldung relevant sein:

[…] for your minimum-stability (stable). Check […] your minimum-stability

Da Deine Erweiterung vermutlich noch keinen Release-Tag hat, erkennt Composer die Stabilität Deiner Erweiterung als dev. Standardmäßig, d. h. wenn keine andere minimum-stability in der Root-composer.json steht, will Composer nur Pakete installieren, die er als stable erkennt. Für die Entwicklung kannst Du erst mal ein Stability Flag in dem require verwenden:

"githubuser/test-bundle": "@dev" 

Mit dem Stability Flag kannst Du für bestimmte Pakete die minimum-stability erweitern oder einschränken. In diesem Fall erweiterst Du sie auf dev. Mehr zum Thema:
https://getcomposer.org/doc/04-schema.md#package-links
https://getcomposer.org/doc/articles...ty-constraints