custom CMS - Block Kategorie

Aktuell gibt es ja vier Block Kategorien Text, Images, Text&Images, Commerce.

Gibt es eine Möglichkeit eine eigene Kategorie hinzuzufügen, wo man dann praktisch all seine custom Elemente rein packt?

Andernfalls wäre es extremst unübersichtlich.

Fände ich auch spannend, habe aber noch nichts gefunden dazu…

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍ Hast du vielleicht Infos dazu? :slight_smile:

Hallo zusammen,

ihr könnt den sw_cms_detail_sidebar_block_overview_category in der sw-cms-detail.html.twig via plugin Überschreiben und eure eigenen Optionen hinzufügen. Danach könnt Ihr dann eure Böcke zur neuen Kategorie zuweisen (CustomBlock/index.js -> category: ‘newType’) 

Hoffentlich hilft euch die Info weiter. 

Viele Grüße aus Schöppingen
 Thorben Pantring

1 „Gefällt mir“

@tpantring‍ Super, vielen Dank :slight_smile:

Aber Vorsicht, macht nicht den selben Fehler wie ich und trennt Blöcke und Elemente :wink: Denn Blöcke sind nur fürs Layout und mit den Elementen füllt man die Blöcke.

@Moorleiche schrieb:

Aber Vorsicht, macht nicht den selben Fehler wie ich und trennt Blöcke und Elemente ;) Denn Blöcke sind nur fürs Layout und mit den Elementen füllt man die Blöcke.

Ja habe vor ein paar Stunden auch erst den Unterschied zwischen Blöcken & Elementen gerallt :D 

Vielleicht erstellst du auch ein Tutorial direkt dazu. Vermisse die alten Hostianer Tutorials. =) 

@Shopwareianer schrieb:

@Moorleiche schrieb:

Aber Vorsicht, macht nicht den selben Fehler wie ich und trennt Blöcke und Elemente ;) Denn Blöcke sind nur fürs Layout und mit den Elementen füllt man die Blöcke.

Ja habe vor ein paar Stunden auch erst den Unterschied zwischen Blöcken & Elementen gerallt :D 

1 „Gefällt mir“

@yicdeniz schrieb:

Vielleicht erstellst du auch ein Tutorial direkt dazu. Vermisse die alten Hostianer Tutorials. =) 

@Shopwareianer schrieb:

@Moorleiche schrieb:

Aber Vorsicht, macht nicht den selben Fehler wie ich und trennt Blöcke und Elemente ;) Denn Blöcke sind nur fürs Layout und mit den Elementen füllt man die Blöcke.

Ja habe vor ein paar Stunden auch erst den Unterschied zwischen Blöcken & Elementen gerallt :D 

Ein Tutorial? Das Wissen muss hart erarbeitet werden  Grin

Wenn man dann Änderungen im Ordner “component” oder “preview” gemacht hat, muss man ja jedes Mal ./psh.phar administration:build ausführen, damit man was von den Änderungen sieht, nur die Frontend Templates können direkt geändert werden. Dauert bei mir leider jedes Mal 90 bis 110 Sekunden, gibt’s da nen Trick wie man das Ganze beschleunigen kann?

./psh.phar administration:watch startet den watch & hot-reload modus für das backend.

Super, danke!!!

Bekomme aber leider wilde Fehlermeldungen in der Art:

	 WAIT Compiling...9:41:42 AM
	
	ℹ 「wdm」: Compiling...
	 DONE Compiled successfully in 2140ms9:41:44 AM
	
	ℹ 「wdm」: 3271 modules
	ℹ 「wdm」: Compiled successfully.
	(node:521) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/app/platform/src/Administration/Resources/public/static/css/storefront.css'
	(node:521) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 5)
	(node:521) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/app/platform/src/Administration/Resources/public/storefront.14065f1e6cef1d19edd0.hot-update.js'
	(node:521) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 6)
	(node:521) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/app/platform/src/Administration/Resources/public/static/js/storefront.js'
	(node:521) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 7)
	(node:521) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/app/platform/src/Administration/Resources/public/custom-cms-block.14065f1e6cef1d19edd0.hot-update.js'
	(node:521) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 8)
	(node:521) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/app/platform/src/Administration/Resources/public/static/css/custom-cms-block.css'
	(node:521) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 9)
	(node:521) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/app/platform/src/Administration/Resources/public/static/js/custom-cms-block.js'
	(node:521) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 10)

Die kommen beim normalen build nicht.

@digitalhoch3 schrieb:

Wenn man dann Änderungen im Ordner „component“ oder „preview“ gemacht hat, muss man ja jedes Mal ./psh.phar administration:build ausführen, damit man was von den Änderungen sieht, nur die Frontend Templates können direkt geändert werden. Dauert bei mir leider jedes Mal 90 bis 110 Sekunden, gibt’s da nen Trick wie man das Ganze beschleunigen kann?

du glücklicher, bei mir dauert es 3-mal so lang… muss mal neue Hardware her ;) 

CPUs sind durch nichts zu ersetzen außer durch noch größere CPUs  Grin

@tpantring schrieb:

Hallo zusammen,

ihr könnt den sw_cms_detail_sidebar_block_overview_category in der sw-cms-detail.html.twig via plugin Überschreiben und eure eigenen Optionen hinzufügen. Danach könnt Ihr dann eure Böcke zur neuen Kategorie zuweisen (CustomBlock/index.js -> category: ‚newType‘) 

Hoffentlich hilft euch die Info weiter. 

Viele Grüße aus Schöppingen
 Thorben Pantring

Was würde den passieren wenn mehrere Plugins die gleiche stolle so überschreiben? Ich kann mir gut vorstellen dass im Zukunft einige „CMS - Erweiterungs Plugins“ geben wird mit eigenen Kategorienamen.

Mann sollte hier lieber nur die Options erweitern können anstelle den gesamten Block zu überschreiben - oder sehe ich das Falshc?!

@tpantring schrieb:

Hallo zusammen,

ihr könnt den sw_cms_detail_sidebar_block_overview_category in der sw-cms-detail.html.twig via plugin Überschreiben und eure eigenen Optionen hinzufügen. Danach könnt Ihr dann eure Böcke zur neuen Kategorie zuweisen (CustomBlock/index.js -> category: ‚newType‘) 

Hoffentlich hilft euch die Info weiter. 

Viele Grüße aus Schöppingen
 Thorben Pantring

 Um die Blockkategorie zu erweitern muss man den Block „sw_cms_detail_sidebar_block_overview_category“ überschreiben welcher sich bei mir inzwischen in der Datei „sw-cms-sidebar.html.twig“ befindet.
Der Pfad hierzu ist „/plattform/src/Administration/Resources/app/administration/src/module/ …“

Wie kann ich die Datei in mein Plugin einbinden um den entsprechenden Block zu erweitern welches sich in /custom/mein_plugin/… befindet.

Mit "{% sw_extends '@Parent/ … erreiche ich den Pfad nicht.

Muss man hierfür einen anderen Weg gehen?

Freundliche Grüsse und allen hier einen guten Rutsch ins neue Jahr.

 

 

Oh man, nach Update auf 6.1 werden nun meine Blöcke im Backend nicht mehr gefunden. Habe schon die Struktur angepasst wie in vendor/shopware/administration/Resources/app/administration/src/module/sw-cms/blocks/, die Vorschau Elemente erscheinen aber nicht. Bereits vorhandene Elemente in den Erlebniswelten sind zwar vorhanden, werden aber auch nicht korrekt dargestellt.

Im Frontend passt aber alles noch, hat jemand einen Tipp?

Hej @digitalhoch3 und allg.,

durch Shopware 6 hat sich das Anlegen einer Custom CMS Category leicht verändert.
Hier ein richtig guter Beitrag von Joschi (Ninja Army):

damit lässt sich ganz leicht eine Custom CMS Category anlegen.
Approved durch mich, da ich diese gerade bei uns im System erfolgreich angelegt habe.

Beste Grüße
Pascal