Bin verzweifelt: Wie erstelle ich eine Erweiterung für Contao 4.x

Hiho!

Ich bin gerade verzweifelt!

Ich habe vor Jahren eine Homepage mit Contao erstellt (http://www.rodgauer-workshop.de/). Die ist nun schon extrem in die Jahre gekommen. Und deswegen wollte ich sie neu aufbauen und modernisieren.

Und nachdem mir damals Contao so gut gefallen hat, und so gut gefallen hat, wollte ich wieder Contao nehmen, und möglichst ein aktuelles, Zukunftssicher zu sein. Das hat eigentlich auch gut geklappt, und der erste "Proof Of Concept" steht bereits (http://rodgau.testspace.de/).

Bis hier hin war ich total glücklich, alles ging recht einfach, ich bin mit Boardmittel weit gekommen. Und die Erweiterung "Rocksolid Custom Elements" hat mir sehr geholfen.

Und nun geht das Problem los! Ich bin schon seit Abenden am Suchen, Googlen und lesen. Ich habe damals auch zwei kleine Erweiterungen geschrieben. Die eine trägt einen User, der sich zum Newsletter anmeldet oder abmeldet in meinem CiviCRM ein. Die andere war ein spezielles Feld für den Formbuilder um eine Art "Colorizer" zu realisieren!

Ich war damals unglaublich begeistert, wie leicht sich Contao erweitern lies!

Jetzt versuche ich die Erweiterungen neu zu bauen, für Contao 4.x. Und ich bin total verzweifelt! Ich habe keine Vorstellung, wie das geht. Ich hab schon einiges an Folien gelesen, Videos geguckt, aber ich werde da nicht schlau! Da werden Dateien erwähnt, die ich nicht finde, Aufrufe gemacht, die ich nicht machen kann, weil die Scripte nicht da sind. Da spielen scheinbar 1000 Dateien zusammen, ich steh komplett im Wald. Ich hab noch nicht mal eine Idee, wie ich anfangen kann, um ich von Fehler zu Fehler vorzuhangeln.

Muss ich mich wirklich komplett in Symphonie einarbeiten, um Contao zu erweitern? Ist Contao 4.x echt zur Zeit nur für Profientwickler? Ich bin nur ein Hobbyfriggler, bin ich jetzt außen vor?

Wo finde ich Infos, die ich verstehen kann? Beispielcode? Etwas einfaches, das mir eine Richtung gibt?

Wie gesagt, ich bin verzweifelt! Ich möchte auch nicht wegwerfen, was ich bisher habe, und mit einem anderen CMS neu anfangen... vor allem, weil mir keines sonst so gut gefällt.

Tschüss
Marcus (aka Tiggr)

Contao 3 Erweiterungen sind mit Contao 4 kompatibel. Du kannst also ohne weiteres deine Erweiterung genau so für Contao 4 programmieren wie für Contao 3, wenn du kein Bundle programmieren möchtest. Natürlich gibt es ein paar Unterschiede, die zu beachten sind. Siehe zB https://github.com/contao/core-bundl...ter/UPGRADE.md

Hallo!

Das ist schon mal ermutigend, aber meine alte Seite läuft noch unter Contao 2.10 - ja, ich habe da echt lange nichts mehr gemacht! :-D Hat sich von 2 zu 3 viel getan?

Wie installiere ich unter 4.x eine 3er-Erweiterung?

Aber ganz ehrlich, ich fände es einfach sauberer, wenn ich da neue Bundles erstellen würde. Aber damit komme ich sowas von garnicht klar! Wobei ich glaube, ich brauch nur einen Tritt in den ..., damit ich in die richtige Richtung losstolpere!

Mein größtes Problem ist zur Zeit: Wie bringe ich Contao dazu, eine Erweiterung zu nutzen. Wenn sie erstmal irgendwie geladen wird, dann würde ich mich von Fehler zu Fehler entlanghangeln! Ich bräuchte sowas wie ein leeres Gerüst für eine Erweiterung.

Das schlimme für mich ist: Jede Anleitung, die ich finde, beschreibt das etwas anders, bringt andere Dateien und andere Strukturen ins Spiel!

Tschüss
Marcus

Wenn es auch nicht schädlich ist, sich in Symfony einzuarbeiten, ist es meiner Ansicht nach nicht zwingend notwendig. Du musst nur zwei Dateien anlegen und kannst dann (erstmal) arbeiten wie unter Contao 3.

Du legst ein Bundle (Ordner) in /src an. Nennst Du Dein Bundle AppBundle (wie von Symfony vorgeschlagen), wird es von Contao auch automatisch (glaube ich) erkannt. Du kannst aber auch einen beliebigen anderen Namen wählen (gefällt mir besser). Diese Vorgehensweise beschreibe ich mal hier.

Meine Beschreibung bezieht sich auf eine Erweiterung, die nicht auf Github veröffentlicht wird, sondern nur im eigenen Projekt verwendet wird. Das Schreiben von Erweiterungen für Github / Packagist weicht teilweise davon ab:

Also:

Anlegen von

/src/DeinName/Test
/src/DeinName/Test/Resources
/src/DeinName/Test/Resources/contao
/src/DeinName/Test/Resources/public

Im Ordner Resources/contao schreibst Du ganz normal deine Erweiterung mit den Ordnern dca, languages, models, modules, etc.
Test kann in diesem Fall der Name deiner Erweiterung sein oder besser ein Namespace-Name. Also eine Bezeichnung, z.B. CRM, wenn es in Deiner Erweiterung um ein CRM geht.

Damit deine Erweiterung als Bundle von Symfony geladen werden kann, benötigst Du noch folgende Datei:
/src/DeinName/Test/TestBundle.php

PHP-Code:

---

<?php

namespace DeinName\Test;

use Symfony\Component\HttpKernel\Bundle\Bundle;

class TestBundle extends Bundle
{
}

---

Ja, die Klasse ist leer. Das ist richtig so.

Damit das Symfony Bundle nun auch von Contao geladen wird, musst Du sie noch bekannt machen. Contao sucht automatisch nach einem globalen ContaoManagerPlugin (und sonst nichts). Mit diesem Plugin registriert man sein(e) Bundle(s).

/src/ContaoManager/ContaoManagerPlugin.php

PHP-Code:

---

<?php

use Contao\ManagerPlugin\Bundle\Config\BundleConfig;
use Contao\ManagerPlugin\Bundle\BundlePluginInterface;
use Contao\ManagerPlugin\Bundle\Parser\ParserInterface;
use Contao\CoreBundle\ContaoCoreBundle;
use DeinName\Test\TestBundle;

class ContaoManagerPlugin implements BundlePluginInterface
{
    public function getBundles(ParserInterface $parser)
    {
        return [
            BundleConfig::create(TestBundle::class)->setLoadAfter([ContaoCoreBundle::class]
            )
        ];
    }
}

---

Wichtig:
Wo Du das ContaoManagerPlugin speicherst, ist völlig egal. Die Klasse muss aber im globalen Namespace stehen, also hier keinen Namespace angeben. Daher speichere ich das ContaoManagerPlugin nicht in meinem Namespace, sondern direkt in /src/ContaoManager/ContaoManagerPlugin.php

TestBundle::class hat übrigens die gleiche Funktion wie "\DeinName\TestBundle"
(die Einen schreiben es so, die anderen so)

Jetzt muss Du noch dafür sorgen, dass deine PHP Klassen auch gefunden werden. Dafür musst Du die composer.json im Root verändern.

Code:

---

"autoload": {
        "classmap": [
            "src/ContaoManager/ContaoManagerPlugin.php",
            "src/DeinName/Test/Resources/contao"
        ],
        "psr-4" : { "": "src/" },
        "exclude-from-classmap": [
            "src/DeinName/Test/Resources/contao/config/",
            "src/DeinName/Test/Resources/contao/dca/",
            "src/DeinName/Test/Resources/contao/languages/",
            "src/DeinName/Test/Resources/contao/templates/"
        ]
    },

---

"src/DeinName/Test/Resources/contao" sorgt dafür, dass alle Deine Klassen unterhalb von Contao (also wie früher) durch den Composer Autoloader "automatisch" (bitte unbedingt unten weiterlesen) erkannt und geladen werden. Solltest Du auf der Ebene /src/DeinName/Test weitere Klassen anlegen (mehr Symfony Style), werden sie durch die PSR-4 Angabe erkannt.

Beispiel:
/src/DeinName/Test/Hooks/InsertTags.php

In der /src/DeinName/Test/Resources/contao/config/config.php

PHP-Code:

---

$GLOBALS['TL_HOOKS']['replaceInsertTags'][] = array('DeinName\Test\Hooks\Inserttags', 'DeineFunktion'); 


---

Damit Deine Klassen auch tatsächlich korrekt geladen werden, ist zwingend auf der Console folgendes auszuführen:

Code:

---

composer dump-autoload

---

Dieser Befehl durchsucht Deine Ordner, registriert Deine Klassen und speichert sie in ein paar Dateien, damit nicht bei jedem Aufruf alle Verzeichnisse durchsucht werden müssen.
Nachdem Du Dein Modul eingerichtet hast, musst Du einmal den Befehl

Code:

---

composer install

---

ausführen. Contao klingt sich in diesen Composer Befehl rein und führt ein paar Scripte aus, z.B. werden ein paar Symlinks generiert. Alle deine öffentlichen Dateien zum Modul landen ja in /web. In Deinem Fall in
/web/bundles/test

Solltest Du also in Deiner Erweiterung Pfade z.B. für Icons angeben, ist der richtige Pfad:
bundles/test/icon.png


Jetzt beginnt Deine Arbeit mit der Modul-Entwicklung. Contao 3 weicht aber nicht ganz unerheblich von Contao 2 ab. Also die Grundsystematik ist schon geblieben. Aber hier kannst Du Dir wie früher auch viel bei anderen Erweiterungen abschauen.

Und wenn Du doch eine Erweiterung machen willst die auf GitHub liegt und über Composer / Contao Manager installierbar sein soll,
und du Contao 3 Erweiterungen schreiben beherrscht, dann gibt es hier Folien eines Workshops der dir den Umstieg verdeutlicht.
Also wie mache ich aus einer Contao 3 Erweiterung ein Contao 4 Bundle, was ebenso wie oben noch das Contao Framework nutzt und die Symfony Dinge mitbringt, damit es Contao Managed Edition kompatibel wird.
https://docs.contao.ninja/de/erweiterung-c3-c4.html

Muss man den Ordner src/ manuell erstellen? Ich habe den z.B. nicht. Habe nur:

• app
• assets
• contao-manager
• files
• system
• templates
• var
• vendor
• web

Du musst alles manuell erstellen. Auch das Auto Loading für den src/ Ordner.

Warum habe ich keinen src-Ordner, obwohl schon ein gutes Dutzend (fremde) Bundles installiert sind? Allerdings alle z.B. unter /vendor/Spitzname/Bundlename/src.

Ja, ich habe auch mindestens 50 src/ Ordner, aber alle nicht im Root.

Zitat:

---

Zitat von Samson1964

Warum habe ich keinen src-Ordner, obwohl schon ein gutes Dutzend (fremde) Bundles installiert sind? Allerdings alle z.B. unter /vendor/Spitzname/Bundlename/src.

---

Composer installiert Pakete in den /vendor Ordner.

Hallo!

Vielen Dank für die ausführliche Antwort. Das hat mir geholfen! So klar und kompakt hatte ich das bisher noch nicht gefunden! Dann weiß ich ja, was ich heute Abend probieren werde!

Das fehlende src-Verzeichnis hat mich übrigens auch schon verwirrt. :-D

Tschüss
Marcus (aka Tiggr)

Hiho!

Nochmal Danke! Irgendwie hat die Beschreibung wirklich geholfen. :-) Ich hab mit dem Colorizer angefangen, und Backend steht schon:

Anhang 20090

Frontend braucht noch etwas Arbeit beim Design, aber Funktion ist schon da:

Anhang 20091

Danke für die Hilfe!

Tschüss
Marcus (aka Tiggr)

Ich hänge mich hier nochmal ran, weil ich jetzt ernst machen will mit der Bundle-Entwicklung unter Contao 4.4/4.5. Ich entwickle auf meinem Hosting-Server mit einer frischen 4.5er Installation. Ich will das Bundle später auf GitHub hochschieben, so daß man es über Composer installieren kann. Wo muß ich denn nun meine Dateien anlegen? Im noch nicht existenten Ordner src (ich habe nur Anleitungen dazu gefunden) oder im Ordner vendor (hierzu leider keine Anleitungen)?

Nie in vendor, denn dort installiert später composer deine Erweiterung rein, wenn du die auf GitHub gelegt hast.

Ich entwickle die ganz normal in meinem Entwicklungs Verzeichnis (außerhalb von Contao).

Im src/ Verzeichnis ginge das im Prinzip auch, macht aber die spätere Installation über Composer + GitHub kompliziert, denn dann hättest du die ja zweimal drin.
Spätestens dann müsstes du die aus src/ entfernen, damit löscht du dann aber quasi deine Entwicklung.

Du solltest dann die Entwicklung auch per git verwalten, falls du das nicht eh schon tust.

Dann kannst du z.B. auch über composer direkt aus deinem Entwicklungspfad die Erweiterung installieren lassen, ohne über GitHub zu gehen (vorerst).
https://docs.contao.ninja/de/vortrag...dle.html#/16/1

Später dann direkt von GitHub ohne Packagist.org ginge auch:
https://docs.contao.ninja/de/vortrag...undle.html#/16

Zitat:

---

Zitat von BugBuster

Nie in vendor, denn dort installiert später composer deine Erweiterung rein, wenn du die auf GitHub gelegt hast.

---

Ja, habe ich auch schon gelesen.

Zitat:

---

Zitat von BugBuster

Ich entwickle die ganz normal in meinem Entwicklungs Verzeichnis (außerhalb von Contao).

---

Ein stinknormaler Ordner, egal wo? Aber man schreibt doch ein paar Codezeilen, testet dann und macht weiter. Wie soll das Testen gehen, wenn ich nicht in der Contao-Ordnerstruktur drin bin?

Zitat:

---

Zitat von BugBuster

Im src/ Verzeichnis ginge das im Prinzip auch, macht aber die spätere Installation über Composer + GitHub kompliziert, denn dann hättest du die ja zweimal drin.
Spätestens dann müsstes du die aus src/ entfernen, damit löscht du dann aber quasi deine Entwicklung.

---

Das ist natürlich blöd. Ich könnte ja aber theoretisch dann in vendor weiterentwickeln, statt in src. Die ganzen Anleitungen geben an, man soll in src sein Bundle anlegen und coden.

Zitat:

---

Zitat von BugBuster

Du solltest dann die Entwicklung auch per git verwalten, falls du das nicht eh schon tust.

---

Ja, will ich dann machen. Es würde ja dann ein Ordner src/.git mit angelegt werden.

Des Weiteren komme ich noch nicht ganz klar, wohin diese ContaoManagerPlugin.php oder Plugin.php hin soll. Und welche composer.json gemeint ist. Siehe https://gist.github.com/joergmoldenh...02760e4506b86a
Am liebsten würde ich beide Dateien direkt im Bundleverzeichnis mit drin haben.

Im src/ Ordner legt man Installationsbezogene Bundles an, zum Beispiel Anpassungen in Form einer Erweiterung.

Zitat:

---

Ein stinknormaler Ordner, egal wo? Aber man schreibt doch ein paar Codezeilen, testet dann und macht weiter. Wie soll das Testen gehen, wenn ich nicht in der Contao-Ordnerstruktur drin bin?

---

In dem du zum testen in der Contao Installation ein composer update ausführst.
Du könntest auch nach der Installation in Vendor direkt mal was ausprobieren, das mach ich auch mal ab und zu.
Aber entwickeln außerhalb. In meiner IDE stelle ich dann ein, das er ein Contao 4 mit einbinden soll, damit ich die Code Vervollständigung und dandere Dinge nutzen kann.

Zitat:

---

wohin diese ContaoManagerPlugin.php oder Plugin.php hin soll. Und welche composer.json gemeint ist.

---

Die ContaoManagerPlugin.php das hängt vom Namespace ab wie du das anlegst und speziell für diese Datei gibt es eine Angaben in der composer.joson der Erweiterung.

Da wäre jetzt zu Aufwändig den ganzen Zusammenhang zu erklären.
Schau die meine Folien komplett an, oder eine kleine Erweiterung wie https://github.com/BugBuster1701/contao-xing-bundle und schaue ob du das nachvollziehen kannst.
PSR-4 Autoloading ist der Schlüssel, damit bzw. über Namespace Angaben kannst du selber bestimmen wo welche Dateien liegen.
Es gibt natürlich für Symfony eine grobe Vorgabe, da es noch ein wenig Magie gibt die man wissen muss.

Zitat:

---

Ein stinknormaler Ordner, egal wo? Aber man schreibt doch ein paar Codezeilen, testet dann und macht weiter. Wie soll das Testen gehen, wenn ich nicht in der Contao-Ordnerstruktur drin bin?

---

Ich würde immer im vendor Ordner arbeiten, für Erweiterungen, die (öffentlich) per Composer installiert werden können sollen.
Dafür ist ja

PHP-Code:

---

composer update myname --prefer-source 


---

da.
Also mit einem leeren git Repository arbeiten, bzw. mit einer composer.json. Dann bei packagist registrieren und mit dem o.a. composer update installieren.

Siehe auch hier:
https://github.com/m-vo/docs/blob/a2...environment.md

Zitat:

---

Das ist natürlich blöd. Ich könnte ja aber theoretisch dann in vendor weiterentwickeln, statt in src. Die ganzen Anleitungen geben an, man soll in src sein Bundle anlegen und coden.

---

Für ein spezielles Kundenprojekt: src
Für Composer bzw. den Contao-Manager: /vendor mit --prefer-source
(meine auch, Leo hätte auch ma in einem Ticket geschrieben, dass er das so macht.)

Zitat:

---

Des Weiteren komme ich noch nicht ganz klar, wohin diese ContaoManagerPlugin.php oder Plugin.php hin soll. Und welche composer.json gemeint ist.
Am liebsten würde ich beide Dateien direkt im Bundleverzeichnis mit drin haben.

---

[/QUOTE]

a) Wenn Du das Projekt unter /src ablegst, nutzt du die composer.json im Root, da du ja hier nicht mit composer require deine Erweiterung installierst und composer daher keine eigene composer.json von dir kennt.
b) Als Vendor-Paket liegt deine eigene composer.json in deinem Vendor Ordner.

Das ContaoManagerPlugin befindet sich in beiden Fällen in deinem Plugin Ordner (src oder vendor).
Da schaust Du am besten an anderen Erweiterungen (oder z.B. dem core-bundle).
Im Prinzip ist es egal, wo das ContaoManagerPlugin hinkommt. In der Regel hier hin:
/vendor/src/ContaoManager/Plugin.php
Das gibst Du dann in deiner /vendor/DeinName/composer.json an im Bereich extra

Mit "--prefer-source" direkt in vendor, hmm kann man machen. Aber wie du selber schreibst, kann es da zu Cache Problemen führen. Immer über app_dev arbeiten reicht da leider nicht immer, auch app_dev legt ein Cache an.

Den Workflow muss jeder selbst bestimmen.
Ich zum Beispiel will bei der Erstentwicklung (also noch keine stable Version auf GitHub) keine Registrierung in Packagist machen müssen, nur damit ich das darüber installieren kann zum testen.

Wie in meinen Folien beschrieben (der erste Link), installiert composer meine lokale Erweiterung einfach durch anlegen von symbolischen Links. (repository -> type -> path)
Im Prinzip liegt die dann in vendor/, ich arbeite aber dran außerhalb und trotzdem sind die Änderungen schon drin. Und Installationstests kann ich trotzdem machen.
Und ich kann was probieren ohne das die ganze Sache schon öffentlich wird.

Was damit auch geht, ich kann meine Erweiterung lokal in mehrere Contao Versionen (4.4., 4.5) installieren und parallel testen und habe trotzdem nur ein Verzeichnis in dem ich entwickle. :cool:

Wenn dann die erste stable da ist, editiere ich meine Contao composer.json und nehme den Abschnitt raus, damit composer nun über packagist gehen muss.
Oder direkt von GitHub, wenn ich Erweiterungen habe die ich einfach nicht über packagist anbieten will. :-)


Am besten versucht man die einzelnen Varianten mal durch und nimmt die, die man vollständig verstanden hat.
Denn wenn mal was nicht so funktioniert wie man will, dann ist es wichtig zu wissen, wo man ansetzen muss.

Zitat:

---

Zitat von BugBuster

Mit "--prefer-source" direkt in vendor, hmm kann man machen. Aber wie du selber schreibst, kann es da zu Cache Problemen führen. Immer über app_dev arbeiten reicht da leider nicht immer, auch app_dev legt ein Cache an.

---

Welche Cache Probleme?


Ein Problem gibt es mit --prefer-source: Änderungen in der composer.json (Abhängigkeiten) werden nicht erfasst. Dazu müsste man den Ordner aus dem vendor/ Ordner wieder löschen und nochmal mit --prefer-source requiren.

Irgendwie ist es langsam nicht mehr schön, man quält sich von Video zur Power Point Präsentation hin und her, schaut in das Forum aber es gibt keine klare Anleitung, wie man das ganze "migriert" auf Basis der Version (hier mal 4.5).

https://docs.contao.ninja/de/erweiterung-c3-c4.html
https://docs.contao.org/books/extend...naged-edition/
https://www.youtube.com/watch?v=34R7...ature=youtu.be

ich hab jetzt nach jeder Anleitung versucht, mein Backendmodul aus 3.5 nach 4.5 zu migrieren. Vergebens, wie auch mein Vorredner am Ende hier ebenfalls kapitulierend im Forum nach Hilfe suchend, wie ich am ende feststellen muss. Ich verstehe es aber nicht, kann es nun mal einen zentralen Anlaufpunkt geben, der die Versionen berücksichtigt, wie man nun die Bundles erstellt? Wäre echt prima und im Video wird von Dokumentationen gesprochen, ich finde die alles andere als hinreichend.

Damit ich nicht alles im Anhang posten muss, geb ich gleich mal den Link auf den git https://gitlab.king-arthur.eu/suppor...le/tree/master und wie man schon sehen kann, hatte das ganze mal eine ganz andere Struktur und wie oben schon erwähnt, ich bin jetzt bei der 5. Anleitung (hier aus dem Forum gelandet).

Endresultat:

PHP-Code:

---

The Symfony bundle "Vendor\Bundle\VendorBundle" does not exist. 


---

Bin also gern über jede Hilfestellung dankbar und nehme es auch gern hin, wenn man es eben hier im Forum Scheibchenweise sich zusammen sammeln muss :rolleyes:

Auf der Contao Konferenz hat Leo einen Vortrag darüber gehalten und auch ein Skeleton Bundle zur Verfügung gestellt - welches man sich irgendwann auch über composer erstellen lassen kann :). Wann die Videos bzw. Slides zur Verfügung gestellt werden weiß ich allerdings nicht.

https://twitter.com/leofeyer/status/1005014606824329216

Zitat:

---

Zitat von fgr

Irgendwie ist es langsam nicht mehr schön, man quält sich von Video zur Power Point Präsentation hin und her, schaut in das Forum aber es gibt keine klare Anleitung, wie man das ganze "migriert" auf Basis der Version (hier mal 4.5).
ich hab jetzt nach jeder Anleitung versucht, mein Backendmodul aus 3.5 nach 4.5 zu migrieren. Vergebens, wie auch mein Vorredner am Ende hier ebenfalls kapitulierend im Forum nach Hilfe suchend, wie ich am ende feststellen muss. Ich verstehe es aber nicht, kann es nun mal einen zentralen Anlaufpunkt geben, der die Versionen berücksichtigt, wie man nun die Bundles erstellt? Wäre echt prima und im Video wird von Dokumentationen gesprochen, ich finde die alles andere als hinreichend.

---

Ich leide mit Dir. In C3 hat man einfach seine Erweiterung in system/modules reingeworfen und es lief. Das ist zwar in C4 immer noch möglich, doch man möchte ja mit der Entwicklung mitgehen und gleich ein C4-Bundle machen. Es soll ja mit C4 alles so viel einfacher für Entwickler geworden sein. Ich kann das noch nicht unterschreiben. Für mich ist alles sehr viel schwieriger geworden:

• In vendor kommt das Bundle letztendlich rein, doch da darf man nicht reinschreiben, weil da nur der Composer reinschreiben darf.
• Ich soll im nichtexistenten src-Verzeichnis entwickeln und meine Erweiterung danach auf GitHub hochladen, für Packagist freigeben und mit Composer in vendor installieren.
• Ohne GitHub/Packagist entwickeln scheint wohl nicht mehr richtig zu gehen.
• Ich muß irgendwelche Einträge in irgendwelchen composer.json machen.
• Ich muß ständig var/cache löschen, wenn ich nicht app_dev.php nutzen will.
• ... und wer weiß was ich noch alles an Annehmlichkeiten vergessen habe.

Was bitte ist daran einfacher für Entwickler geworden? Oh, es muß das Symfony-Zeug sein! Damit reicht es 12 Zeilen Code für Contao zu schreiben, anstatt 500 Zeilen, wie Leo Feyer beim Nordtag geschwelgt hat. Leute - wen interessiert das?! Der normalsterbliche Entwickler hat schon genug damit zu tun, die vom Contao-Core zur Verfügung gestellten Funktionen zu nutzen. Ich schaffe das in C3 bestenfalls zu 1-5%, weil ich einfach keine Ahnung davon habe, was C3 für Möglichkeiten bietet. Das Meiste schnappt man durch Googeln auf. Wenn dann jemand meinen Code anschaut kommt dann z.B. die Aussage "Das kannst Du mit einem Model schneller lösen". Die Aussage kam noch nie, aber die Leute die den Core aus dem EffEff kennen, können leicht Erweiterungen performanter gestalten.

Nun ist C4 mit Symfony da und dank Symfony kann ich noch viel besser meinen Code schreiben und Funktionen nutzen, von denen ich vorher nie zu träumen gewagt hätte. Da hyperventiliere ich doch geradezu. Meine Core-Nutzung schrumpft dank Symfony auf 0,01 bis 0,05% zusammen. Ich habe keine blasse Ahnung was Symfony mir bringen soll. Ich bin kein Hardcore-Entwickler, weil ich schlichtweg keine Zeit dafür habe. Das Programmieren erledige ich nebenbei und kann höchstens 2-5 Stunden die Woche dafür aufwenden.

Mittlerweile habe ich auf der Konferenz gelernt, man kann doch in vendor entwickeln, nur geht das etwas trickreicher als einfach reinkopieren.
Und dann auch (erstmal) ohne GitHub.

Zitat:

---

Zitat von Spooky

https://twitter.com/leofeyer/status/1005014606824329216

---

das wäre jetzt die 6. Variante wie man was tut. *lol*

Ich habs aber geschafft, dass Bundle zu registrieren, nun stehe ich aber vor der entscheidenden Aussage, die Christian Schiffler in dem Video tätigte die "src/Resource/contao/" können unverändert bleiben. Aha ... ich glaube das ist nicht so, denn sonst würde ich kein Problem mit dem install Tool bekommen, nach import des Bundles. :eek:

Code:

---

Type error: preg_match() expects parameter 2 to be string, null given

---

Code:

---

Uncaught PHP Exception Symfony\Component\Debug\Exception\FatalThrowableError: "Type error: preg_match() expects parameter 2 to be string, null given" at /var/www/html/vendor/contao/core-bundle/src/Doctrine/Schema/DcaSchemaProvider.php line 203
Hide context    Hide trace
[?
  "exception" => FatalThrowableError {#1 ?}
]
{?
  /var/www/html/minetest/vendor/contao/core-bundle/src/Doctrine/Schema/DcaSchemaProvider.php:203 {?}
  /var/www/html/minetest/vendor/contao/core-bundle/src/Doctrine/Schema/DcaSchemaProvider.php:111 {?}
  /var/www/html/minetest/vendor/contao/core-bundle/src/Doctrine/Schema/DcaSchemaProvider.php:170 {?}
  /var/www/html/minetest/vendor/contao/core-bundle/src/Doctrine/Schema/DcaSchemaProvider.php:59 {?}
  /var/www/html/minetest/vendor/contao/installation-bundle/src/Database/Installer.php:107 {?}
  /var/www/html/minetest/vendor/contao/installation-bundle/src/Database/Installer.php:55 {?}
  /var/www/html/minetest/vendor/contao/installation-bundle/src/Controller/InstallationController.php:429 {?}
  /var/www/html/minetest/vendor/contao/installation-bundle/src/Controller/InstallationController.php:101 {?}
  /var/www/html/minetest/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:151 {?}
  /var/www/html/minetest/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:68 {?}
  /var/www/html/minetest/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:202 {?}
  /var/www/html/minetest/web/app_dev.php:67 {?
    › $kernel = new ContaoKernel('dev', true);
    › $response = $kernel->handle($request);
    › $response->send();
    arguments: {?}
  }
}

---

für mich sieht es so aus, als würde ich ein DCA Element haben, was die Anforderungen nicht genügt. Supi happy debugging ... nur wo :D

in dem File DcaSchemaProvider.php in Zeile 203 steht das hier:

Code:

---

if (preg_match('/default (\'[^\']*\'|\d+)/i', $def, $match)) {
            $default = trim($match[1], "'");
        }

---

Ok, und auf was bezieht sich "/default" ??

src/Resource/contao? Den Ordner sollte es nicht geben.

Meinst du app/Resources/contao?

// edit: achso du meintest innerhalb deines Bundles vermutlich (und hast nur das s vergessen)

Zitat:

---

Zitat von Samson1964

• Ich soll im nichtexistenten src-Verzeichnis entwickeln und meine Erweiterung danach auf GitHub hochladen, für Packagist freigeben und mit Composer in vendor installieren.

---

Nein, in den src/ Ordner kommt nur Code für eine individuelle Contao Installation. Brauchst du die Extension bzw. das Bundle für mehrere Installationen gehst du den anderen Weg (siehe Folien).

Zitat:

---

Zitat von Samson1964

• Ohne GitHub/Packagist entwickeln scheint wohl nicht mehr richtig zu gehen.

---

Doch natürlich. Bei beiden Varianten musst du nicht unbedingt ein VCS verwenden.

Zitat:

---

Zitat von Samson1964

• Ich muß irgendwelche Einträge in irgendwelchen composer.json machen.

---

Du musst Einträge in deiner root composer.json machen - nicht in irgendeiner und auch nicht in irgendwelchen. In Contao 3 musstest du ja auch Einträge in system/modules/config/autoload.php machen, um Klassen zu laden.

Zitat:

---

Zitat von Samson1964

• Ich muß ständig var/cache löschen, wenn ich nicht app_dev.php nutzen will.

---

Während des Entwickelns benutzt man immer die app_dev.php. Warum willst du die nicht benutzen? Und dass du ständig var/cache löschen musst stimmt auch nicht. Da kommt es ganz darauf an was du gemacht hast.

Zitat:

---

Zitat von Samson1964

• ... und wer weiß was ich noch alles an Annehmlichkeiten vergessen habe.

---

Wenn sie dir einfallen poste sie und ich kommentiere auch die dann ;)

Zitat:

---

Zitat von Samson1964

Was bitte ist daran einfacher für Entwickler geworden? Oh, es muß das Symfony-Zeug sein! Damit reicht es 12 Zeilen Code für Contao zu schreiben, anstatt 500 Zeilen, wie Leo Feyer beim Nordtag geschwelgt hat. Leute - wen interessiert das?!

---

Na den Entwickler? Wen sonst?

Zitat:

---

Zitat von Samson1964

Der normalsterbliche Entwickler

---

Was genau ist ein "normalsterblicher Entwickler"?

Zitat:

---

Zitat von Samson1964

Die Aussage kam noch nie, aber die Leute die den Core aus dem EffEff kennen, können leicht Erweiterungen performanter gestalten.

---

Ja natürlich. Wie sollte es auch anders sein?

Zitat:

---

Zitat von Samson1964

Ich bin kein Hardcore-Entwickler, weil ich schlichtweg keine Zeit dafür habe. Das Programmieren erledige ich nebenbei und kann höchstens 2-5 Stunden die Woche dafür aufwenden.

---

Hilfe kannst du bspw. hier im Forum suchen/anfragen.

@fgr: unabhängig von deinem aktuellen Fehler würde ich dir empfehlen alles von src/Resources/contao/classes und src/Resources/contao/modules nach src/ zu verschieben, damit die Klassen sauber im Namespace sind. Dann kannst du dir das alles in der composer.json sparen:

Code:

---

        "classmap": [
            "src/Resources/contao/"
        ],
        "exclude-from-classmap": [
            "src/Resources/contao/config/",
            "src/Resources/contao/dca/",
            "src/Resources/contao/languages/",
            "src/Resources/contao/templates/"
        ]

---

src/Resources/contao/classes/MinetestVectorEditor.php würde ich bspw. nach src/BackendModule/MinetestVectorEditor.php verschieben und die Namespace deklaration entsprechend auf Minetest\ServerInterfaceBundle\BackendModule ändern (und natürlich auch in der src/Resources/contao/config.php ändern).

src/Resources/contao/modules/SimpleAjax.php kannst du ganz entfernen und stattdessen einen src/Controller/AjaxController.php machen (inkl. routing.yml, siehe dazu auch die Folie von Leo - oder frage nochmal nach, was du dafür alles machen musst ;)).

src/Resources/contao/modules/APIopenlayerJSON.php scheint auch nach src/BackendModule/APIopenlayerJSON.php zu gehören.

src/Resources/contao/modules/ModuleMinetestMap.php würde ich zu src/FrontendModule/ModuleMinetestMap.php geben. (Hier gibt es eine Diskrepanz: Frontend Module in Contao haben die Klasse "Module", Backend Module die Klasse "BackendModule". Im Zuge von Contao 4.6 wird man jetzt aber präziser zwischen "FrontendModule" und "BackendModule" unterscheiden, daher würde ich das eben in den Namespace Minetest\ServerInterfaceBundle\FrontendModule geben, anstatt Minetest\ServerInterfaceBundle\Module. Im Endeffekt ist es natürlich egal - der namespace kann natürlich auch Minetest\ServerInterfaceBundle\CzykBcojfskGu oder sonst was heißen. Es geht ja nur um eine sinnvolle Strukturierung, verpflichtend ist hier gar nichts.)

Zitat:

---

Zitat von Spooky

@fgr: unabhängig von deinem aktuellen Fehler würde ich dir empfehlen alles von src/Resources/contao/classes und src/Resources/contao/modules nach src/ zu verschieben, damit die Klassen sauber im Namespace sind. Dann kannst du dir das alles in der composer.json sparen:

Code:

---

        "classmap": [
            "src/Resources/contao/"
        ],
        "exclude-from-classmap": [
            "src/Resources/contao/config/",
            "src/Resources/contao/dca/",
            "src/Resources/contao/languages/",
            "src/Resources/contao/templates/"
        ]

---

src/Resources/contao/classes/MinetestVectorEditor.php würde ich bspw. nach src/BackendModule/MinetestVectorEditor.php verschieben und die Namespace deklaration entsprechend auf Minetest\ServerInterfaceBundle\BackendModule ändern (und natürlich auch in der src/Resources/contao/config.php ändern).

src/Resources/contao/modules/SimpleAjax.php kannst du ganz entfernen und stattdessen einen src/Controller/AjaxController.php machen (inkl. routing.yml, siehe dazu auch die Folie von Leo - oder frage nochmal nach, was du dafür alles machen musst ;)).

src/Resources/contao/modules/APIopenlayerJSON.php scheint auch nach src/BackendModule/APIopenlayerJSON.php zu gehören.

src/Resources/contao/modules/ModuleMinetestMap.php würde ich zu src/FrontendModule/ModuleMinetestMap.php geben. (Hier gibt es eine Diskrepanz: Frontend Module in Contao haben die Klasse "Module", Backend Module die Klasse "BackendModule". Im Zuge von Contao 4.6 wird man jetzt aber präziser zwischen "FrontendModule" und "BackendModule" unterscheiden, daher würde ich das eben in den Namespace Minetest\ServerInterfaceBundle\FrontendModule geben, anstatt Minetest\ServerInterfaceBundle\Module. Im Endeffekt ist es natürlich egal - der namespace kann natürlich auch Minetest\ServerInterfaceBundle\CzykBcojfskGu oder sonst was heißen. Es geht ja nur um eine sinnvolle Strukturierung, verpflichtend ist hier gar nichts.)

---

Hi,

ich stehe da noch irgendwie auf dem Schlauch. Gern hätte ich mal ein Grundgerüst hierzu gesehen. Wo könnte ich mir das eventuell mal anschauen?

Zitat:

---

Zitat von BugBuster

Mittlerweile habe ich auf der Konferenz gelernt, man kann doch in vendor entwickeln, nur geht das etwas trickreicher als einfach reinkopieren.
Und dann auch (erstmal) ohne GitHub.

---

könntest du das noch etwas näher erläutern?

Ich weiß nicht genau ob ich alles richtig verstanden habe, daher wollte ich das schon längst mal probieren.
Bin aber noch nicht zu gekommen.

Ich hab das neulich gemacht. Entwicklung im vendor verzeichnis (xampp). Dies ist auch die Workingcopy. Das Repository liegt irgendwo anders auf den Rechner. Dann kann ich nach dem Pushen aus dem repository installieren/updaten. Ich weiß auch nicht ob das so korrekt ist. Aber es scheint zu funktionieren.

Zitat:

---

Zitat von BugBuster

Ich weiß nicht genau ob ich alles richtig verstanden habe, daher wollte ich das schon längst mal probieren.
Bin aber noch nicht zu gekommen.

---

Wird hier im Abschnitt 4 auch gut beschrieben wie es gehen könnte.
https://gist.github.com/joergmoldenh...c2d039095142#2