Erweiterungsbundle, Symlinks nicht bei Managed-Editon Version

[BugBuster]

Ich habe da was merkwürdiges.
Ich habe meine Grid16 Erweiterung vor längerer Zeit für Contao 4.1 umgebaut als Bundle.
Das funktionierte bisher auch alles unter Contao Standard Edition. (4.3.9)

Nun habe ich in der composer.json die contao-manager-plugin Zeile eingebaut inkl. der Contao Manager Plugin-Klasse. Die Installation in der Managed-Edition geht auch, ebenso in der Standard Edition mit dieser Änderung, jedoch werden die Symlinks in beiden Installationen nicht mehr angelegt.
Ich rede dabei nicht über Symlinks die Inhalte aus dem public Verzeichnis ins web/ verlinken sollen, sondern spezielle die in der composer.json angegeben sind unter extra-contao-sources.
Auszug:

		"contao":{
			"sources":{
"assets/contao/css/grid-1120-16-pixel-responsive.css": "assets/contao/css/grid-1120-16-pixel-responsive.css",

Nochmal anders gesagt:
Mein contao-grid_16-bundle im master Branch, nur für Standard-Edition angepasst:

• Symlinks nach assets/contao/css werden angelegt in Contao Standard-Edition
• Symlinks nach assets/contao/css werden angelegt in Contao Managed-Edition

Mein contao-grid_16-bundle im develop Branch, zusätzlich für Managed-Edition angepasst:

• Symlinks nach assets/contao/css werden nicht angelegt in Contao Standard-Edition
• Symlinks nach assets/contao/css werden nicht angelegt in Contao Managed-Edition

Es spielt also offensichtlich keine Rolle welche Contao Edition installiert ist.

Und nun? So gehts in beiden nicht mehr.

[BugBuster]

Nachtrag:

Es liegt an dieser Zeile:

"type":"contao-module",

Die Symlinks werden angelegt

"type":"contao-bundle",

Die Symlinks werden nicht mehr angelegt.

Ist das so gewollt? Wenn ja, wie bekomme ich über einer Erweiterung als Bundle nun Dateien nach assets/contao/css ?

[BugBuster]

Muss ich da etwa noch eine Erweiterung vom Type: contao-components mitbringen, nur mit den CSS Dateien? so wie contao-components/contao ?

[Spooky]

Evt. ist das bei einem Contao Bundle nicht vorgesehen - weil es auch bei einem regulären Symfony Bundle nicht vorgesehen ist. Vielleicht funktioniert es aber mit

    "extra": {
        "component": {
            …
        }
    }

wenn du auch robloach/component-installer requirest - aber keine Ahnung welche Voraussetzungen es dafür gibt.

Aber wozu überhaupt in den alten assets Folder damit? Lass es doch einfach im Bundle, das wäre der reguläre Weg.

[BugBuster]

Deswegen hat ja Contao noch Components eingeführt und den "contao-components/installer" soweit ich gesehen habe.
(siehe z.B. https://github.com/contao-components/contao )

Ich will deshalb die CSS direkt in assets/contao/css Ordner reinbekommen, damit die im LayoutBuilder direkt auftauchen und ich die gleich dort aktivieren kann, wie die von Hause aus mitgelieferten auch.
Das hat in Contao 3 gut funktioniert.

grid16.jpg

Derzeit installiert der "contao-components/installer" die per default unter assets/<component-name>/... was mir auch nicht viel hilft, es sei denn ich würde etwas als buguster/contao veröffentlichen, was aber wieder missverstanden werden würde.
Wahrscheinlich läuft es darauf hinaus, es als "bugbuster-components/contao" zu veröffentlichen, sofern ich keine andere Möglichkeit finde die auch ein sicheres remove beinhaltet, wenn jemand die Erweiterung wieder deinstalliert.

[Spooky]

Achso naja, meiner Meinung nach sollten in den Ordner assets/contao nur die tatsächlichen Contao Assets, keine Assets von Extensions . Wenn Extensions eigenes CSS mitbringen, wählt man dies normalerweise unter einer eigenen Sektion in tl_layout aus.

[BugBuster]

Zur Not auch das, dann muss ich mich aber auch um die Einbindung im Frontend je nach verwendetem Theme Layout selber kümmern, das wollte ich mir ersparen.

[NetMediaWork]

Hallo,

macht ja auch wenig Sinn, wenn man dorthin nichts selber einbinden könnte.

Eine CSS-Reset wie bsw. Normalize würde man ja an den Anfang stellen, bevor andere Stylesheets geladen werden. Das wäre so dann über ein Modul nicht möglich.

[BugBuster]

Oje. Das wird alles nichts in Contao 4. Dateien in "fremde" Componenten schreiben sollte man nie tun!. (wer mehr wissen will, fragt mich auf der Konferenz )

Habe nun eine eigene Componente mit eigenem assets Pfad. Jetzt suche ich den richtigen Hook um die im Frontend zu platzieren.
Der getPageLayout schien mir Anfangs geeignet (objLayout->framework manipulieren), aber PageRegular nimmt bei den Framework CSS Angaben einen festen Pfad + basename der Datei, bringt mir also nichts.
Was ginge:
Über $GLOBALS['TL_CSS'][] = 'meine datei in meinem pfad'; bekomme ich die vor allen anderen CSS
über $GLOBALS['TL_HEAD']... nach den anderen.

Dazu muss ich dann aber doch einen eigenen Abschnitt in Theme->Layout anlegen mit Auswahl meiner CSS und der Einbindungsreihenfolge.

Wenn ich das allerdings so tue, dann könnte ich das auch alles wieder in einer Erweiterung kippen und die CSS doch aus web/bundles/... laden.

[NetMediaWork]

Hallo,

ideal wäre ein Hook der es erlaubt auch eigene CSS aus einem Modul/Bundle nach $GLOBALS['TL_DCA']['tl_layout']['fields']['framework']['options'] zu laden, ohne das diese in assets/contao/css/ liegen müssen, um diese auch im Layout sortieren zu können.

[BugBuster]

Da gibt es mehrere Probleme. Das per Hook dort reinzubekommen geht ja noch, aber wie gesagt der Pfad zu den eigenen passt dann nicht.
Wo ich aber auch drüber gestolpert bin, das Datenbank Feld ist nur 255 Zeichen groß. Wenn man derzeit alle Core-CSS auswählt und zusätzlich alle meine 4 kommt schon ne Fehlermeldung.
Das serialisierte Array ist dann als String einfach zu groß. Wundert mich grad das es nicht schon zu Contao 3 Zeiten geknallt hat.

Ich hatte auch schon geschaut ob man sich in die externen einklinken kann, dann müssen die aber unter files/ liegen, da dort über die UUID gearbeitet wird.

Das ganze System ist an dieser Stelle nicht ausgelegt dort was passendes einfügen zu können.
Außer eben, wie ich jetzt mal probieren werde, die DCA von tl_layout zu erweitern um eine eigene Gruppe und Werte und über ein Frontend Hook dann die entsprechend einbinden.

Im Notfall kann man dann auch einfach alle CSS nach Files kopieren, alle als externe einbinden und dann sortieren wie man es haben möchte.
Aber im meinen Einsatzfällen habe ich das reset von Contao eingebunden und danach meine Grid CSS, und das wird auch so möglich sein wenn ich meine Idee umgesetzt habe.
Ob die internen über den CSS Editor angelegt dann nach den Grid-CSS kommen bleibt noch zu testen. Wenn nicht wäre das uncool.

Im Prinzip sollte man sich mal allgemein überlegen, wo solche CSS Frameworks, ob nun Grids, oder Bootstraps, oder .... ablegen sollte, vielleicht gibt es da auch Vorgaben von Symfony?:

• assets/<deine-componente>/css (dazu muss zumindest ein Teil eine contao-componente sein)
• files/<dein bundlename>/css
• public Ordner im Bundle und somit automatisch nach web/bundles/<bundlename/css

Wo ich auch prinzipiell ein Problem in Contao 4 sehe, die uniqe Namen von den Bundles die es nunmal nicht zwingend geben kann.
Eindeutige Namen zu finden damit nicht jemand Dateien anderer überschreibt wird immer wichtiger. Das war im ER2 einfacher, da konnte man nur unique Namen anlegen.

[NetMediaWork]

@Bugbuster

erstaunlich, das es aber mit dem Bundle 0.1.2 in der Standard-Edition funktioniert, weil dort ja dann die Symlinks gesetzt werden.

Ein wirklicher Fortschritt wäre es ja, wenn man sich die ext. CSS-Frameworks über Composer in den Vendor lädt und diese dann dort aktuell hält, wiederum über Composer und von dort aus dann in das Conto-Framework im Layout zur Auswahl hätte, schon um es dort auch entsprechend sortieren zu können.

[BugBuster]

Das funktioniert, weil es da noch intern als contao-module deklariert ist und nicht als contao-bundle.
Da macht Contao offensichtlich ein Unterschied um im Manager unterscheiden zu können, echte Contao Bundles gefiltert finden zu können oder andere Erweiterungen. (auch als Contao 3 Erweiterungen betitelt)

Ein Bundle hat halt nach Symfony Bestimmung öffentliches im Verzeichnus public abzulegen, was dann automatisch nach web/... gesymlinkt wird.

[Spooky]

Hallo,

ideal wäre ein Hook der es erlaubt auch eigene CSS aus einem Modul/Bundle nach $GLOBALS['TL_DCA']['tl_layout']['fields']['framework']['options'] zu laden, ohne das diese in assets/contao/css/ liegen müssen, um diese auch im Layout sortieren zu können.

Besser wäre es, wenn die Pfade nicht hardgecodet wären, sondern in den options des Feldes bereits integriert sind und von Contao per load_callback einfach geladen werden. Dadurch könnte man in einem eigenen load_callback weitere CSS Dateien (die dann irgendwo liegen können) hinzufügen.

[NetMediaWork]

Besser wäre es, wenn die Pfade nicht hardgecodet wären, sondern in den options des Feldes bereits integriert sind und von Contao per load_callback einfach geladen werden. Dadurch könnte man in einem eigenen load_callback weitere CSS Dateien (die dann irgendwo liegen können) hinzufügen.

sehe ich auch so, das im Conto-CSS-Framework nur Dateien geladen werden können, die zwingend in root/assets/contao/css liegen.

[Spooky]

Könnte man ja als Feature Request posten im core-bundle . Oder gleich einen Pull Request, der das dementsprechend umsetzt